|
Boost : |
Subject: Re: [boost] [gil] New IO release
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-24 16:27:27
"Mateusz Loskot" <mateusz_at_[hidden]> wrote in message
news:4CBC79E9.2040009_at_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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk