LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2004
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
2004.09.02 16:22 "Re: Stacked tiffs with colourmaps", by Ross A Finlayson
Hello, warm regards, The compressed colormap is folklore, and perhaps ephemera as nobody ever encounters one of them. It might be a fable. In theory, if you want to use a compressed color map then you should get a private PhotoMetricInterpretation value and then a private tag for the color map, then calculate from the SamplesPerPixel / ExtraSamples / MinSampleValue / MaxSampleValue / Indexed / PhotometricInterpretation /PrivateColorMapCompression / PrivateColorMapPredictor tags some correct count of colormap values and an uncompressed ColorMap. Many times the colormap is seen to have values that are ridiculous. For example, If each RGB triple for an RGB palette image is (0, 0, 0), (1, 1, 1), etcetera, then the image data can just be considered grayscale. Correspondingly, there are images that exist that, use, say, two elements of the colormap for black and white and have more than one bit per sample unnecessarily. That's about examining the color map and seeing if the image data is thus an even more compact palette defined by a standard PhotometricInterpretation. A colormap of that form could compress very well with using a differencing predictor for the entire colormap or each plane of the colormap. Simply reusing the offset with having the same colormap for each image in a file as Joris noted is probably the best way to reuse the colormap data. A standard reader might check to see if the offset to the value data is reused within the file and complain or even balk, but most readers will happily reuse the data without complaint as TIFF is a random access storage method. Programs that copy the data from one file to another should be able to handle them acceptibly, although they would probably put a new instance of the colormap data in the output file for each image. If you wanted to use libtiff to generate those images, there would be much work in modifying the TIFFGetField to maintain a list of pointers and lengths of input data with TIFFSetField and to reuse the written data for any time TIFFSetField is called with the same input pointer. That would be incompatible with programs that currently use, say, the same pointer to pass in multiple values, eg a scanline pointer, although that is handled by different functions than TIFFSetField, or for example a reused character pointer with varying values. As one of the concepts of TIFF is "no duplicate pointers", where that is often seen, in for example OJPEG images with multiple JPEGQTables offsets that are the same value, that would presumably be a separate patch fork. So if you wanted to modify libtiff, which is a primary point of discussion if this mailinglist about TIFF, for the colormap, then that would entail implementing in the TIFFVSetField function for the case where the colormap is set logic to compare the input colormap pointers and then also there would be other brutal hacking within the TIFFWriteDirectory type functions. Alternatively, you could write a completely custom program to do what you want and then most readers and tools would handle that image without a problem. That would save 30 megabytes, which ten or fifteen years ago was hundreds of dollars of hard disk storage and is today hundreds of pennies, and as well back then T1 line speed was similarly, but not quite, more valued. I have not heard of a ready-made tool to do this, you would have to partially invent one yourself. Sinc., Ross