Hi there, over the past few months I have been working on a new version of gil's io extension. In this release I've added support for: * more image formats, most importantly bit_aligned images ( like 1bit images ), * reading of subimages like one row at a time for huge images, * reading image information, only. * having a unified interface for all sorts of devices, subimages, and converter objects. So far, png, jpeg, and tiff images are supported. In the not so distant future there will be bmp and pnm images added. You can grab the current version via subversion from: https://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension... If desired I can supply a zip file to the vault. The images libraries can be grabbed from: ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz ( www.ijg.org isn't responding ) http://www.libpng.org/pub/png/libpng.html http://www.libtiff.org/ It's highly advised to built your own version of the image lib you need. I installed the GNU's binaries for Windows, but unfortunately, I only had problems with them. The library is still header-only. When using boost::filesystem's paths, of course, you add a dependency to the filesystem lib. The Read Interface ------------------------ Reading an image can be done in multiple ways depending on what your need is. Like the old io lib there are 4 different ways of reading images. As there are: * read_image: Read image, the right amount of memory will be allocated beforehand. The supplied image type needs to be compatible with actual image file. * read_view: Read image, the image's memory must be already allocated. The supplied image type needs to be compatible with actual image file. * read_and_convert_image: Same as read_image, but the user can specify an color converter. * read_and_convert_view: Same as read_view, but the user can specify an color converter. There is a new function for reading image information. Since every image format has it's own set of tags, the library defines seperate image_read_info<format_tag> structures. Please see, for instance, the jpeg_tags.hpp header. As for the function parameters the following sections in the same order. 1. String for file name ( std::string, std::wstring, char*, boost::filesystem::path ) OR devices ( FILE*, TIFF*, std::ifstream ) 2. Image or view type 3. Optional: Subimage definition ( top_left corner + dimensions ) 4. Optional: Color converter. This parameter is only valid for converting functions. The default parameter is gil's default_color_converter 5. Format Tag. Reading the image information only takes parameter 1 and 5. Here are some examples for reading images: #include <boost/gil/extension/io_new/jpeg_read.hpp> // Read image information std::string filename( "..\\test_images\\jpg\\found online\\test.jpg" ); image_read_info< jpeg_tag > info = read_image_info( filename, tag_t() ); // Read image FILE* file = fopen( filename.c_str(), "rb" ); rgb8_image_t img; read_image( file, img, tag_t() ); // Read image ifstream in( filename.c_str(), ios::in | ios::binary ); rgb8_image_t img( 136, 98 ); read_view( in, view( img ), tag_t() ); // Read and convert image, use gil's default converter. rgb8_image_t img; read_and_convert_image( filename, img, tag_t() ); // Read a 10x10 subimage, starting from the top_left corner. rgb8_image_t img; read_image( filename, img, point_t( 0,0 ), point_t( 10, 10 ), tag_t() ); I have created some header files to support the old read interface. For example: #include <boost/gil/extension/io_new/jpeg_io_old.hpp> std::string filename( "..\\test_images\\jpg\\found online\\test.jpg" ); rgb8_image_t img( 136, 98 ); jpeg_read_view( filename, view( img ) ); The Write Interface --------------------------- The write interface is a much simpler than the read interface. Here, we only have write_view as the entry point. As for parameters the following sections are supported: 1. String for file name ( std::string, std::wstring, char*, boost::filesystem::path ) or devices ( FILE*, TIFF*, std::ofstream ) 2. View type 3. Optional: image_write_info< FormatTag > 4. Format type The image_write_info<...> structure defines a format specific properties which can be used when writing an image. A good example is jpeg's image quality value. Examples: #include <boost/gil/extension/io_new/tiff_write.hpp> // Write image string filename( "..\\test\\tiff\\test1.tif" ); gray8_image_t img( 320, 240 ); write_view( filename, view( img ), tiff_tag() ); // Write image string filename( "..\\test\\tiff\\test2.tif" ); TIFF* file = TIFFOpen( filename.c_str(), "w" ); rgb8_image_t img( 320, 240 ); write_view( file, view( img ), tag_t() ); I have created some header files to support the old write interface. For example: #include <boost/gil/extension/io_new/tiff_io_old.hpp> string filename( "..\\test\\tiff\\test3.tif" ); gray8_image_t img( 320, 240 ); tiff_write_view( filename, view( img ) ); Supported image formats ------------------------------------- In the process of developing the new version I tried to include as many formats as possible. One consequence is a much higher compilation time. Hopefully, a design review by the community can hint me better ways to reduce it. Also, there are still holes in the support. Most noteably is TIFF, since it can support almost everything. This makes it very hard not to have code explosion during compilation. Here is a list of list of supported formats: TIFF: * Number of samples: 1, 3, 4 ( eg. RGB would be 3 ) * Bits per sample: 1, 2, 4, 8, 16, 32, 64 * planar and interleaved images * indexed images. Indices can be of 1, 2, 4, 8, or 16 bit depth, whereas the palette must a rgb16_image_t. PNG: * gray, gray_alpha, rgb, rgba * bit_depth can be 1, 2, 4, 8, 16 JPEG: * gray, rgb, cmyk, ycck ( will be read as cymk ) Please note, that I'm still in process of testing all these different formats. The primary goal of this new version is to eventually replace the old io library which is part of boost's distribution. Do I need to apply for a review? I'm not sure how to go from here. I know there is still some work to do before a possible review. Documentation is lacking and support for dynamic image needs to be added. But what I want for now is to get some feedback on design and implementation. I would like to thank Lubomir Bourdev and Andreas Pokorny for their most valueable input. Thanks, Christian
Christian Henning wrote:
Hi there, over the past few months I have been working on a new version of gil's io extension. In this release I've added support for:
* more image formats, most importantly bit_aligned images ( like 1bit images ), * reading of subimages like one row at a time for huge images, * reading image information, only. * having a unified interface for all sorts of devices, subimages, and converter objects.
So far, png, jpeg, and tiff images are supported. In the not so distant future there will be bmp and pnm images added.
You can grab the current version via subversion from:
https://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension...
This link seems not publicly available. Do you have an alternative one? Greetings from Bremen, Daniel Krügler
This is my bad. Sorry. It's basically the same address without the 's' in https. Here it is again: http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension/... Christian
From: Christian Henning [mailto:chhenning@gmail.com] Hi there, over the past few months I have been working on a new version of gil's io extension. In this release I've added support for:
I have been reviewing versions of Christian's work and giving him my feedback. While I have yet to do a comprehensive review, I think his I/O extension resolves a lot of the I/O feature requests and should eventually replace the current I/O extension of GIL. Lubomir
Christian Hennig wrote:
Hi there, over the past few months I have been working on a new version of gil's io extension. In this release I've added support for:
* more image formats, most importantly bit_aligned images ( like 1bit images ), * reading of subimages like one row at a time for huge images, * reading image information, only. * having a unified interface for all sorts of devices, subimages, and converter objects.
Thanks for great extension! Why do you take the top-left corner and size as a parameter to read_image? Why not just use read_view? -- John
Hi John,
Why do you take the top-left corner and size as a parameter to read_image? Why not just use read_view?
I'm doing that for the sake of least surprises in the interface. I think I know what you mean but some people might prefer to have the lib be responsible for allocating the memory. For example in the case the image file is in bad shape the lib will throw an exception and no memory would be allocated. Have you tested the lib? Can you compile on Linux? That would be a great help! Thanks, Christian
Have you tested the lib? Can you compile on Linux? That would be a great help!
I'm checking quickly with mingw g++ 3.4.5 on a PC. It does not currently compile. The results and the code I used are attached, so you can tell me if I am misusing the extension. For starters there is a dependancy on another extension called 'toolbox'. You might want to remove that or somhow document that it is necessary, because it is not part of the gil distribution in boost. -- John
John,
I'm checking quickly with mingw g++ 3.4.5 on a PC. It does not currently compile. The results and the code I used are attached, so you can tell me if I am misusing the extension.
Thanks.
For starters there is a dependancy on another extension called 'toolbox'. You might want to remove that or somhow document that it is necessary, because it is not part of the gil distribution in boost.
You're right. I will scope it inside a compiler symbol ( ENABLE_GRAY_ALPHA ) for now. I probably need to talk to Lubomir asking him if he wants to add gray_alpha. It's a pretty straight forward change to the current lib. This reminds me that there are some other additions that should be added. Can you try to compile again? Are you planning on using the lib? Thanks a lot for your time, Christian
You're right. I will scope it inside a compiler symbol ( ENABLE_GRAY_ALPHA ) for now. I probably need to talk to Lubomir asking him if he wants to add gray_alpha. It's a pretty straight forward change to the current lib. This reminds me that there are some other additions that should be added.
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.
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. 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?
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. -- John Index: detail/jpeg_io_read.hpp =================================================================== --- detail/jpeg_io_read.hpp (revision 317) +++ detail/jpeg_io_read.hpp (working copy) @@ -194,28 +194,29 @@ template<typename View> void apply_impl( const View& view ) { - start_decompress(); + + this->start_decompress(); - switch( _info._color_space ) + switch(this->_info._color_space ) { case JCS_GRAYSCALE: - io_error_if(_info._num_components!=1,"reader<jpeg>: error in image data"); + io_error_if(this->_info._num_components!=1,"reader<jpeg>: error in image data"); read_rows<gray8_pixel_t>( view ); break; case JCS_RGB: - io_error_if(_info._num_components!=3,"reader<jpeg>: error in image data"); + io_error_if(this->_info._num_components!=3,"reader<jpeg>: error in image data"); read_rows<rgb8_pixel_t>( view ); case JCS_YCbCr: - io_error_if(_info._num_components!=3,"reader<jpeg>: error in image data"); + io_error_if(this->_info._num_components!=3,"reader<jpeg>: error in image data"); //!\todo add Y'CbCr? We loose image quality when reading JCS_YCbCr as JCS_RGB read_rows<rgb8_pixel_t>( view ); break; case JCS_CMYK: - io_error_if(_info._num_components!=4,"reader<jpeg>: error in image data"); + io_error_if(this->_info._num_components!=4,"reader<jpeg>: error in image data"); read_rows<cmyk8_pixel_t>( view ); break; case JCS_YCCK: - io_error_if(_info._num_components!=4,"reader<jpeg>: error in image data"); + io_error_if(this->_info._num_components!=4,"reader<jpeg>: error in image data"); //!\todo add Y'CbCrK? We loose image quality when reading JCS_YCCK as JCS_CMYK this->_cinfo.out_color_space = JCS_CMYK; read_rows<cmyk8_pixel_t>( view ); @@ -225,7 +226,7 @@ // unknown } - finish_decompress(); + this->finish_decompress(); } template< typename ImagePixel @@ -240,14 +241,14 @@ ); - std::vector<ImagePixel> buffer( _info._width ); + std::vector<ImagePixel> buffer( this->_info._width ); JSAMPLE *row_adr = reinterpret_cast< JSAMPLE* >( &buffer[0] ); //Skip scanlines if necessary. - for( int y = 0; y < _top_left.y; ++y ) + for( int y = 0; y < this->_top_left.y; ++y ) { - io_error_if( jpeg_read_scanlines( &_cinfo + io_error_if( jpeg_read_scanlines( &this->_cinfo , &row_adr , 1 ) !=1 @@ -257,22 +258,22 @@ // Read data. for( int y = 0; y < view.height(); ++y ) { - io_error_if( jpeg_read_scanlines( &_cinfo + io_error_if( jpeg_read_scanlines( &this->_cinfo , &row_adr , 1 ) !=1 , "jpeg_read_scanlines: fail to read JPEG file" ); - _cc_policy.read( buffer.begin() + _top_left.x - , buffer.begin() + _dim.x - , view.row_begin( y ) - ); + this->_cc_policy.read( buffer.begin() + this->_top_left.x + , buffer.begin() + this->_dim.x + , view.row_begin( y ) + ); } //@todo: Finish up. There might be a better way to do that. - while( _cinfo.output_scanline < _cinfo.image_height ) + while( this->_cinfo.output_scanline < this->_cinfo.image_height ) { - io_error_if( jpeg_read_scanlines( &_cinfo + io_error_if( jpeg_read_scanlines( &this->_cinfo , &row_adr , 1 ) !=1 Index: detail/path_spec.hpp =================================================================== --- detail/path_spec.hpp (revision 317) +++ detail/path_spec.hpp (working copy) @@ -75,4 +75,4 @@ }}} -#endif BOOST_GIL_EXTENSION_IO_DETAIL_PATH_SPEC_HPP_INCLUDED +#endif //BOOST_GIL_EXTENSION_IO_DETAIL_PATH_SPEC_HPP_INCLUDED
Christian Henning wrote:
Hi there, over the past few months I have been working on a new version of gil's io extension.
Hi Christian, I'm not currently using gil, though now it has been released in 1.35 I will probably convert some of my existing code to use it. However, I have used the C++ interfaces to libjpeg in a couple of other libraries - ImageMagick and DirectFB - and I thought I'd have a look at your code to see how it compares. My application involves decompressing large JPEGS from digital cameras which are displayed on a pan/zoon user interface, which needs to be responsive despite running on somewhat slow hardware. Here are some comments, some of which are feature requests and others are really just questions for someone who might know a bit more about libjpeg than me: DCT type: libjpeg lets you select one of three different DCT implementations via cinfo.dct_method: integer, normal floating point and a faster floating point algorithm that is less accurate. I have found this faster algorithm to be visually indistinguishable and makes decoding about 1/4 to 1/3 faster overall, and I now use it by default. It would be good to have some way to enable this. Scaled decoding: libjpeg has a mode in which it will scale the image down to 1/2, 1/4 or 1/8 of its native size while decoding (see cinfo.scale_num and cinfo.scale_denom). This is much less expensive than doing the full decode and then scaling. It would be good to have some way of using this. Partial image decoding: I see that you have some code to extract a portion of an image, but that it does this by reading and discarding the unwanted parts. You should certainly be able to avoid doing this for the parts after the wanted portion, as you note in the comments. I have been trying to work out how to avoid doing this work for the earlier parts of the image. It should be possible to skip the expensive DCT for these parts as libjpeg has a mode in which it will perform only Huffman decoding and returns DCT coefficients (jpeg_read_coefficients). However, I've not found a way to ask it to do the DCT (and subsequent steps) for the wanted subset of those values. I believe that it's also possible to skip lines in the JPEG data (i.e. not even doing the Huffman decoding) by looking for an FFDA marker, but I don't see anything in libjpeg to support that. MMX/SSE: It should be possible to get a significant speedup for the DCT using MMX or SSE instructions on x86 machines. Versions of libjpeg that do this have existed, but it seems that they were buggy and not well maintained; Debian stopped shipping theirs. Byte packing: I recall that the output from libjpeg is a packed sequence of red/green/blue values, which you typically then unpack to 32 bits per pixel. Wouldn't it be nice if libjpeg would save it in this format? Rotation: It's possible to rotate a jpeg image inexpensively by fiddling with the DCT coefficients. But I find the same situation as for partial image decoding: having asked libjpeg to decode to DCT coefficients, and then having fiddled with them to effect the rotation, I can see no function that will complete the decoding to pixel values. Maybe I'm missing something. In-memory jpegs: If I get my jpeg data from somewhere other than a file, e.g. from some sort of database, or from an in-memory cache or an mmap()ed file, do you have a way to use it? Regards, Phil.
Hi, 2008/4/27 Phil Endecott <spam_from_boost_dev@chezphil.org>:
Christian Henning wrote:
Hi there, over the past few months I have been working on a new version of gil's io extension. [...]. In-memory jpegs: If I get my jpeg data from somewhere other than a file, e.g. from some sort of database, or from an in-memory cache or an mmap()ed file, do you have a way to use it?
It is possible to read from memory or any other thing that can be treated like a stream. The read and write methods require a "device", there are already implementations for FILE* and std::streams: http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension/... A device should provide {read|write,flush} and seek. It should be easy to implement one for in-memory images. kind regards Andreas Pokorny
Hi Phil, thanks for your email.
I'm not currently using gil, though now it has been released in 1.35 I will probably convert some of my existing code to use it. However, I have used the C++ interfaces to libjpeg in a couple of other libraries - ImageMagick and DirectFB - and I thought I'd have a look at your code to see how it compares. My application involves decompressing large JPEGS from digital cameras which are displayed on a pan/zoon user interface, which needs to be responsive despite running on somewhat slow hardware. Here are some comments, some of which are feature requests and others are really just questions for someone who might know a bit more about libjpeg than me:
DCT type: libjpeg lets you select one of three different DCT implementations via cinfo.dct_method: integer, normal floating point and a faster floating point algorithm that is less accurate. I have found this faster algorithm to be visually indistinguishable and makes decoding about 1/4 to 1/3 faster overall, and I now use it by default. It would be good to have some way to enable this.
Interesting. The new IO interface defines a image_read_info type for each file format. The user can use those structures to either get information from the image that is unimportant for the reader or to set some values that can be used by the reader while reading. Your suggestion would fall into the later. Let me do some research on how to use this flag. As the default I would suggest to use the more expensive but more accurate setting. But of course the documentation will reveal such optimization.
Scaled decoding: libjpeg has a mode in which it will scale the image down to 1/2, 1/4 or 1/8 of its native size while decoding (see cinfo.scale_num and cinfo.scale_denom). This is much less expensive than doing the full decode and then scaling. It would be good to have some way of using this.
That would be another candidate to include in image_read_info.
Partial image decoding: I see that you have some code to extract a portion of an image, but that it does this by reading and discarding the unwanted parts. You should certainly be able to avoid doing this for the parts after the wanted portion, as you note in the comments. I have been trying to work out how to avoid doing this work for the earlier parts of the image. It should be possible to skip the expensive DCT for these parts as libjpeg has a mode in which it will perform only Huffman decoding and returns DCT coefficients (jpeg_read_coefficients). However, I've not found a way to ask it to do the DCT (and subsequent steps) for the wanted subset of those values. I believe that it's also possible to skip lines in the JPEG data (i.e. not even doing the Huffman decoding) by looking for an FFDA marker, but I don't see anything in libjpeg to support that.
I believe the smallest entity to read is by scanline. Because of compression there is no random access for scanlines or parts of a scanline. Though, skipping whole scanlines or parts of scanlines might be problematic. It will require some research some find the right ways. I totally agree on minimizing expensive operations.
MMX/SSE: It should be possible to get a significant speedup for the DCT using MMX or SSE instructions on x86 machines. Versions of libjpeg that do this have existed, but it seems that they were buggy and not well maintained; Debian stopped shipping theirs.
What I have noticed is that I needed to recompile the lib on every different Windows machine itself. I haven't researched it thoroughly but if you compile it yourself using MMX then it might work on one machine but fails on another. Someone here to share his/her experience?
Byte packing: I recall that the output from libjpeg is a packed sequence of red/green/blue values, which you typically then unpack to 32 bits per pixel. Wouldn't it be nice if libjpeg would save it in this format?
libjpeg? Not sure if I can follow here. I think libjpeg only supports interleaved images. When reading a scanline we have a std::vector with the values which then are memcpy'ed into gil::image in the case we only read and not convert. gil's copy_pixels should do that automatically.
Rotation: It's possible to rotate a jpeg image inexpensively by fiddling with the DCT coefficients. But I find the same situation as for partial image decoding: having asked libjpeg to decode to DCT coefficients, and then having fiddled with them to effect the rotation, I can see no function that will complete the decoding to pixel values. Maybe I'm missing something.
I will put it this feature on my todo list. But there are more pressing issues, right now.
In-memory jpegs: If I get my jpeg data from somewhere other than a file, e.g. from some sort of database, or from an in-memory cache or an mmap()ed file, do you have a way to use it?
I remember doing such things at one point in my past. It was for a jpeg streaming application. It worked pretty well and the source code should be somewhere on google groups. For now I haven't thought about such features yet. There are more pressing problems right. Most notably too many template instantiations. Thanks a lot for valuable input. Christian
Christian wrote:
might know a bit more about libjpeg than me:
DCT type: libjpeg lets you select one of three different DCT implementations via cinfo.dct_method: integer, normal floating point and a faster floating point algorithm that is less accurate. I have found this faster algorithm to be visually indistinguishable and makes decoding about 1/4 to 1/3 faster overall, and I now use it by default. It would be good to have some way to enable this.
Interesting. The new IO interface defines a image_read_info type for each file format. The user can use those structures to either get information from the image that is unimportant for the reader or to set some values that can be used by the reader while reading. <snip>
Scaled decoding: libjpeg has a mode in which it will scale
the image
down to 1/2, 1/4 or 1/8 of its native size while decoding (see cinfo.scale_num and cinfo.scale_denom). This is much less expensive than doing the full decode and then scaling. It would be good to have some way of using this.
I think the tiff format, which I beleve was designed to be a kind of meta-format on top of jpeg and others, has a huge slew of 'tags' that you can peruse on the web. I think each tag corresponds tpo som peice of info. that can be read from or written to the underlying image. These might be useful for providing the kinds of parameters that could/should be read or written.
Partial image decoding: I see that you have some code to extract a portion of an image, but that it does this by reading and
the unwanted parts. You should certainly be able to avoid doing this for the parts after the wanted portion, as you note in the comments. I have been trying to work out how to avoid doing this work for the earlier parts of the image. It should be possible to skip the expensive DCT for these parts as libjpeg has a mode in which it will perform only Huffman decoding and returns DCT coefficients (jpeg_read_coefficients). However, I've not found a way to ask it to do the DCT (and subsequent steps) for the wanted subset of those values. I believe that it's also possible to skip lines in
discarding the JPEG
data (i.e. not even doing the Huffman decoding) by looking for an FFDA marker, but I don't see anything in libjpeg to support that.
I believe the smallest entity to read is by scanline. Because of compression there is no random access for scanlines or parts of a scanline. Though, skipping whole scanlines or parts of scanlines might be problematic. It will require some research some find the right ways. I totally agree on minimizing expensive operations.
I have always thought that an image reader/writer should act a lot like an image that holds memory for the pixels, except that it could be lazy about when it allocated. You would create one from a file, but it would only read the header. You would ask it for its size or other properties, or request a view to part of the pixels. It would load what was needed (possibly more) into memory. You would be able to pass a visitor to some operations and it would call the visitor at various phases of decoding with format specific info, which may be an array of coefficients, a scan line, a single-channel-view, or a view to a tile that is smaller than the region requested. This way somebody could customize handling of various kinds of format specific info in a generic way, or just print progress (% complete) messages. for example: jpeg_image_t jpeg(filename); size_t w = get(jpeg, tags::width); size_t h = get(jpeg, tags::height); double compression_ratio = get(jpeg, tags::compression_ratio); struct my_visitor { //Swallow unhandled events template<class Event, class Data> void operator()(Data & data, Event const& event){} template<class View> void operator()(View & tile, events::on_tile){ //Do something .... } }; //Request a portion to be loaded into memory somewhere jpeg_image_t::view_t roi = jpeg.lock_view(x, y, width, height, my_visitor) I havent considered all the details, but this kind of interface seems like it would be good, if it works. -- John
Christian wrote:
I know there is still some work to do before a possible review. Documentation is lacking and support for dynamic image needs to be added. But what I want for now is to get some feedback on design and implementation.
When you do add support for this, perhaps you can address this issue: What I would like is a way to read_and_convert to an any_image class, so that the 'best' conversion from the file data to the format of one of my image types is chosen. For hypothetical example, if the file would optimally choose a gray16 planar image, but I pass any_image<mpl::vector<rgb8_image_t, gray8_image_t> > to read_image, then I want the read_image function to create a gray8_image_t and convert the pixels to that. I dont know how it would be done, but that would be a nice feature. I think the other thing would be for each image format to have its own image_types typedef, to that I can read into an image variant that is perfect for the reader. Cheers, John
Hi John,
What I would like is a way to read_and_convert to an any_image class, so that the 'best' conversion from the file data to the format of one of my image types is chosen.
For hypothetical example, if the file would optimally choose a gray16 planar image, but I pass any_image<mpl::vector<rgb8_image_t, gray8_image_t> > to read_image, then I want the read_image function to create a gray8_image_t and convert the pixels to that.
I dont know how it would be done, but that would be a nice feature.
Yeah, sounds like a nice feature. I will make a mark in my todo list. Before I could tackle that I would need to overcome my template instantiation issue. I cannot even compile with MSVC 7.1. It's complaining: fatal error C1055: compiler limit : out of keys I think I need to seriously rethink the design.
I think the other thing would be for each image format to have its own image_types typedef, to that I can read into an image variant that is perfect for the reader.
Not sure if I follow here. Thanks for your input, Christian
For hypothetical example, if the file would optimally choose a gray16 planar image, but I pass any_image<mpl::vector<rgb8_image_t, gray8_image_t> > to read_image, then I want the read_image function to create a gray8_image_t and convert the pixels to that.
I dont know how it would be done, but that would be a nice feature.
Yeah, sounds like a nice feature. I will make a mark in my todo list. Before I could tackle that I would need to overcome my template instantiation issue. I cannot even compile with MSVC 7.1. It's complaining:
fatal error C1055: compiler limit : out of keys
I think I need to seriously rethink the design.
Hmmm...
I think the other thing would be for each image format to have its own image_types typedef, to that I can read into an image variant that is perfect for the reader.
Not sure if I follow here.
any_supported_image<jpeg_tag> result; read_image(fname, result, jpeg_tag()) gil::apply_operation(result, my_operation) On another note, I dont think you need filesystem to check the extension of the images. You can use the boost string algorithms library (or just use std::string operations). bool can_read(std::string filename, jpeg_tag const& ){ static const string extensions[] = {".jpg", ".jpeg" }; return ::boost::algorithm::iends_with(filename, extensions[0]) || ::boost::algorithm::iends_with(filename, extensions[1]); } Also, I beleive some of the image formats can peek at the first few bytes of the file to determine if the format is appropriate. I dont know about non-windows systems, but on some of them this might be the only way to tell. If that is the way image formats are checked, then I dont think filesystem (or string algs) is going to be important. -- John
Hi John, I have added the necessary this-> to hopefully make the lib compile with gcc now. Can you pull the latest and try again?
any_supported_image<jpeg_tag> result; read_image(fname, result, jpeg_tag())
gil::apply_operation(result, my_operation)
Ah, I see. Nice idea, I will add it to my todo list.
On another note, I dont think you need filesystem to check the extension of the images. You can use the boost string algorithms library (or just use std::string operations).
bool can_read(std::string filename, jpeg_tag const& ){ static const string extensions[] = {".jpg", ".jpeg" }; return ::boost::algorithm::iends_with(filename, extensions[0]) || ::boost::algorithm::iends_with(filename, extensions[1]); }
You're right. This should work, as well. Thanks!
Also, I beleive some of the image formats can peek at the first few bytes of the file to determine if the format is appropriate. I dont know about non-windows systems, but on some of them this might be the only way to tell. If that is the way image formats are checked, then I dont think filesystem (or string algs) is going to be important.
For now, I believe the file extension will do. Thanks again, Christian
participants (6)
-
Andreas Pokorny -
Christian Henning -
Daniel Krügler -
John Femiani -
Lubomir Bourdev -
Phil Endecott