John,

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, Christian