"Mateusz Loskot" <mateusz@loskot.net> wrote in message news:4CBC79E9.2040009@loskot.net...
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).
That's exactly what's wrong with them :) You do not use something yet 'they' still make you pay for it because of the almost exclusively runtime/dynamic configuration where different behaviours are runtime-switched using traditional branching and virtual functions... Not to mention dynamic memory allocation...and thread synchronization...and RTTI...and locales...and ad nauseam... It puzzles me that you still have to 'persuade' people into the simple fact that std::streams are an evil failure (as shyly/indirectly, and of course not in this wording, admitted even by the official technical report on C++ performance)...
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.
This was not the issue (how to write an image, that's up to the user to decide)...the issue was whether, and how, to implement and provide ROI capabilities for backends that do not provide them or provide them poorly themselves. I better (re)explained the implications of different approaches in the last reply to Christian... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman