Re: [Boost-users] [gil] Processing huge images

Subject: Re: [Boost-users] [gil] Processing huge images
From: Christian Henning (chhenning_at_[hidden])
Date: 2011-04-07 10:14:52

I agree that a virtual view should do the trick. But it was Nathan who
suggested the idea to Franz.

Christian

On Wed, Apr 6, 2011 at 2:53 PM, Lubomir Bourdev <lbourdev_at_[hidden]> wrote:
> Hi Franz,
>
> The simplest solution is to create your own GIL virtual view, as suggested by Christian.
> In your view you can provide implementation for a pixel accessor given (x,y) coordinates to read/write a pixel from the appropriate view.
>
> If you have control of the layout of the tiles in the virtual image and you are aware of the kinds of algorithms you are using this for, consider having thinner and wider tiles so that one tile spans the entire width of the image. For some algorithms this is faster and it would be easier to add GIL support for this. Specifically, in this case all you would need is to create a custom step iterator (iterator that advances by K pixels when you increment it). GIL uses a step iterator with a step equal to the image width to provide vertical navigation. Your step iterator will keep track of which line of which tile it is on and pointers to all tiles, and it will know when to switch to another tile.
> Using this custom step iterator, you can construct a locator and a view (see how it is done for the standard GIL images). The advantage of this approach is that horizontal navigation (typically the bottleneck of many image algorithms) is still very fast using native pointers. But this only works if your tiles span only horizontally.
>
> If you want to handle locking and releasing tiles, swapping them in/out of memory, that would be much more complicated.
>
> GIL does not provide off-the-box support for tiled images for several reasons: First, no one tiling strategy is better, it really depends on what you plan to do with the image, on your memory management policy, etc. And second, if performance is important to you, you cannot get away from abstracting your algorithm from your tiled representation: You actually have to think carefully about the access pattern of your algorithm and may need to provide a custom version for tiled images anyway, unfortunately.
> I think tiled image support would be a good and useful GIL extension if anyone is interested in a new project.
>
> Lubomir
>
>
>
> On Apr 4, 2011, at 1:38 PM, Christian Henning wrote:
>
>> Hi Franz,
>>
>>> To make my problem more concrete, imagine the following picture:
>>>
>>> |<---- width of the huge "virtual" image ------>|
>>> +---------+---------+-----------------+---------+
>>> | image 1 | image 2 | ...             | image N |
>>> |         |         |                 |         |
>>> |         |         |                 |         |
>>> +---------+---------+-----------------+---------+
>>>
>>> All the images are in different places in memory.
>>>
>>> From my point of view I would make something like a wrapper class that holds
>>> the separate images and supports an iterator to iterate over the huge image.
>>> In this case I'm not sure if I could use this wrapper class as a normal gil
>>> image and therefore can't use the full gil power at my wrapper class.
>>>
>>> Do you know if gil has something onboard to solve problems like this?
>>
>> You can create an image view from raw data. Once you have a view you
>> can use all the gil goodies.
>>
>> Look here:
>> http://stlab.adobe.com/gil/html/group___image_view_constructors.html
>>
>> Does that help?
>>
>> Christian
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>