LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 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.11.30 16:14 "ITULAB JPEG support", by Lee Howard
Hello all (again). A mail thread[1] on this list came up a couple of months ago where someone had some trouble with some patches to libtiff that I have been distributing to provide ITULAB JPEG support. Unfortunately, I was not subscribed to this list at the time (I seem to come-and-go around here) and was unable to respond. The whole purpose of my involvement in this matter revolves around the handling of color faxes in HylaFAX - initially just receiving them, but eventually I'd like to be sending them, too. Let me state up front that the patches that I've been distributing (within SRPMs[2]) are not largely my work. The libjpeg patch originates from John Andy Barber[3] - who appears to be familiar to some of you here, and although I did initiate the libtiff patch, it was largely reworked by Blas Rodriguez Somoza. Initially I had assumed that color fax used ITULAB (because of the *ITU* part - they being responsible for the fax specs, generally), but then in conversation with John I was convinced that it was CIELAB, that being reinforced by my confusion from the ITU's specs themselves[4]. Ultimately Blas (and now Joris Van Damme) settled the matter for me by analyzing color fax samples that I have - which proved to be ITULAB. Nearly two years ago I started a small thread[5] on this list which proved very helpful. Eventually that thread died. I did open up a Bugzilla report[6] for libtiff where I hoped to distill all of what became of the effort from the mail thread. I am quite accustomed to having blog-like discussions in Bugzilla-space, and as Joris points out in his last comments on that Bugzilla report, apparently I incorrectly assumed that discussion would continue there. I'm posting this message to this list now to attempt to ressurrect the two earlier threads[1, 5] as well as open up the discussion I've attemped on Bugzilla[6] into the mailing list. As mentioned on the Bugzilla report, my ambition in this is to be able to take a received color fax (ITULAB JPEG in TIFF) and use any of libtiff's tiffcp, tiff2ps, and tiff2pdf to convert that image file into something more commonplace. Eventually I'll also need to devise some tool to generate ITULAB JPEG in TIFF from commonplace image formats too (and, in as lossless as a manner possible place a fax "tagline" onto the top of each page). I don't want to speak for anyone else, but let me summarize what I am understaning from the latest posts by Joris on the Bugzilla. As much of this is "over my head" please do correct me and forgive me if I get it wrong. Joris feels that using John Barber's libjpeg patch is an inferior, perhaps wholly unneccesary, step towards my ambition. I am not really familiar with the libjpeg API, but apparently libjpeg already has the ability to handle ITULAB without patching. I would be delighted to be shown how to modify the libtiff patch on the Bugzilla report[6] in order to accomplish this. Furthermore, it would seem that the way that tif_jpeg.c currently works is sub-par. I'd like to see some discussion towards a resolution on this. I'll quote Joris from that bug report: ------------------------------------- > As I am not an imaging person I sought for assistence in this matter, and > I was greeted by John Barber, and his work in libjpeg suited my needs > well. This is where you loose me, for two reasons. 1) I've recently created a a tool that produces various TIFF testfiles. It furthermore checks support for these files with a variety of decoder and decoder settings, including LibTiff RGBA interface. Here's one family of results: 8-bit predictor combined with no compression: not supported 8-bit predictor combined with packbits compression: not supported 8-bit predictor combined with LZW compression: supported Next take into account that there is absolutely no dependence between the compression, whatever the compression is, and the prediction. That means a single central point in the library that supports prediction, should suffice to support prediction for all compression schemes. Yet, it doesn't. Why? Because issues that could and should have been regarded separately, weren't. This is just one example, but I could give at least half a dozen others. Fact of the matter is that LibTiff just doesn't properly separate some logically independent mechanisms, and therefore supports only a small subset of combinations, whilst half of the programming efforts and total amount of code that is in the library should in fact suffice to support all mechanisms separately and thus support all combinations, if only the library as a whole were properly designed that way. Now we must evolve away from this bad situation. We must *NOT* burry ourselves deeper in this shit by hiding away ITULAB support in a single subcodec and thus tying it in with the JPEG compression scheme. 2) The use of the JPEG_COLOR_MODE tag is an abomination. No other subcodec does any color conversion, and that's perfecly logical. The library is thus build to expect from the subcodec the sort of data that is specified in the IFD. Yet, in the case of JPEG compression combined with the use of this pseudotag, it doesn't. This required *too* many hacks to support. Predictably, it got us in a maintanance nightmare, and I dare say it is the single most important reason why JPEG support in TIFF continues to be a problem, tif_jpeg.c gets more hacky and more complicated, and less reliable, with every new LibTiff version. There is one LibTiff maintainer, myself included, that feels we should evolve away from the JPEGCOLORMODE tag. We can do this if we first offer people a good alternative for the subsampling issue. (They may have to deal with YCbCr color, but then again, if they don't use the RGBA interace they have to deal with any color so I see no problem in that and feel a good alternative for subsampling resolution should suffice.) We may even decide to abuse this new and better altnerative in a backwards compatible support for the depreciated JPEGCOLORMODE tag at that time. (This is all not entirely hypothetical, there has been some talk about all this with respect to the upcoming LibTiff 4.0, though no decisions have been made yet.) In any case can we not allow dependence on the JPEGCOLORMODE rat's nest of hacks to grow, and that's exactly what we would be doing if we allow the support for ITULAB to be tied in with LibJpeg. ------------------------------------- At the end of the bug report Joris makes some undoubtedly valuable advice on what to do to accomplish my goals, but admittedly most of it is not in terms that I understand easily. I would certainly appreciate some translation (from guru-speak to the level of know-how that would create the initial hacky libtiff patch found on the report). ------------------------------------- If you want a broad range of mainstream viewers to support your ITULAB images, and/or your own applications depend on the RGBA interface, then add support for ITULAB to the LibTiff RGBA interface. If you need your own application layer to support these TIFF images, and you use the TIFFReadEncodedXxx interface, then add support for ITULAB to your complete layer, or add conversion from ITULAB to your familiar color spaces right after the TIFF decoding step. If you need support for these files in any tool, the same reasoning applies to those tools as does apply to your own application layer. Of course, things are complicated by the fact that the principles of separation haven't been applied rigorously in the past. For example, if you need to add ITULAB support to the LibTiff RGBA interface, you'll find JPEG compressed imagery uses the JPEGCOLORMODE hack... That mess is no reason to repeat its causes, though, quite the contrary. Instead, separate the case where the JPEG compressed data contains ITULAB, disable the bad use of the abominable JPEGCOLORMODE tag in that case, and make the RGBA interface handle that case as it would (subsampled) ITULAB combined with any other compression scheme. ------------------------------------ Your replies will be most appreciated. Thanks, Lee. 1. http://www.asmail.be/msg0055388649.html 2. http://sourceforge.net/project/showfiles.php?group_id=148904 3. now dead link: http://homepage.ntlworld.com/john.andy.barber/JPEG/index.php 4. ITU-T.30 Table 2 Note 35 (in the 2003 revision) states: 'In a DCS frame, setting bits 68 and 69 to "1" indicates that the calling terminal sends image in full colour representation in the CIELAB space in JPEG mode.' 5. http://www.asmail.be/msg0054884586.html 6. http://bugzilla.remotesensing.org/show_bug.cgi?id=736