Re: [boost] [GIL] I/O

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-06-25 11:03:34

Daniel Mitchell wrote:
> I'm curious about how your library communicates the type of pixel data

> contained in an image. 

I presume you need to know so you know what type of image to give it?
There are three scenarios:

1. If you know what channel type and color space the image on disk is,
you can use jpeg_read_image passing it an image of the right color space
/ channel. If you are wrong an exception is thrown. (You don't have to
get the channel permutations correct by the way - you can read an rgb
image into a bgr destination)

2. If you don't know the image format on disk is but you just need the
image in a specific color space and channel depth, you can use
jpeg_read_and_convert_image passing it the type of image that you need.
As long as color space and channel depth conversion is provided between
the source and target color space and channel depth, this will read the
image and color convert. It does it on the fly (doesn't need to store
the image data and then color-convert)

3. If you don't know the image format on disk and you want to read the
image in its native color space and channel depth, you must use
jpeg_read_image passing it a run-time specified image (any_image). The
I/O code will try to match the image on disk with any of the allowed
types of your run-time image (as always, channel permutations are
ignored) and if a match is found it will read and instantiate the image
in that format. If none of the allowed image types of your any_image is
a match it will throw an exception.

For all of the above, instead of images you can use views (templated or
any_image_view). The calls are jpeg_read_view,
jpeg_read_and_convert_view.
Using a view transformation, this allows you to do some very powerful
things, like fetch a subimage of your large image from disk (using
subimage_view) or read the image upside down, etc, all without using any
extra memory and without copying the data. Image views don't own the
pixels. Loading into a view will not allocate extra memory. However, the
dimensions of your image on disk must match that of the view or else an
exception is thrown.

All of the above apply for TIFF and PNG, just replace jpeg_ with tiff_
and png_

Lubomir