Hi Christian, no, I haven't tried the gil.io extensions. The images itself shouldn't be a problem. They are all of ordinary RGB format. 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? Regards Franz Am 04.04.2011 21:59, schrieb Christian Henning:

Hi Franz,

have you tried the gil.io extension? If the underlying C lib can handle your format then you shouldn't have any problems.

Let me know if that works, Christian

On Mon, Apr 4, 2011 at 3:40 PM, Franz Alt<f.alt@gmx.net> wrote:

...

Hi all,

I'm very new in Boost.GIL so I hope anyone could help me with my question.

Imagine several images all with identical dimensions (e.g. 10000x10000). All images form one huge "virtual" image. Because every image is very big (~ 50M) I couldn't copy them together to one image in memory. I want to perform some algorithms (e.g. x-gradient) over the huge image with GIL in a (hopefully) elegant way. The user should use GIL on the huge image "as normal" as possible. Does anyone know how I could handle this problem?

Regards

Franz

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi Franz On Mon, Apr 4, 2011 at 2:28 PM, Franz Alt <f.alt@gmx.net> wrote:

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.

GIL doesn't support this by default, but it's trivial to use the virtual image view to do this. I don't know of a way to ensure efficient traversal of this image for for_each_pixel-type algorithms, however. HTH, Nate