AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.03.24 15:19 "[Tiff] Need consultant", by Wendel Dean Renner
2004.03.24 22:15 "Re: [Tiff] Need consultant", by Bob Friesenhahn
2004.03.24 22:51 "Re: [Tiff] Need consultant", by Joris Van Damme

2004.03.24 22:51 "Re: [Tiff] Need consultant", by Joris Van Damme

The tiff library only goes to 8 bit.

There's no such thing as a limit to 8 bit, not in the TIFF specification, and not in LibTiff.

We have a routine that makes calls to the libtiff library to decode an image that is 8 bit, but don't know how to modify things to handle 16 bits per pixel, be it true color or gray scale.

Either this routine uses the RGBA interface, or it goes about the proper way.

* RGBA interface *

Is really unfortunate. I think it probably came about because people ignorant of the actual file format expect such an interface, possibly because other formats and libraries more naturally provide such an interface. The consequence of this interface is that there's people reading singlebit black and white as 32bit RGBA and such, and the fact that we periodically see messages that go from the assumption TIFF or LibTiff does not support anything beyond 8bit per channel may have something to do with this interface, also. This interface I do not recommend, it is kinda like 'LibTiff for dummies', but, obviously, you have a professional need and should not be misguided into using the RGBA interface. And even true dummies should not be tempted into lowering standards when it's not at all difficult to go about things in better ways, but should instead receive proper documentation.

* the proper way *

Has no such limitation. Has very little limitation at all, TIFF is very flexible, and so is LibTiff (only thing TIFF allows and LibTiff does not is different bitdepths for different channels in same raster, to the best of my knowledge). This interface documented in the LibTiff documentation. Here's some additional pointers. First two are URL's to good documentation on how to use LibTiff the good natural way. Next two are pointers to the long-term mailing list archive, riddled with information on TIFF and LibTiff.

http://www.ibm.com/developerworks/linux/library/l-libtiff/
http://www-106.ibm.com/developerworks/linux/library/l-libtiff2/
http://www.remotesensing.org/libtiff/tml/index.html
http://www.awaresystems.be/tiff_mailing_list/index.html

Is there anyone who could do this for us?

You don't need a consultant, you need some courage, some good pointers like the ones given here, and at most a couple of hours of research. Don't take my word for it though. If you're still eager to needlessly throw money at it anyway, please note my signature. My company is not very active in C or C++, but in Borland Delphi. For big spenders, we'll do just about anything though.

if the file is 16 bits each of red, green, blue, one would just take the average of each of those three signals at each pixel

I don't know the context, so maybe I'm missing something. *If* the goal is true convertion from RGB to grayscale, then simple average will not do. In fact, this is off sofar as to render 16 bits of precision completely useless. There's tons of convertion formulae scattered all over the web that are (slightly) better. Most of these find their roots in ancient analog devices, and not in color theory. Is why I wanted to warn about these, too (and expect someone to quote some at me). I believe the correct way to do it is to convert RGB to Y (as in XYZ), and next convert Y back to either grayscale (as in R=G=B) or brightness (as in L*), depending on what exactly you're after (display on common RGB display device, or perceptually proportional grayscale for further processing).

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html