LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2006
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
2006.09.26 06:48 "Re: Status of ISO JBIG and CIELAB JPEG support", by A Wandering Libtiff User
> I'll state the obvious that nobody seems to notice, first. The LibJpeg > library includes a definition for any 'unknown' color space. You're right, I didn't notice this. > Only to next find that a prior convertion from A to B, to > next convert from B to C to suit your purposes, accumulates convertion > errors, where a direct convertion from A to C would do a lot better? No, I understand. > When adding support for ITULAB to 10 of these 27 codecs, are you > planning to do 10 separate difficult jobs? Only to next find it hard to > maintain as these 10 are modifications to open source libraries and > you'll need to merge your changes and the public changes time and time > again? I should ask Lee what his intentions were with these patches to libjpeg/libtiff. It sounds like building colour conversion code into his end-client (Hylafax) was the correct place to make changes, and to make only minimal changes to the lib[jpeg|tiff] to ensure they didn't reject the datastreams. > It seems clear that color convertion isn't really correctly placed > inside a codec. Instead of having 27 such color convertion modules, > codecs should normally be made to return exactly what is there, and any > convertion should be managed by the image processing layer. I have no argument with any of this. Typically the application author "knows" the end destination and what colourspace he wants to end up with, and so having a library do as little "processing" outside of the formats it's designed to support is a prudent one. I've seen numerous examples of well-intentioned mistakes that the driver authors make when trying to be "helpful". > I've some, or at the very least I had some... I'll try and find them and > get back to you later today. I would love to get them, still. Thanks! > It is dangerous trying to build support for something based on bugzilla > attachment, as many a bugzilla attachment is totally bazurk. Here's a > tagdump. Yeah, I know it was very much a risky concept... on many levels. > LibJpeg doesn't support the DNL scheme, and it's not valid inside JPEG > compressed data inside TIFF anyway. What Howard did at the time, was > 'patch up' the SOF marker to include the proper image length. Strictly > speaking, this is now a totally invalid JPEG stream. But most > implementations, LibJpeg included, can interpret the stream just fine > and simply ignore the bazurk DNL marker. Gack. OK. > This confirms my memory that Howard patched up the Y member of the SOF > marker. It also indicates that subsampling is indeed used, and the > subsampling values in the IFD are correct. What a mess. In my naivete, I'd thought that JPEG handled "true colour" data as tri-planar data, but I suppose the temptations to use subsampling for the colour component was too irresistable. > I'm unable to answer these questions, best I can do is provide > theoretical background and file analysis. I will also try and find the > ITULAB JPEG images that at least at one time were part of my testimage > library. I would appreciate links to what are hopefully "reference" images that reflect the correct output according to spec. > I hope was somewhat helpful though. Perhaps someone else will jump in to > answer your bottom-line questions. Your answer was much more than I'd hoped, actually, and I appreciate its thoroughness and attention to technical details. Thanks again, Joris. Your reply was useful, interesting, and provided the detailed background which resolved my questions about the matter. =R=