TIFF and LibTiff Mail List Archive


1998.09.22 14:49 "TIFF Questions - TIFF 7.0 ?", by Ed Grissom
1998.09.22 14:51 "Photometric interpretation of multi-band, NON-alpha images ?", by Ed Grissom
1998.09.23 15:15 "RE: Photometric interpretation of multi-band, NON-alpha images ?", by Ed Grissom
1998.09.22 14:51 "Large images (>2gb & >4gb)", by Ed Grissom
1998.09.22 14:52 "Sparse images (uninstantiated tiles/strips)", by Ed Grissom
1998.09.22 14:52 "Transparent pixel value (no transparency mask)", by Ed Grissom

1998.09.23 15:15 "RE: Photometric interpretation of multi-band, NON-alpha images ?", by Ed Grissom

In a previous message, Max said:

> We have adopted essentially option (2) below
> as our method of storing multi-spectral imagery in TIFF files (we
> actually use RGB instead of MinIsBlack when the number of layers
> is 3 or greater but MinIsBlack is a little less misleading.

Max, thanks for the info, I assume that I will be seeing images that your software has created, so it is good to know how you have solved the problem.

> 1) CMYK seems inappropriate given its current description in the
> TIFF spec. Are you trying to put a square peg in a round hole here?

Perhaps, but Section 16 of the TIFF spec talks about "Separated Images (usually CMYK)" and later says "The fields described in this section... can also be used for describing an image made up of more than 4 inks,..." I was hoping to get some discussion about the reason why "separated" is always associated with "CMYK". It seems to me that we have "separated" images in the satellite data case also.

Maybe I am trying to put an oval peg in a round hole.

> 2) I could be wrong, but how likely is it that 3rd party apps that
> do not support ExtraSamples ...And if they choke on ExtraSamples,
> they are not Baseline TIFF Readers.

I agree, ExtraSamples was my favorite choice also (given current TIFF 6.0 constraints). The only problem is confusion over the PhotoMetricInterp (MinIsBlack vs. RGB). If you will accept my "MinIsBlack" Images, I'll accept your RGB images :).

> 3) This was the other option that we considered but it turned out
> to be more complicated to support programatically. We obviously
> would push for option (2) as we have already made the choice.

I maintain a Raster I/O library for Intergraph. I already support multiple images In TIFF and other formats. Mostly all we currently see are single-bit images in this format. From my point of view, this is the easiest for me to implement (nothing needs to be done...). However, as you said, the applications built on my program will have to change much more for this option than for the ExtraSamples option. Unless I hear better arguments from the TIFF community, I will probably try to encourage option 2 also. Note: I do not have control over the INGR's applications, and since this option (3) already exists in my library, they may go with this one...

> 4) We needed it yesterday. I'm sure you did too.

Yes, If Adobe does not do something soon, folks are going to start leaving the TIFF format for other formats that meet their needs. When I say "do something" I mean "make an announcement, give up the standard, or form a committee, or something, anything to let us know that they are still interested in moving this standard forward or letting us do it."

Mark my words, the >4Gig problem is going to be hitting many more people very soon. I have a home scanner that I bought for $150 that will "scan" at 4800 DPI (interpolated) and will scan a 8.5x17 inch sheet in 24bit color. Uncompressed, this would be:

(8.5 x 4800) * (17 *4800) * 3 = 9,987,840,000 ~= 9.525 GB.

I doubt that the software allows a full sheet at full res and uncompressed output, and I don't have the disk space to try it. However, drives that will hold more than 4Gb in a single file are widely available now, and it is just a matter of time before users will want to start working the limits.

Perhaps this can be managed in a similar way the GeoTIFF additions were managed. I know there are several other features desired by satellite and RS data users, like ephemris, capture date, & sensor info that also need to be carried along with the data.

> I will also note that your other three issues,...
> we have current solutions to these issues in our native file
> format.

Yes, although we cannot handle >4GB in our native format either, all of the other problems have solutions in the INGR file format.

> Finally, I want to mention two additional issues.
> STATISTICS: It is common with this type of data to store scalar
> statistics separately for each sample. The public domain library
> only supports a single min and a single max, although the spec
> allows the min and max to be specified separately for each sample.

Both the Min(Max)SampleValue and the SMin(SMax)SampleValue tags are supposed to support "SamplesPerPixel" values. If LibTIFF does not, I'd say that is something that needs to be looked at. I am not very familiar with the internals of LibTIFF, but if I do run across this I'll try to come up with a patch.

> COMPLEX DATA: Complex data is common in this industry also. Has
> anyone devised an interchangeable approach for this (perhaps using
> the Data Sample Format extension somehow)?

I'd say that separating the real and imag. components into two separate bands would make sense. Then you could set SamplesPerPixel=2, SampleFormat=3, and BitsPerSample=32 (float) or 64 (double) for each band. Of course, this does not distinguish "complex" data from some "two-band" sensor that writes floats, so interpretation of the data is going to be tricky.

Thanks for the info & the discussion.....

ed grissom