LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
October 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.10.26 18:59 "Re: checking test images", by Joris Van Damme
Frank Warmerdam wrote: > On 10/26/05, ryuki_dono <ryuki_dono@yahoo.de> wrote: > > It was not meant as an insult. I used JPEG.lib and PNG.lib before > > and they where able to provide the full support of > > the image format with high level functions. > > With all due respect, libjpeg and libpng do not attempt to support > the same breadth of image data types as libtiff. I believe that to be very true, bot not very clear, and I hope to add a little example. ryuki_dono, I believe you probably haven't tried decoding a CMYK jpeg with LibJpeg yet. (Please note the proper name, jpeg.lib may be some build somewhere, but LibJpeg is the name of the library.) If you had come accross this more exotic use of JPEG, you had noticed that LibJpeg doesn't decode these to RGB. LibJpeg provides convertion between YCbCr and RGB, for example, because this is extremely much used and, in the opinion of some (myself not included), actually a part of the codec rather then a part of the encapsulating imaging engine. However, when it came to convertion between CMYK and RGB, the LibJpeg designers quite rightly decided this is not a matter for a codec, but a specialized issue to be handled by imaging/color engine layer. The thing with the JPEG and PNG file formats, compared to the TIFF file format, is that the first mostly offer color and bitdepth modes that are largely the same as the RGB standard depths that are usually supported in the imaging layer. Thus, it's rather easy and direct to interface with these libraries, and you'll have little need for contemplating the color convertion issue. However, with TIFF, this is drastically different. TIFF doesn't just support RGB and YCbCr, and CMYK, it also supports CIE L*a*b*, grayscale, L*, and even non-colorspace-related scientific data and all, and does so in just about any possible bitdepth, including floating point encoding, etc. Thus, here the 'convertion layer' (if you decide to design things such that it is a seperate layer), is no longer negligable. Of course, that's all theory. In practice, there's practice. Many that wish to interface with TIFF, are not prepared to start building code that deals with umpty color spaces and bitdepths. In this sense, a minimum support for only the most common spaces and depths, is a welcome contribution to the actual codec, even if it cannot be the intention to add a complete color engine there. This is the LibTiff RGBA interface. It's allright to use it, but remember you're using exactly this, and don't expect your more exotic TIFFs to be decoded properly. For more then a minimum support, use either your own color code and/or interface with more open source color engines or commercial libraries or such, instead of the RGBA interface. (For example, good combination of LibTiff and LCMS might also be possible.) Frank wrote: > I, for one, have avoided trying to implement support in the RGBA > interface for higher bit depth images because in my industry > (geospatial), just shifting off the low order bits to make the image > 8bit is not the appropriate response to high dynamic range data. I believe Frank here adds a valuable point: why make the RGBA interface support all and everything, if the ones more likely to be interested in all and everything, actually require the usage of their own color / bitdepth handling instead of the RGBA interface? A uniforming-easy-access to the color data, is bound to add overhead on small bitdepth data, and add loss on high bitdepth data. In fact, it adds loss in any color convertion whatsoever, and thus serious libraries that are interested in reading exactly what is there, preserving all data at all precision, wouldn't want an RGBA interface anyhow. Frank wrote: > I would like to stress very strongly that it is not safe, at the very > least not clean, to throw an exception from within the error handler. > Libtiff assumes that control will return to the calling function so > that it can cleanup appropriately after the error. Frank, I believe this mistake will be commonly triggered by the lack of TIFF* indication in the error handler. It is a very tempting way out: the actual error gets feeded back to the calling code where an exception stack frame is set up, this tracing it back and being able to take appropriate action in the encapsulating structures. I don't deny it's bad, mind you, of course I agree with you. I'm merely saying why it's a tempting mistake to make. Have you had any private feedback to the 'dual-mode' error handling I proposed recently? I haven't seen any feedback in the list, but maybe I missed it. 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