From: Christian Henning (chhenning_at_[hidden])
Date: 2008-04-25 10:43:10
> I really think that all of the other formats are important. Hopefully
> Lubomir does make them an official part of gil, or an official extension
> that can be part of the boost svn.
I'll discuss it with Lubomir. I rather believe that we should divide
gil into seperate modules. One for the core part, meaning the
infrastructure code without specific code for color spaces, etc. And
then, there should be extensions for all the color spaces, io, image
variants, algorithms, etc. Also, gil might consider having it's own
review procedure. This might fasten up inclusion of new extensions and
also takes burden away from boost. After all the extensions are
gil-specific and don't impact boost very much. What do you think?
> > Can you try to compile again?
> I fixed some parts, but it still fails.
> g++ is really picky about dependant names. When a base class is
> dependant on a template parameter, I think you need to use 'this->' in
> order to let the compiler know that the symbol comes from a base class
> instead of the global scope. I attached a patch, which was created
> inside the io_new folder.
I'll change the code, asap.
> Also, there are references to deail::read_and_no_convert used in
> read_image.hpp. I can not find a declaration for read_and_no_convert,
> did you forget to add a file to svn?
read_and _no_convert is defined in conversion_policies.hpp.
> > Are you planning on using the lib?
> I will probably use the library, but I am not ready to switch yet
> (timing issues).
> Is it possible to have read_image deduce the file format from the file /
> filename itself? That feature would make a gil io lib. perfect for me.
I was thinking of adding that, as well. But it would introduce the
dependency to boost::filesystem. Not sure if that's advisable since
the io lib wouldn't be header only anymore.
Thanks for your effort,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk