On 18/10/10 15:53, Christian Henning wrote:
Why not use std::streams
Streams are _evil_ ... http://lists.boost.org/Archives/boost/2010/01/160911.php ...
and what are the alternatives?
In my book anything is an alternative to screams :D
OTOH, only providing a streams based interface as an additional option is usually just fine (as opposed to forcing a streams only based interface)
Don't wanna get into a "streaming" fight here. Point is noted. Did you know there are several fast streams implementation available on the net? They might change some arguments.
It's also not clear to me what's wrong with use of streams in such case as in Boost.GIL where no character formatting, no use of manipulators but read/write calls (binary mode).
Unlike io and io_new it uses objects that represent on-disk images ("formatted images" in io2-speak). This has several advantages:
Could you go into more details? What are "formatted images"?
Well, images in different 'formats' like JPEG, PNG, GIF...obviously not a very clever name that I just came up with to somehow distinguish them from 'raw'/in-memory images (like gil::image<>)...you are more than welcome to come up with a more intuitive name ;)
How about in-memory vs. of-file? ;-)
Raw image is not necessarily in-memory image. To distinguish image source location, I'd rather vote for in-memory.
I would love to know how you seek through a image using a 3rd party lib, for instance with libjpeg. Right now I'm just reading and discarding unwanted regions. Not the most ideal solution to say the least.
With LibJPEG you cannot really/literally skip unwanted data but you can make the library read the unwanted data using faster/less precise methods which is what I currently do (and admittedly use a bit of LibJPEG's internal implementation detail knowledge for that)...
Cool, I would love to know more. Can you point where in your code you do that?
I may be wrong, but presumably it's done by (re)setting parameters like note colour dithering to perform faster decompression.
That sounds great. I have to look at how you deal with certain functionalities, like reading ROI in a jpeg image.
Actually, I forgot to mention, with the LibX (JPEG, PNG, TIFF) backends I do not provide 'full'/2D/rectangular ROI capability but only 'vertical' ROIs (i.e. you can specify from which to which row/scanline to read but whole rows/scanlines are always read...) because the backends do not support reading partial rows/scanlines so adding full/proper ROIs for those backends would require emulation which in turn would cause code bloat/complication and (possible) redundant data copying...For now it seems to me that the user should handle 'full' ROI support in such cases (if required)...
I try to allow all sizes of ROI. It can be anything from a single pixel to a scanline or a vertical line to a rectangle. This was bit** to implement for tiff's tiled images. ;-)
IMO, that's correct approach. If scanline-based reading is not efficient, such image is a candidate for tiled tiff. This would improve decompression as well, as tiles are compressed independently. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org