GIL - is there interest for an image library in Boost?
Hello, We have developed the Generic Image Library (GIL) - a library that abstracts away the image representation from algorithms written for images. It allows for writing the algorithm once and having it work for images in any color space, channel depth and pixel organization with performance comparable to writing the code for each specific image format. GIL is currently part of the Adobe Open Source Libraries and we use it for several imaging projects inside Adobe. Its only dependency is boost. You can find the sources and documentation at GIL's home page: http://opensource.adobe.com/gil Is there an interest for having GIL be a boost library? Also, I would appreciate any recommendations for improving the design of GIL. Thanks, Lubomir
Lubomir Bourdev wrote:
Hello,
We have developed the Generic Image Library (GIL) - a library that abstracts away the image representation from algorithms written for images. It allows for writing the algorithm once and having it work for images in any color space, channel depth and pixel organization with performance comparable to writing the code for each specific image format.
GIL is currently part of the Adobe Open Source Libraries and we use it for several imaging projects inside Adobe. Its only dependency is boost.
You can find the sources and documentation at GIL's home page:
http://opensource.adobe.com/gil
Is there an interest for having GIL be a boost library?
yes++ -- very, very cool! Jeff
Lubomir Bourdev wrote:
http://opensource.adobe.com/gil
Is there an interest for having GIL be a boost library?
Definitely yes. m Send instant messages to your online friends http://au.messenger.yahoo.com
Lubomir Bourdev wrote:
GIL is currently part of the Adobe Open Source Libraries and we use it for several imaging projects inside Adobe. Its only dependency is boost.
Is there an interest for having GIL be a boost library?
I've only skimmed your docs but it looks very interesting indeed! Of course the first extension folks are likely to ask for is image-file IO, but I guess that's a whole other ball game? John.
Very interested. thanks the design guide does mention the GIL io extension (not yet released) and it provides examples of loading and saving jpeg. Could you explain more about this extension and which formats will support (apart from JPEG I assume PNG ..) On 6/5/06, John Maddock <john@johnmaddock.co.uk> wrote:
Lubomir Bourdev wrote:
GIL is currently part of the Adobe Open Source Libraries and we use it for several imaging projects inside Adobe. Its only dependency is boost.
Is there an interest for having GIL be a boost library?
I've only skimmed your docs but it looks very interesting indeed!
Of course the first extension folks are likely to ask for is image-file IO, but I guess that's a whole other ball game?
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
John Maddock wrote:
Of course the first extension folks are likely to ask for is image-file IO, but I guess that's a whole other ball game?
We just released the first version of our I/O extension, but we haven't updated the documentation yet. It supports JPEG, TIFF and PNG. It supports run-time instantiated images, so you can load the image in its native color space and channel depth. Our I/O operates at a very base level - like load the image in a given format from a given file. If you use GIL inside ASL you will get extra goodies - such as a dynamic registration of I/O modules and tighter integration with Adam/Eve libraries. Lubomir
could you pls let the list know when the docs are updated ? thxs On 6/5/06, Lubomir Bourdev <lbourdev@adobe.com> wrote:
John Maddock wrote:
Of course the first extension folks are likely to ask for is image-file IO, but I guess that's a whole other ball game?
We just released the first version of our I/O extension, but we haven't updated the documentation yet. It supports JPEG, TIFF and PNG. It supports run-time instantiated images, so you can load the image in its native color space and channel depth.
Our I/O operates at a very base level - like load the image in a given format from a given file. If you use GIL inside ASL you will get extra goodies - such as a dynamic registration of I/O modules and tighter integration with Adam/Eve libraries.
Lubomir
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
We just updated our web pages and created a stand-alone version of the Generic Image Library: http://opensource.adobe.com/gil/ You can now download it outside of ASL. The only required dependency is Boost. We also allow you to browse GIL-only Doxygen documentation. We have updated all the documentation. We would like to hear of any suggestions you might have on improving the design of the library. Assuming there is sufficient interest on your side, and the amount of work required for a successful submission is not unreasonable, we would like to pursue a Boost submission. Thanks, Lubomir
Jose wrote:
could you pls let the list know when the docs are updated ? thxs
On 6/5/06, Lubomir Bourdev <lbourdev@adobe.com> wrote:
John Maddock wrote:
Of course the first extension folks are likely to ask for is
image-file
IO,
but I guess that's a whole other ball game?
We just released the first version of our I/O extension, but we haven't updated the documentation yet. It supports JPEG, TIFF and PNG. It supports run-time instantiated images, so you can load the image in its native color space and channel depth.
Our I/O operates at a very base level - like load the image in a given format from a given file. If you use GIL inside ASL you will get extra goodies - such as a dynamic registration of I/O modules and tighter integration with Adam/Eve libraries.
Lubomir
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
the design guide (and tutorial) have not changed. Are they up to date ? Do you plan to document the IO extension ? The last release in sf is dated 2-june. is that the last one ? It would also be nice if you could also reply to a previous email regarding GIL not being flexible enough thxs On 6/15/06, Lubomir Bourdev <lbourdev@adobe.com> wrote:
We just updated our web pages and created a stand-alone version of the Generic Image Library:
http://opensource.adobe.com/gil/
You can now download it outside of ASL. The only required dependency is Boost. We also allow you to browse GIL-only Doxygen documentation. We have updated all the documentation.
We would like to hear of any suggestions you might have on improving the design of the library.
Assuming there is sufficient interest on your side, and the amount of work required for a successful submission is not unreasonable, we would like to pursue a Boost submission.
Thanks, Lubomir
Jose wrote:
could you pls let the list know when the docs are updated ? thxs
On 6/5/06, Lubomir Bourdev <lbourdev@adobe.com> wrote:
John Maddock wrote:
Of course the first extension folks are likely to ask for is
image-file
IO,
but I guess that's a whole other ball game?
We just released the first version of our I/O extension, but we haven't updated the documentation yet. It supports JPEG, TIFF and PNG. It supports run-time instantiated images, so you can load the image in its native color space and channel depth.
Our I/O operates at a very base level - like load the image in a given format from a given file. If you use GIL inside ASL you will get extra goodies - such as a dynamic registration of I/O modules and tighter integration with Adam/Eve libraries.
Lubomir
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jose wrote:
the design guide (and tutorial) have not changed. Are they up to date ?
Do you plan to document the IO extension ?
There are little changes to the documents, as they were already up-to-date. The only significant change is section 14 of the design guide, which describes the new I/O extension.
The last release in sf is dated 2-june. is that the last one ?
Please use the following URL for the latest code and documentation: http://opensource.adobe.com/gil The stuff inside sourceforge is the monthly release of ASL, which does not contain the latest updates.
It would also be nice if you could also reply to a previous email
regarding
GIL not being flexible enough
Strangely, Pavel's original post never got to my email client. Thanks Jose for pointing it out to me - I will read it carefully and respond tomorrow. Lubomir
Jose wrote:
It would also be nice if you could also reply to a previous email regarding GIL not being flexible enough
Pavel Chikulaev wrote:
Sure there is, but I do think that this library is not flexible enough - image layout (RGB and RGB classes).
It is hard to compare the two approaches if you don't have the code side by side, but let me say a few words about GIL's flexibility. Pavel's concern was that every channel permutation (like BGR, for example) requires creating a new color space, which seems inflexible. I think his concern is in part a misunderstanding based on terminology. In both GIL and his example, to support BGR we have to write some new code - in GIL we call it "derived color space" while Pavel calls it "layout" But let me point out that: 1. Adding a channel permutation (like BGR) requires very little new code 2. All channel-level support (assignment, copy-construction, etc) will automatically work for BGR 3. All the algorithms that operate on RGB will automatically work for BGR (unless explicitly prevented). In detail: ___1. Adding a channel permutation (like BGR) requires very little new code The only changes that you need to do to make BGR are more or less the following: struct bgr_t : public rgb_t {}; template <typename T> struct color_base<T,bgr_t> { T blue,green,red; color_base() {} color_base(T v0, T v1, T v2) : blue(v0),green(v1),red(v2) {} template <typename T1, typename C1> color_base(const color_base<T1,C1>&); template <int N> T& semantic_channel(); template<> T& semantic_channel<0>() { return red; } template<> T& semantic_channel<1>() { return green; } template<> T& semantic_channel<2>() { return blue; } }; The only catch is that it is illegal to create full specialization (semantic_channel<0>) inside a partially specialized class, which requires us instead to use a channel_accessor class. Note that the above color_base class is homogeneous (every channel type is the same) but a heterogeneous one can be created the same way. The "semantic channel" accessor is needed to pair channels semantically. We are investigating a more compact representation, for example using mpl::vector_c<int, 2,1,0>. The color base class is reused in many places - when T is a channel, it is used to construct a pixel. When T is a channel reference, it is used to construct a proxy reference to a planar pixel (a bundle of three references). When T is a channel iterator, it is used to form the basis of a planar pointer (a bundle of three pointers) ___2. All channel-level support will automatically work for BGR All the channel-level operations are abstracted out of the pixel and are automatically provided. In other words, I never have to explicitly define how to copy-construct, assign or compare between BGR pixels. fill_channels, transform_channels, max_channel, etc. already work for BGR. Not only that, they also work for planar references and planar pointers (see how planar pointers are incremented). Not only are things like copy constructor and operator== automatically available for BGR; they are also optimally efficient - we are using a compile-time recursion to avoid explicit loops over the channels. One important feature: channel-level operations properly pair the channels semantically. For example, if you assign an RGB pixel to a BGR pixel, GIL will properly assign the red source to the red destination. ___3. All the algorithms that operate on RGB will automatically work for BGR (unless explicitly prevented). No special code is needed to handle color space variations. For example, if you provide an "RBG" variation, you can automatically color convert between RBG and CMYK (the RGB to CMYK code will be reused.) Another example - the I/O code will allow you to read into an RBG image, (as long as RGB is supported for the given file format). ______________ Flexibility is one of the principal design goals of GIL. Everything is based on concepts, which means that you can replace just about any part of GIL and use the rest. One developer can provide XYZ color space, another can provide 64-bit channel, a third one can provide a fully synthetic image view, such as the Mandelbrot set, and we can use the existing GIL algorithms (for example x_gradient from the tutorial) to compute the gradient of the Mandelbrot set in the new color space using the new channel type. Furthermore, all these developers don't need to coordinate with each other (or even know about each other) and the GIL core doesn't need to change. Pavel's example of constructing a pixel is nice. But I see no theoretical reason why we can't get GIL to work with his pixels, for example. GIL is flexible enough to allow you to specify the ordering of the channels (and any other property of your image) at run-time as well. If you follow certain rules, your run-time version will be practically as efficient as a compile-time version. We feel really good about GIL's flexibility. Other advantages of GIL are its performance, extensibility, compatibility with existing code/libraries, minimality of constructs, nonintrusiveness and the high-profile projects that use GIL already. If you are interested in any of these aspects let me know and I can say a few words about them too. Lubomir
Lubomir Bourdev wrote:
> Pavel's concern was that every channel permutation (like BGR, for
> example) requires creating a new color space, which seems inflexible.
>
> I think his concern is in part a misunderstanding based on terminology.
> In both GIL and his example, to support BGR we have to write some new
> code - in GIL we call it "derived color space" while Pavel calls it
> "layout"
"Derived color space" is only a small subset of "layout".
> But let me point out that:
> 1. Adding a channel permutation (like BGR) requires very little new code
> 2. All channel-level support (assignment, copy-construction, etc) will
> automatically work for BGR
> 3. All the algorithms that operate on RGB
> will automatically work for BGR (unless explicitly prevented).
Ok. You've pointed out how make a new permutation of any colorspace, but
don't you think it's kind of too-level stuff and should be automated?
I still think you approach is less flexible:
1. I can hardly imagine how you would support all YCbYr 4:4:4, 4:2:2,
4:2:1, 4:2:0, etc. (Especially 4:2:0 one ;) without redutant data)
2. Perhaps with your "semantic channels" you can create interleaved RGB
image, but do you really think that mixing "colorspace" stuff and how it
is organized in memory is good?
> In detail:
> ___1. Adding a channel permutation (like BGR) requires very little new
> code
> The only changes that you need to do to make BGR are more or less the
> following:
> struct bgr_t : public rgb_t {};
> template <typename T>
> struct color_base<T,bgr_t> {
> T blue,green,red;
> color_base() {}
> color_base(T v0, T v1, T v2) : blue(v0),green(v1),red(v2) {}
> template <typename T1, typename C1> color_base(const
> color_base<T1,C1>&);
>
> template <int N> T& semantic_channel();
> template<> T& semantic_channel<0>() { return red; }
> template<> T& semantic_channel<1>() { return green; }
> template<> T& semantic_channel<2>() { return blue; } };
>
> The only catch is that it is illegal to create full specialization
> (semantic_channel<0>) inside a partially specialized class, which
> requires us instead to use a channel_accessor class.
You could use T& semantic_channel(boost::mpl::int_<0>) { return red; }
and in some "very" base class
template<typename U>
void semantic_channel(U)
{
//Something's wrong with client code if it've triggered
BOOST_STATIC_ASSERT(sizeof(U) != 0);
}
> We are investigating a more compact representation, for example using
> mpl::vector_c<int,2,1,0>.
Once you make it working and add some generalization be sure you'll get
my layout ! ;)
> between RBG and CMYK (the RGB to CMYK code will be reused.) Another
> example - the I/O code will allow you to read into an RBG image, (as
> long as RGB is supported for the given file format).
About IO: If I understand correctly you in Adobe have "not open-source"
IO GIL stuff? Is it correct and would that two versions be the same one day?
--
Pavel Chikulaev
Lubomir Bourdev wrote:
Pavel's concern was that every channel permutation (like BGR, for example) requires creating a new color space, which seems inflexible.
I think his concern is in part a misunderstanding based on terminology. In both GIL and his example, to support BGR we have to write some new code - in GIL we call it "derived color space" while Pavel calls it "layout"
"Derived color space" is only a small subset of "layout".
But let me point out that: 1. Adding a channel permutation (like BGR) requires very little new code 2. All channel-level support (assignment, copy-construction, etc) will automatically work for BGR 3. All the algorithms that operate on RGB will automatically work for BGR (unless explicitly prevented).
Ok. You've pointed out how make a new permutation of any colorspace, but don't you think it's kind of too-level stuff and should be automated? I still think you approach is less flexible: 1. I can hardly imagine how you would support all YCbYr 4:4:4, 4:2:2, 4:2:1, 4:2:0, etc. (Especially 4:2:0 one ;) without redutant data) 2. Perhaps with your "semantic channels" you can create interleaved RGB image, but do you really think that mixing "colorspace" stuff and how it is organized in memory is good?
In detail: ___1. Adding a channel permutation (like BGR) requires very little new code The only changes that you need to do to make BGR are more or less the following: struct bgr_t : public rgb_t {}; template <typename T> struct color_base<T,bgr_t> { T blue,green,red; color_base() {} color_base(T v0, T v1, T v2) : blue(v0),green(v1),red(v2) {} template <typename T1, typename C1> color_base(const color_base<T1,C1>&);
template <int N> T& semantic_channel(); template<> T& semantic_channel<0>() { return red; } template<> T& semantic_channel<1>() { return green; } template<> T& semantic_channel<2>() { return blue; } };
The only catch is that it is illegal to create full specialization (semantic_channel<0>) inside a partially specialized class, which requires us instead to use a channel_accessor class.
You could use T& semantic_channel(boost::mpl::int_<0>) { return red; } and in some "very" base class template<typename U> void semantic_channel(U) { //Something's wrong with client code if it've triggered BOOST_STATIC_ASSERT(sizeof(U) != 0); }
We are investigating a more compact representation, for example using mpl::vector_c<int,2,1,0>. Once you make it working and add some generalization be sure you'll get my layout ! ;)
between RBG and CMYK (the RGB to CMYK code will be reused.) Another example - the I/O code will allow you to read into an RBG image, (as long as RGB is supported for the given file format).
About IO: If I understand correctly you in Adobe have "not open-source" IO GIL stuff? Is it correct and would that two versions be the same one day? -- Pavel Chikulaev
Ok. You've pointed out how make a new permutation of any colorspace, but don't you think it's kind of too-level stuff and should be automated?
Yes, it would be nice and if people believe it is important, we can make adding a new permutation even less new code. But there is diminishing return here - it is already easy to create a new permutation and the number of color space permutation that people ever use in practice is very small; we already provide the vast majority of them so people rarely will have to create their own permutation.
I still think you approach is less flexible: 1. I can hardly imagine how you would support all YCbYr 4:4:4, 4:2:2, 4:2:1, 4:2:0, etc. (Especially 4:2:0 one ;) without redutant data) 1. I can hardly imagine how you would support all RGB565, RGB555, RGB888 >etc. with your RGB class or BGR?
Pavel - you are confusing the concept of GIL pixel with a specific design of a particular model. One of the reasons GIL is flexible is that it allows you to use multiple models of the same concept. This is why it is able to abstract away the planar vs. interleaved structure of the image - it has different models for a planar and interleaved pixel reference and iterator. This is why the same GIL algorithm will work for a subsampled view of the image, for a color converted view, for a fully synthetic image view, or even for a run-time specified view - because these are just different models of an image view. We are working on heterogeneous pixel models and models of sub-byte channels. All of your examples above can be modeled in GIL. Some require providing a new pixel model, others may require providing a new image view model. I don't think it is impossible to create a GIL pixel model that allows you to enumerate channels similar to the way you have it in your example. There is a huge number of ways an image may be represented and new ones come up over time. There is an unlimited number of imaging algorithms as well. It is not GIL's objective to have a model for every possible image representation and imaging algorithm. What is important is that we have good concepts that allow people to make extensions to create whatever they need and know that their models will work with the rest of GIL.
2. Perhaps with your "semantic channels" you can create interleaved RGB
image, but do you really think that mixing "colorspace" stuff and how it is >organized in memory is good?
I see your point, but I think it is a matter of terminology. What we call "base color space" could be simply "color space" and "derived color space" could be different; "layout?", "channel permutation?"
You could use T& semantic_channel(boost::mpl::int_<0>) { return red; }
That is a good idea! Someone asked us why we want to put GIL in Boost, since it is already a part of a high-profile library. This is an example - we are already getting good ideas to help us make GIL even better.
About IO: If I understand correctly you in Adobe have "not open-source"
IO GIL stuff? Is it correct and would that two versions be the same one day?
That is incorrect. We don't have a more advanced internal GIL I/O extension. We are working on a higher-level I/O layer that will allow you to register image format modules at run-time. It will use the base GIL I/O extension that we have released; it will just be on top of that. But it will have some dependencies on the Adobe Source Libraries and thus we cannot include it in our Boost proposal. That higher-level I/O layer will be fully open-sourced as well. (We are not using GIL's I/O module internally because our products already know how to read/write image files) That said, we do have some internal GIL extensions that we are not at liberty to open-source. For example, Photoshop Elements 4.0 (shipped last Fall) has the ability to automatically extract human faces in your photographs and present them to you to speed up tagging. It uses an early version of GIL for the resampling and all face detection stuff. The next version of Photoshop will also use GIL but unfortunately I cannot share with you how and where without losing my job :-) Thank you Pavel for all of your suggestions on how to make GIL better. We have not heard from anyone else, except a few minor suggestions. Are other people reviewing/trying out the library? Lubomir
Ok. You've pointed out how make a new permutation of any colorspace, but don't you think it's kind of too-level stuff and should be automated? Yes, it would be nice and if people believe it is important, we can make adding a new permutation even less new code. But there is diminishing return here - it is already easy to create a new permutation and the number of color space permutation that people ever use in practice is very small; we already provide the vast majority of them so people rarely will have to create their own permutation. Actually you came up with word "permutation" :) I think that there shouldn't be any permutation or any derived colorspaces. My point is
Lubomir Bourdev wrote: that we should independently define specific colorspace (i.e. RGB) without any information how precise we store the channel information, and should not make any assumption like all channels should be the size same (your RGB class for example). This is what I call colorspace and concept of an image. Every image with such colorspace should be treated the same way, no matter BGR, RGB or any other kinds of layouts (i.g. interleaved). For example template<typename Image> //or view actually void foo_on_rgb_image_algorithm(Image const & image, where<Image, is_rgb888_colorspace> *= 0); //888 for example But how specific image (or view) organized in memory (or even synthetic like in you example), that's what I call layout. But you mix this from the very beginning (when defined RGB class) till the very end (member functions of a templated class image, with arguments that specify each row alignment). I think it's no good at all.
I still think you approach is less flexible: 1. I can hardly imagine how you would support all YCbYr 4:4:4, 4:2:2, 4:2:1, 4:2:0, etc. (Especially 4:2:0 one ;) without redutant data) 1. I can hardly imagine how you would support all RGB565, RGB555, RGB888 >etc. with your RGB class or BGR? Pavel - you are confusing the concept of GIL pixel with a specific design of a particular model. One of the reasons GIL is flexible is that it allows you to use multiple models of the same concept. This is why it is able to abstract away the planar vs. interleaved structure of the image - it has different models for a planar and interleaved pixel reference and iterator. This is why the same GIL algorithm will work for a subsampled view of the image, for a color converted view, for a fully synthetic image view, or even for a run-time specified view - because these are just different models of an image view. Ok, that's not strange to me.
We are working on heterogeneous pixel models and models of sub-byte channels. All of your examples above can be modeled in GIL. Some require providing a new pixel model, others may require providing a new image view model. I don't think it is impossible to create a GIL pixel model that allows you to enumerate channels similar to the way you have it in your example. So you working now on heterogeneous pixel modes, that's one more proof to me that I'm on a right way, I don't even need to bother me doing so, I already have it.
There is a huge number of ways an image may be represented and new ones come up over time. There is an unlimited number of imaging algorithms as well. It is not GIL's objective to have a model for every possible image representation and imaging algorithm. What is important is that we have good concepts that allow people to make extensions to create whatever they need and know that their models will work with the rest of GIL. I always wanted to implement most of that algorithms, but right now I just don't feel GIL is the platform where I want to do it, sorry :(
2. Perhaps with your "semantic channels" you can create interleaved RGB image, but do you really think that mixing "colorspace" stuff and how it is >organized in memory is good? I see your point, but I think it is a matter of terminology. What we call "base color space" could be simply "color space" and "derived color space" could be different; "layout?", "channel permutation?" No it's not about terminology, it's about mixing absolutely two different things in one.
-- Pavel Chikulaev
But how specific image (or view) organized in memory (or even synthetic
like in you example), that's what I call layout. But you mix this from the very beginning (when defined RGB class) till the very end (member functions of a templated class image, with arguments that specify each row alignment). I think it's no good at all.
There is one important point that I keep repeating but for some reason have failed to get through to you. Let me try again: GIL defines abstract concepts and concrete models of those concepts. Our design principles are that the concepts are as general as possible, to the degree that does not affect the performance and usability of the models. For example, take a look at the RandomAccessNDImageConcept. Does it say anything about the order of channels, or the color space, or that it even operates on pixels? Does it even say that the image is two dimensional? No. For what it's worth, that level of abstraction allows you to create a model of a video clip or a synthetic 3D volume using voxels if you'd like. Then there are refinements of RandomAccessNDImageConcept that allow for 2D images, and further refinements dealing with concrete, memory-based images, with the corresponding additional required functionality. As for the models, you are correct to point out that the models are very much dependent on the particular representation of the image in memory (what you call the "layout"). This is not a design flaw; it is very much intentional, because the models HAVE to know what they are supposed to model. The pixel iterator concept doesn't say anything about planar vs interleaved representation. But there is a planar model of pixel iterator (planar_ptr) and an interleaved model, and they are different and very much dependent on the memory organization they are representing. The users of the library don't have to deal directly or know the specifics of the underlying models. VIEW::x_iterator will return a raw pointer for interleaved images, planar pointer for planar images, step iterator for subsampled images, or whatever is the optimal model that will do the job. But the GIL algorithm need not be concerned with the specifics of the design.
I always wanted to implement most of that algorithms, but right now I just don't feel GIL is the platform where I want to do it, sorry :(
Pavel - you may have given up on us, but we haven't given up on you. Some of the points you make (decoupling the ordering of the channels and more automatic pixel creating) are worth looking into further. Since you obviously have spent a lot of time thinking about and working on a very similar area your input is invaluable. If our submission is successful, we will be sure to give you credit for your suggestions. Also, I don't want to imply that GIL is perfect. GIL is far from perfect, and that is why I am asking the boost list for suggestions for improvements. The concepts need to be further refined, some important models need to be added; we are aware of several improvements and we are working on all of these but I do want to hear about other improvements people might suggest to make sure we are not missing anything. Lubomir
FWIW My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI. regards Andy Little
Andy Little wrote:
FWIW
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
Why? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:e7i1v7$rv$1@sea.gmane.org...
Andy Little wrote:
FWIW
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
Why?
I like to see what going on .... ;-) regards Andy Little
"Andy Little" wrote:
... a cross-platform UI.
Discussion about GUI do appear once or twice a year on mail-list. Quite a few believe that this task is impossible within current Boost framework. Possibly the most close to such ideal may be the next planned version of wxWidgets - wxTNG (The New Generation) http://www.wxwidgets.org/wiki/index.php/WxWidgets3. Using parts of Boost is one of suggested options. wxTNG is, AFAIK, in "thinking about" phase, though. /Pavel
Andy Little wrote:
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
Andy, GIL is designed to solve a very specific problem - abstracting away the image representation from algorithms applied on images. A well-done and complete user interface library is a huge undertaking and is very much orthogonal to the problem of image manipulation. If you need a UI library, one pointer for you are the Adam/Eve libraries at http://opensource.adobe.com They are open-source, very much Boost-friendly, cross-platform and widely used commercially (we use them for our products too). We are also working on having a GIL integration with the Adam/Eve libraries (the picture widget will be a GIL image) Lubomir
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
FWIW
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
I can't imagine what a cross-platform UI has to do with an imaging library. It seems like one could make the same demand of any library that works on something visualizable. If we used that criterion we wouldn't have the Boost Graph library, or uBlas, or, heck, a smart pointer library either. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes:
FWIW
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
I can't imagine what a cross-platform UI has to do with an imaging library. It seems like one could make the same demand of any library that works on something visualizable. If we used that criterion we wouldn't have the Boost Graph library, or uBlas, or, heck, a smart pointer library either.
I strongly disagree. An image is a very specific physical entity, in the context the word is being used here, a Graphical image. In computing terms and AFAICS from reading the GIL docs. An image is comprised of a grid of pixels. Within that grid pixel(x1,y1) is specifically either above or below or at the same level as pixel(x2,y2) and is either to the left of or to the right of or in the same x position as (x2,y2). That is a physical description. Similarly the colour of that pixel is a physical thing. IOW an image is a physical entity. In the vast majority of use the purpose of that image is to communicate directly to a human being. An image is the physical interface for human machine interaction as is the case on a computer monitor. Within a photographic image by means of perspective the user will instictively imagine physical depth. etc, etc.... A graph OTOH is a mathematical abstraction far removed from any phemomenon it is trying to represent. A pointer is similarly an abstraction far removed from the electronic phemonena Both Graphs and pointers are also widely computing entities with very widespread general purpose use. Neither Graphs or pointers need a viewer for a user to make sense of them Imaging OTOH is a specialised area. Fact is you need a Viewer of some kind to work with them in any meaningful way. I am being slightly cheeky and trying to probe as to whether the Adobe guys would also be willing to share some of their cross platform viewing technology with boost as a companion to or part of their GIL proposal. Imagine how impressive the GIL examples would be if the library came with a viewer. Heck you could even use it for BGL and little memory boxes representing pointers if you felt the need. but, whatever... regards Andy Little
"Andy Little" writes:
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
Displaying images on the screen has nothing to do with image-handling library. That's what I would expect from image handling library (just few examples): - Changing image brightness, - adjusting gamma levels, - changing color modes, - converting from CMYK to YCbCr, - scaling using various interpolation methods, - rotating. - provide an access method for OTHERs who want to display the image on the screen (or somewhere else), it's not even the UI (or the printer) that displays this image - it is something in between. - etc.. - Image I/O in various formats (tiff,jpg,png) is just an extra bonus here. cross platform UI is completely unrelated, because it does following things: - windows with menus - buttons and widgets to click - drop down menus - provides display context for OTHER methods that can display something within the context provided (eg. displaying text of this email you are reading, displaying some OpenGL 3D graphics stuff, and eventually displaying an image) - etc... Andy: That's so unrelated I can't imagine how you would want to combine them. Lubomir Bourdev: can you confirm my expectations? How difficult would it be to add YCbCr color space? (My work with experimental data requires extracting Y component from digital camera picture) -- Janek Kozicki |
Janek Kozicki wrote:
"Andy Little" writes:
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
Displaying images on the screen has nothing to do with image-handling library.
That's what I would expect from image handling library (just few examples): - Changing image brightness, - adjusting gamma levels, - changing color modes, - converting from CMYK to YCbCr, - scaling using various interpolation methods, - rotating. - provide an access method for OTHERs who want to display the image on the screen (or somewhere else), it's not even the UI (or the printer) that displays this image - it is something in between. - etc.. - Image I/O in various formats (tiff,jpg,png) is just an extra bonus here.
What about image *processing* ? Things like - sharpening, smoothing, thresholding, dilation, erosion - compression, FFTs, wavelets - feature detection, segregation - morphing There is indeed a whole lot of things that are done with images without any need for a GUI. And even if displaying images would be part of it, it's most often enough to be able to dump the image on some kind of 'surface' or 'canvas', without having to know anything about widgets etc. In short: I fully agree. A library such as GIL should not care about a GUI. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld said: (by the date of Sat, 24 Jun 2006 10:39:00 -0400)
Janek Kozicki wrote:
Displaying images on the screen has nothing to do with image-handling library.
That's what I would expect from image handling library (just few examples): - Changing image brightness, - adjusting gamma levels, - changing color modes, - converting from CMYK to YCbCr, - scaling using various interpolation methods, - rotating. - provide an access method for OTHERs who want to display the image on the screen (or somewhere else), it's not even the UI (or the printer) that displays this image - it is something in between. - etc.. - Image I/O in various formats (tiff,jpg,png) is just an extra bonus here.
What about image *processing* ? Things like
- sharpening, smoothing, thresholding, dilation, erosion - compression, FFTs, wavelets - feature detection, segregation - morphing
I have only quickly skimmed through GIL docs, so I don't know if GIL provides *processing* algorithms. It would be nice to have that. But maybe due to the fact the the number of such *processing* methods is almost infinite (just look at how many plugins GIMP has) I rather expect this library to provide an easy interface to implement any (and all) of those that you mentioned above. -- Janek Kozicki |
Janek Kozicki wrote:
Stefan Seefeld said: (by the date of Sat, 24 Jun 2006 10:39:00 -0400)
Janek Kozicki wrote:
Displaying images on the screen has nothing to do with image-handling library.
That's what I would expect from image handling library (just few examples): - Changing image brightness, - adjusting gamma levels, - changing color modes, - converting from CMYK to YCbCr, - scaling using various interpolation methods, - rotating. - provide an access method for OTHERs who want to display the image on the screen (or somewhere else), it's not even the UI (or the printer) that displays this image - it is something in between. - etc.. - Image I/O in various formats (tiff,jpg,png) is just an extra bonus here. What about image *processing* ? Things like
- sharpening, smoothing, thresholding, dilation, erosion - compression, FFTs, wavelets - feature detection, segregation - morphing
I have only quickly skimmed through GIL docs, so I don't know if GIL provides *processing* algorithms. It would be nice to have that. But maybe due to the fact the the number of such *processing* methods is almost infinite (just look at how many plugins GIMP has) I rather expect this library to provide an easy interface to implement any (and all) of those that you mentioned above.
I agree. I didn't mean to suggest that all the above should be added to GIL itself. Rather, my point was that there are many situations where images are dealt with in a non-interactive (and, in particular, non-GUI) way. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
I have only quickly skimmed through GIL docs, so I don't know if GIL provides *processing* algorithms. It would be nice to have that. But maybe due to the fact the the number of such *processing* methods is almost infinite (just look at how many plugins GIMP has) I rather expect this library to provide an easy interface to implement any (and all) of those that you mentioned above.
I agree. I didn't mean to suggest that all the above should be added to GIL itself. Rather, my point was that there are many situations where images are dealt with in a non-interactive (and, in particular, non-GUI) way.
Stefan and Janek: As you pointed out, there are infinitely many algorithms that can work with images. All we can do in GIL core is to provide the framework that you can use to write your algorithms. We are hoping other developers can join us and contribute algorithms. One possibility is that we have an "algorithm" extension to GIL possibly as a follow-up submission. Lubomir
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
A graph OTOH is a mathematical abstraction far removed from any phemomenon it is trying to represent.
I could argue that point effectively, but I don't need to.
A pointer is similarly an abstraction far removed from the electronic phemonena
Really? I thought memory addressing goes down to a pretty fundamental level in most computers. Well, nevermind that...
Both Graphs and pointers are also widely computing entities with very widespread general purpose use.
Yes. Images aren't widely used for many different purposes?
Neither Graphs or pointers need a viewer for a user to make sense of them
Against both of those assertions there are good arguments. For pointers consider the popularity of http://www.gnu.org/software/ddd/. For graphs... well, have you ever tried to understand a graph that's given some non-graphical presentation? It's possible for small graphs, but http://www.tomsawyer.com/home/index.php has a market with good reason.
Imaging OTOH is a specialised area. Fact is you need a Viewer of some kind to work with them in any meaningful way.
And there are hundreds of image viewers available, many of them free. There's no reason Boost has to provide one. And a viewer is a far cry from being a UI for the library. The library does image _manipulation_.
I am being slightly cheeky and trying to probe as to whether the Adobe guys would also be willing to share some of their cross platform viewing technology with boost as a companion to or part of their GIL proposal.
So OTOH you were not making a serious objection to the library proposal?
Imagine how impressive the GIL examples would be if the library came with a viewer.
I don't see how it would make the examples any more impressive. The library docs would surely have lots of pictures.
Heck you could even use it for BGL and little memory boxes representing pointers if you felt the need.
Now I'm totally lost. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams said: (by the date of Sat, 24 Jun 2006 12:46:54 -0400)
Neither Graphs or pointers need a viewer for a user to make sense of them
Against both of those assertions there are good arguments. For pointers consider the popularity of http://www.gnu.org/software/ddd/.
Awesome software! I'm going to try it, thanks :) -- Janek Kozicki |
On Sat, 2006-06-24 at 13:35 +0100, Andy Little wrote:
"David Abrahams" wrote
"Andy Little" writes:
FWIW
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
I can't imagine what a cross-platform UI has to do with an imaging library. It seems like one could make the same demand of any library that works on something visualizable. If we used that criterion we wouldn't have the Boost Graph library, or uBlas, or, heck, a smart pointer library either.
I strongly disagree.
I strongly disagree too. An image is nothing more than a multi- dimensionnal array of values. What the values are is totally user- dependent... Of course, there are some treatments (filtering, pdes, conversions, resizing, roi, ...) that are meaningful for images. I'd expect an image class to derive from an array class (which would eventually manage the all the storage problems (tiling/alignment/interleaving/....) and to provide such image specific capabilities. I skimmed quickly through GIL's documentation. Basically, I like the concepts (they look like the ones I use in my own Image library). The major drawbacks I see are (CAUTION: I may be wrong as I just had a very quick look at the design and the tutorial documents): - the iterators seem somewhat restrictive. There is no way to iterate over lines or colums of an image (which is useful eg for filtering). Also, I'm not sure what would be the efficiency of implementing eg image differences using iterators (for that you need to iterate over two similar images)... Often, one may want to iterate over the domain of one image to access an another one... - I'm not sure that the interleaving/alignment/structure really belongs in an image class. For me, it's often more an implementation detail related to storage. That being said if that comes at no cost, I have no problems with that... - I do not like the current IO scheme. From the tutorial, it seems that you have to know the image file format (jpeg,png,tiff) at coding time... But the separation between storage and memory layout is IMHO very important. Extensibility also. A plugin system would be great but this is certainly beyond GIL goals. All that being said, I'm certainly biased by my mathematical/image processing background for which images are somewhat much more than something you display on a screen. But besides these potential drawbacks, GIL is certainly a step in the right direction.
- the iterators seem somewhat restrictive. There is no way to iterate over lines or colums of an image (which is useful eg for filtering).
You can iterate over the rows (VIEW::x_iterator), over the columns (VIEW::y_iterator), or over all pixels in the image (VIEW::iterator). You can also navigate in 2D over the image (VIEW::xy_locator)
Also, I'm not sure what would be the efficiency of implementing eg image differences using iterators (for that you need to iterate over two similar images)...
GIL's constructs are very lightweight. For example, the x_iterator for a simple interleaved image is a raw C pointer. It is not even wrapped in a class, so it has zero abstraction penalty. The y_iterator consists of a raw pointer plus an integer step - 8 bytes.
- I'm not sure that the interleaving/alignment/structure really belongs in an image class. For me, it's often more an implementation detail related to storage.
And storage/ownership is exactly what GIL's image class is designed to do. The preferred way to access the pixels of an image is through an image view (which you can get from an image). Image views don't deal with interleaving, alignment and concrete memory structure.
A plugin system would be great but this is certainly beyond GIL goals.
GIL extensions are the closest to what you call a "plugin system". These are modules (such as I/O) that focus on specific domains. Lubomir
I do not like the current IO scheme.
I agree with you. Our I/O is very low-level. We only handle some of the most popular image formats, and of these we only handle the most common modes. There is a lot more that could be done in I/O but, similar to GUI, this is peripheral to GIL's design objective. I was against us releasing the I/O extension at all. But how do you try an imaging library without I/O? One consideration for you guys is, should you take GIL, whether to take the I/O module as well.
From the tutorial, it seems that you have to know the image file format (jpeg,png,tiff) at coding time...
We used to have methods like read_image that checked the image file extension and called the appropriate jpeg_read_image, tiff_read_image, etc. While they are convenient, we removed them from the public distribution because they were inherently very constrained. If you add a new module you have to go and add another case to the switch statement, etc. Another problem with them is that they require you to compile and link against all available I/O libraries (libjpeg, libtiff, libpng). The current I/O is more modularized - you need to only link against the file formats you need. A better attempt at this (where you can register file format modules dynamically) is in the works in ASL. Lubomir
Lubomir Bourdev wrote:
But how specific image (or view) organized in memory (or even synthetic like in you example), that's what I call layout. But you mix this from the very beginning (when defined RGB class) till the very end (member functions of a templated class image, with arguments that specify each row alignment). I think it's no good at all.
There is one important point that I keep repeating but for some reason have failed to get through to you. Let me try again: Seems I failed do the same job too ;)
GIL defines abstract concepts and concrete models of those concepts.
Our design principles are that the concepts are as general as possible, to the degree that does not affect the performance and usability of the models. For example, take a look at the RandomAccessNDImageConcept. Does it say anything about the order of channels, or the color space, or that it even operates on pixels? Does it even say that the image is two dimensional? No. For what it's worth, that level of abstraction allows you to create a model of a video clip or a synthetic 3D volume using voxels if you'd like.
Then there are refinements of RandomAccessNDImageConcept that allow for 2D images, and further refinements dealing with concrete, memory-based images, with the corresponding additional required functionality. But there you have row alignment support - Why?
As for the models, you are correct to point out that the models are very much dependent on the particular representation of the image in memory (what you call the "layout"). This is not a design flaw; it is very much intentional, because the models HAVE to know what they are supposed to model. The pixel iterator concept doesn't say anything about planar vs interleaved representation. But there is a planar model of pixel iterator (planar_ptr) and an interleaved model, and they are different and very much dependent on the memory organization they are representing.
The users of the library don't have to deal directly or know the specifics of the underlying models.
What's the point of BGR class then?
VIEW::x_iterator will return a raw pointer for interleaved images, planar pointer for planar images, step iterator for subsampled images, or whatever is the optimal model that will do the job.
BTW, I would reject "view" concept at all, since it's actually same as "image" concept because every subset of original image (such as subsampled one) is still an image :)
I always wanted to implement most of that algorithms, but right now I just don't feel GIL is the platform where I want to do it, sorry :( Pavel - you may have given up on us, but we haven't given up on you. Some of the points you make (decoupling the ordering of the channels and more automatic pixel creating) are worth looking into further. Since you obviously have spent a lot of time thinking about and working on a very similar area your input is invaluable. If our submission is successful, we will be sure to give you credit for your suggestions.
Thanks for your patience and politeness to expain all your points to such a bad listener as I am, and I think I shouldn't have acted that way. Yeah it's still true that I like my way more, but my library is nowhere near what your GIL already have now, so I urge you to ask for a formal review. And I'm not planning for a submission at least for a while, and if your library is accepted by that time, I actually see no reason to submit my library then. P.S. I think you should add support for sRGB too ;), of course if you haven't done that already. -- Pavel Chikulaev
Then there are refinements of RandomAccessNDImageConcept that allow for 2D images, and further refinements dealing with concrete, memory-based images, with the corresponding additional required functionality. But there you have row alignment support - Why?
The image owns the pixels and is responsible for allocating the memory for the pixels. Some algorithms run more efficiently when each row of the image is word-aligned, or even 16-byte aligned. This is why when you create an image you can specify if and how you want your rows to be aligned. This is again not in the image concept, but in the underlying model (probably should be in the concept...) Why is that a problem?
The users of the library don't have to deal directly or know the specifics of the underlying models.
What's the point of BGR class then?
I am not sure I understand your question. bgr_t class is a tag that specifies the set of channels and the interpretation of each one. You need this when you want to create a BGR image, for example. It is just a tag class similar to your tag class: struct rgb_t { typedef rgb_t base; BOOST_STATIC_CONSTANT(int, num_channels=3); }; struct bgr_t : public rgb_t {}; As you can see, if you are interested in just the color space and not the channel permutation, you can use bgr_t::base
BTW, I would reject "view" concept at all, since it's actually same as "image" concept because every subset of original image (such as subsampled one) is still an image :)
In our earlier designs we used the same class for an image and a view. The pixel ownership was determined with a smart pointer. Then Alex Stepanov and Sean Parent convinced me to split these into two. Originally I thought it will unnecessary complicate things, but now I think this was the right decision. An "image" is a container of pixels. It allocates them, does a deep-copy, a deep-compare, etc. The STL equivalent is a container like std::vector An "image view" is a shallow range. It doesn't own the pixels, doesn't propagate its constness to them, just contains a raw pointer to them. Does a shallow-copy, shallow-compare, etc. This is equivalent to the STL ranges, which are often represented as a pair of iterators. GIL algorithms typically operate on image views (similarly, STL algorithms typically operate on ranges). Splitting these two makes the ownership semantics very clear.
Thanks for your patience and politeness to expain all your points to such a bad listener as I am, and I think I shouldn't have acted that way.
Pavel - please do keep your questions and comments coming. And criticisms are more helpful to us than praises :-) Lubomir
Lubomir Bourdev wrote:
Pavel's concern was that every channel permutation (like BGR, for example) requires creating a new color space, which seems inflexible.
I think his concern is in part a misunderstanding based on terminology. In both GIL and his example, to support BGR we have to write some new code - in GIL we call it "derived color space" while Pavel calls it "layout"
"Derived color space" is only a small subset of "layout".
But let me point out that: 1. Adding a channel permutation (like BGR) requires very little new code 2. All channel-level support (assignment, copy-construction, etc) will automatically work for BGR 3. All the algorithms that operate on RGB will automatically work for BGR (unless explicitly prevented).
Ok. You've pointed out how make a new permutation of any colorspace, but don't you think it's kind of too-level stuff and should be automated? I still think you approach is less flexible: 1. I can hardly imagine how you would support all RGB565, RGB555, RGB888 etc. with your RGB class or BGR? 2. Perhaps with your "semantic channels" you can create interleaved RGB image, but do you really think that mixing "colorspace" stuff and how it is organized in memory is good?
In detail: ___1. Adding a channel permutation (like BGR) requires very little new code The only changes that you need to do to make BGR are more or less the following: struct bgr_t : public rgb_t {}; template <typename T> struct color_base<T,bgr_t> { T blue,green,red; color_base() {} color_base(T v0, T v1, T v2) : blue(v0),green(v1),red(v2) {} template <typename T1, typename C1> color_base(const color_base<T1,C1>&);
template <int N> T& semantic_channel(); template<> T& semantic_channel<0>() { return red; } template<> T& semantic_channel<1>() { return green; } template<> T& semantic_channel<2>() { return blue; } };
The only catch is that it is illegal to create full specialization (semantic_channel<0>) inside a partially specialized class, which requires us instead to use a channel_accessor class.
You could use T& semantic_channel(boost::mpl::int_<0>) { return red; } and in some "very" base class template<typename U> void semantic_channel(U) { //Something's wrong with client code if it've triggered BOOST_STATIC_ASSERT(sizeof(U) != 0); }
We are investigating a more compact representation, for example using mpl::vector_c<int,2,1,0>. Once you make it working and add some generalization be sure you'll get my layout ! ;)
between RBG and CMYK (the RGB to CMYK code will be reused.) Another example - the I/O code will allow you to read into an RBG image, (as long as RGB is supported for the given file format).
About IO: If I understand correctly you in Adobe have "not open-source" IO GIL stuff? Is it correct and would that two versions be the same one day? -- Pavel Chikulaev
Hi, I'm also interested in an image library for boost. Although my use would be pretty limited. Only save/load a few images. And save screenshots from within the program. Save screenshots is a bit interesting part, because I plan to use it without the picture being displayed on the screen, only in memory. A bit modified TinyGL (written by Fabrice Bellard) software renderer will render the picture to the memory, then save it into a file. That will be used only for the purpose of saving "sceenshots" of a simulation that runs from command line. Nice part of that is that drawing into the memory is done via openGL interface. you can have a look at (if you haven't already): http://www.boost.org/more/submission_process.htm -- Janek Kozicki |
On Monday 05 June 2006 13:57, Lubomir Bourdev wrote:
We just released the first version of our I/O extension, but we haven't updated the documentation yet. It supports JPEG, TIFF and PNG. It supports run-time instantiated images, so you can load the image in its native color space and channel depth.
Our I/O operates at a very base level - like load the image in a given format from a given file. If you use GIL inside ASL you will get extra goodies - such as a dynamic registration of I/O modules and tighter integration with Adam/Eve libraries.
I'm curious about how your library communicates the type of pixel data contained in an image. For example, TIFF can hold integral data of various sizes, floating point data, or complex data. If a user passes my application the path to a TIFF image, how would I determine the type of data contained in the image? Am I supposed to use any_image::_dynamic_cast() within a series of try/catch blocks? D.
Daniel Mitchell wrote:
I'm curious about how your library communicates the type of pixel data
contained in an image.
I presume you need to know so you know what type of image to give it? There are three scenarios: 1. If you know what channel type and color space the image on disk is, you can use jpeg_read_image passing it an image of the right color space / channel. If you are wrong an exception is thrown. (You don't have to get the channel permutations correct by the way - you can read an rgb image into a bgr destination) 2. If you don't know the image format on disk is but you just need the image in a specific color space and channel depth, you can use jpeg_read_and_convert_image passing it the type of image that you need. As long as color space and channel depth conversion is provided between the source and target color space and channel depth, this will read the image and color convert. It does it on the fly (doesn't need to store the image data and then color-convert) 3. If you don't know the image format on disk and you want to read the image in its native color space and channel depth, you must use jpeg_read_image passing it a run-time specified image (any_image). The I/O code will try to match the image on disk with any of the allowed types of your run-time image (as always, channel permutations are ignored) and if a match is found it will read and instantiate the image in that format. If none of the allowed image types of your any_image is a match it will throw an exception. For all of the above, instead of images you can use views (templated or any_image_view). The calls are jpeg_read_view, jpeg_read_and_convert_view. Using a view transformation, this allows you to do some very powerful things, like fetch a subimage of your large image from disk (using subimage_view) or read the image upside down, etc, all without using any extra memory and without copying the data. Image views don't own the pixels. Loading into a view will not allocate extra memory. However, the dimensions of your image on disk must match that of the view or else an exception is thrown. All of the above apply for TIFF and PNG, just replace jpeg_ with tiff_ and png_ Lubomir
On 6/5/06, Lubomir Bourdev <lbourdev@adobe.com> wrote:
We just released the first version of our I/O extension, but we haven't updated the documentation yet. It supports JPEG, TIFF and PNG. It supports run-time instantiated images, so you can load the image in its native color space and channel depth.
Our I/O operates at a very base level - like load the image in a given format from a given file. If you use GIL inside ASL you will get extra goodies - such as a dynamic registration of I/O modules
Hi, Do you have any examples of this dynamic registration code and how to use it? My company currently uses something like this for other image types, and I am interested how yours works and how to possibly roll our image readers into your framework. Chris
Chris, This is in ASL domain. I encourage you to post this question on ASL's discussion forum at http://opensource.adobe.com Lubomir
Hi, Do you have any examples of this dynamic registration code and how to use it?
On Sun, 4 Jun 2006 21:46:01 -0700, "Lubomir Bourdev" <lbourdev@adobe.com> wrote:
Hello,
[...]
Is there an interest for having GIL be a boost library?
Hi, I haven't looked at the code yet but definitely there's interest for an image library here. May I ask you to drop me a mail in case you submit it to boost? I cannot guarantee I will be following the list in the next days but I would really like to follow this closely. I know this is somewhat against netiquette but I guess people here know I'm not in the habit of asking such things; please consider this an exceptional circumstance. Thanks a lot. --Gennaro.
Lubomir Bourdev wrote:
Is there an interest for having GIL be a boost library?
I took a tiny look at the documentation and I'm curious as to why you want to make it a boost library. It's already part of a prestigious high visibility group. That is, what benefit would be had by adding it to boost that it doesn't already have? Would this added benefit be worth the extra work? Robert Ramey
On Mon, 5 Jun 2006 07:26:52 -0700, "Robert Ramey" <ramey@rrsd.com> wrote:
Lubomir Bourdev wrote:
Is there an interest for having GIL be a boost library?
I took a tiny look at the documentation and I'm curious as to why you want to make it a boost library. It's already part of a prestigious high visibility group. That is, what benefit would be had by adding it to boost that it doesn't already have? Would this added benefit be worth the extra work?
I hope "making it part of a prestigious group" isn't the rationale for any of the boost inclusion proposals; oddly enough, a few days ago I was discussing with a friend who also is a boost member, and we identified this as a possible cause for the lack of maintenance that some boost libraries are experiencing; if you see inclusion as a sort of "award" then once you get the library accepted you have no more "goals" to pursue and likely lose interest in your creature. --Gennaro.
Gennaro Prota wrote:
On Mon, 5 Jun 2006 07:26:52 -0700, "Robert Ramey" <ramey@rrsd.com> wrote:
Lubomir Bourdev wrote:
Is there an interest for having GIL be a boost library?
I took a tiny look at the documentation and I'm curious as to why you want to make it a boost library. It's already part of a prestigious high visibility group. That is, what benefit would be had by adding it to boost that it doesn't already have? Would this added benefit be worth the extra work?
I hope "making it part of a prestigious group" isn't the rationale for any of the boost inclusion proposals; oddly enough, a few days ago I was discussing with a friend who also is a boost member, and we identified this as a possible cause for the lack of maintenance that some boost libraries are experiencing; if you see inclusion as a sort of "award" then once you get the library accepted you have no more "goals" to pursue and likely lose interest in your creature.
OK - but I'm still curious: "What is the motivation to take on the extra work of making it part of boost?" Robert Ramey
Robert Ramey wrote:
OK - but I'm still curious: "What is the motivation to take on the extra work of making it part of boost?"
Well for us, we limit our use of 3rd party libraries. boost is seen as one library, not a collection of libraries, which is an extension of the STL, so for us, the more functionality the better. Cheers Russell
"Robert Ramey" wrote:
OK - but I'm still curious: "What is the motivation to take on the extra work of making it part of boost?"
Boost became kind of brand that gets accepted "as is" by some development teams. Other 3pp libraries may be discouraged, forbidden or require detailed examination. /Pavel
On 6/5/06, Pavel Vozenilek <pavel_vozenilek@hotmail.com> wrote:
"Robert Ramey" wrote:
OK - but I'm still curious: "What is the motivation to take on the extra work of making it part of boost?"
Boost became kind of brand that gets accepted "as is" by some development teams.
Other 3pp libraries may be discouraged, forbidden or require detailed examination.
The various legal hurdles and examinations that need to be overcome just to be able to use 3rd party software on our projects is huge. We made the choice to go through with it for Boost because we felt if was important enough for us in our development. However, I would love to be using the Adobe::forest right now, but that's not an option without going through the months long struggle of getting another vendor approved. --Michael Fawcett
"Robert Ramey" <ramey@rrsd.com> writes:
Gennaro Prota wrote:
On Mon, 5 Jun 2006 07:26:52 -0700, "Robert Ramey" <ramey@rrsd.com> wrote:
Lubomir Bourdev wrote:
Is there an interest for having GIL be a boost library?
I took a tiny look at the documentation and I'm curious as to why you want to make it a boost library. It's already part of a prestigious high visibility group. That is, what benefit would be had by adding it to boost that it doesn't already have? Would this added benefit be worth the extra work?
I hope "making it part of a prestigious group" isn't the rationale for any of the boost inclusion proposals; oddly enough, a few days ago I was discussing with a friend who also is a boost member, and we identified this as a possible cause for the lack of maintenance that some boost libraries are experiencing; if you see inclusion as a sort of "award" then once you get the library accepted you have no more "goals" to pursue and likely lose interest in your creature.
OK - but I'm still curious: "What is the motivation to take on the extra work of making it part of boost?"
The authors can speak for themselves, but I can think of a few. * Boost is standards track * The review process is educational and usually improves libraries * More eyes on the code/docs improves libraries * Exposure to more users I welcome a Boost library contribution from Adobe programmers. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Mon, 05 Jun 2006 13:31:25 -0400, David Abrahams <dave@boost-consulting.com> wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
[...]
OK - but I'm still curious: "What is the motivation to take on the extra work of making it part of boost?"
The authors can speak for themselves, but I can think of a few.
Yes. In fact I was waiting for them to speak before stating my opinion.
* Boost is standards track * The review process is educational and usually improves libraries * More eyes on the code/docs improves libraries * Exposure to more users
Though these are important points I think there's one aspect which is probably the most important of all: our testing. I doubt there's any other library collection around that gets so much organized regression testing, on so many compilers and platforms. It's my opinion that this fact alone may be worth the effort of boostifying. --Gennaro.
Lubomir Bourdev wrote:
Hello,
We have developed the Generic Image Library (GIL) - a library that abstracts away the image representation from algorithms written for images. It allows for writing the algorithm once and having it work for images in any color space, channel depth and pixel organization with performance comparable to writing the code for each specific image format.
GIL is currently part of the Adobe Open Source Libraries and we use it for several imaging projects inside Adobe. Its only dependency is boost.
You can find the sources and documentation at GIL's home page:
http://opensource.adobe.com/gil
Is there an interest for having GIL be a boost library? Also, I would appreciate any recommendations for improving the design of GIL.
Sure there is, but I do think that this library is not flexible enough - image layout (RGB and RGB classes). I've got my own small library that is on an early stage of development. Some examples of library: Example 1. Defining your own image format with default planar layout: namespace rgb { struct tag; struct red {} const red; struct green {} const green; struct blue {} const blue; } typedef colorspace< rgb::tag, channels< channel<struct rgb::red, bits<8> >, //or uint8 channel<struct rgb::green, bits<8> >, //can be also float for example channel<struct rgb::blue, bits<8> > > rgb24_colorspace; typedef image<rgb24_colorspace> rgb8_image; void foo() { rgb24_image img; using namespace rgb; img.resize(100, 100); img(0, 0, red) = 255; img(0, 0, blue) = 25 img(1, 1) = rgb8_image::pixel_type(128, 128, 128); } For every colorspace one could define layout. The default is planar (in terms of GIL) (i.g. R G B R G B). To layout data in B G R order or some other there is no need to change the colorspace as you have to do in GIL. Example of layout declaration: typedef layout< rgb24_colorspace, row_major, alignment< row_alignment<4> >, allocator<std::allocator>, position< interleaved, // B B B B ... G G G G ... R R R R ... positions<struct rgb::blue, struct rgb::green, struct rgb::red> >
my_rgb24_layout;
typedef image<rgb24_colorspace, my_rgb24_layout> myrgb24image; Other features: * Images with same colorspaces but different layouts are treated the same way. * Mutable and immutable views of image are available, such as channel_view (mutable). * Row, column, channel, different sliding-windows and layout-specific iterators are available. * Abilility to add custom implicit and explicit colorspace transformation algorithms (such as sRGB to CIE Lab). * Pixel-to-Pixel transformations on images. * Predefined support for RGB(sRGB and Adobe RGB), RGBA, CMY, CMYK, HSV, HSL, CIE Lab, CIE Luv, XYZ, YCbCr colorspaces and transformations between them. * Some algorithms on images (FIR filtering, contrast enhancement, histogram equalization, etc). Unresolved issues: * Whether support packed formats such as RGB565, RGB555 or not... * Whether support indexed images or not... The current implementation uses state-of-the-art Boost.Fusion library. Is there any interest and need in such additional flexibility (with some compile-time cost of course) ? -- Pavel Chikulaev
participants (19)
-
Andy Little -
Chris Weed -
Daniel Mitchell -
David Abrahams -
Gennaro Prota -
Janek Kozicki -
Jeff Garland -
Joel de Guzman -
John Maddock -
Jose -
Lubomir Bourdev -
Martin Wille -
Michael Fawcett -
Pavel Chikulaev -
Pavel Vozenilek -
Robert Ramey -
Russell Hind -
Stefan Seefeld -
Theodore Papadopoulo