Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)

Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-03-25 19:28:59

Phil Endecott wrote:
> Christian Henning wrote:
>>>> Also, how would a C++ wrapper help you with large images?
>>>
>>> My point is that your gil interface doesn't help me with large images
>>> in
>>> limited RAM, and your current design is "all or nothing". ?Decomposing
>>> it
>>> into wrappers around the libraries that are independently useful would
>>> mean
>>> that I could use them directly and get the benefit of e.g. the error
>>> handling stuff, with my own row-at-a-time code on top.
>>
>> Imagine for now libjpeg doesn't allow for partial image decoding. How
>> would you solve that problem?
>
> I'm not sure what you mean by "that problem" in that question.  Do you
> just mean "processing large images in limited RAM"?  If you do, the
> answer is that I would just process the image sequentially, e.g.
> row-at-a-time.  For operations like scaling and tiling this is
> straightforward.

It seems aligned to what I was trying to suggest too.

>> My solution might be to create a virtual
>> image container which only holds a certain amount of an image in
>> memory and the rest on the hard drive. Though, while reading a large
>> image this container will handle limit memory situation on the fly.
>
> Well my digital picture frame doesn't have a hard drive.  You seem to
> be over-thinking this a bit!

Perhaps, generally I mean, it's not a bad idea to manage a cache that
could be used by underlying I/O machinery. This cache could be used to
store
most recent blocks, so they are not re-read from disk if re-accessed.

Though, it feels to me as an application specific feature,
but on the other hand it could be implemented better if made
as close as to low-level I/O.

Best regards,
-- 
Mateusz Loskot
http://mateusz.loskot.net