|
Boost Users : |
Subject: Re: [Boost-users] [GIL new_io] Some questions about TIFF handling
From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2010-02-28 21:40:13
Hi Olivier,
I will let Christian answer the tiled TIFF question. As for why bits32f is scoped 0..1: GIL channel types have a notion of a minimum and maximum value, which is used for many operations, such as converting from one channel to another, in particular in color conversion. Float and double are perfectly valid GIL channels, but their scope is inf to inf, so you cannot linearly interpolate from a float to an uint8, for example. Thus they are not as useful as bits32f, but you can use them as long as you are careful not to do any operations that require using their range.
You are free to define a float/double channel with any other range you might find useful, such as 0..255 or 1..1
In Photoshop, for example there is a channel type that goes from 0 to 32768
Lubomir
On 2/28/10 9:48 AM, "Olivier Tournaire" <olitour_at_[hidden]> wrote:
Hi all (and in particular Christian),
I have some questions about TIFF reader/writer in GIL new_io.
First, I do not understand why bits32f are scoped in the range [0.f ... 1.f]. It is for our applications a real limitation because we use float TIFF images not scoped in the range. We thus have to define a new type (e.g. bits32F) which is not scoped and simply typedef float bits32F. In addition, why double is not "typedefed" by default? We also have to define a new type: typedef double bits64f. Double however seems to be supported in the writer.
Last, but not least, there is no support for tiled TIFF. Nothing about tiled TIFF is defined in tiff_tags.hpp. Maybe we could add in tiff_device_base a read_tile method, similar to read_scaline (sic), but which simply swap TIFFReadScanline with TIFFReadTile.
So, do you plan to add this stuffs in the new version of GIL io? Maybe I could help. Let me know.
Best regards,
Olivier
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net