1999.06.03 19:48 "Large File Support", by Bruce Forsberg

1999.06.14 15:51 "Re: Large File Support", by Martin Bailey

I've been pondering the idea of large file support, and especially the ideal of minimising the impact that any changes would have on existing readers etc. I see backward compatibility as extremely important to ensure that any changes would be acceptable both to application creators and to the user community.

I agree with that goal, but I think that Frank Warmerdam's idea (allow multiple separate TIFF files to be logically "tiled" together to form a huge image) is a more practical approach, for the reasons already mentioned by him and John Aldridge.

Hmmm, I think we're seeing different requirements for different applications here.

My interest is in that I'm one of the task force working on TIFF/IT-P2, very firmly in the realm of graphic arts rather than image manipulation. One of the things that we want do do for P2 is to find a way of encoding FP, LW, CT, HC etc within a single file rather than multiple separate files to reduce the potential for missing files during transmission. That's a relatively obvious development from the existing TIFF/IT standard, until you start to think about the total file size.

I am reasonably sure that the approach I suggested would work fine for TIFF/IT, and the minimal intervention means that it is also something that we can include easily in the spec.

On the other hand, it has been suggested that tags and mechanisms that we add in TIFF/IT could be taken as ideas for inclusion in a future version of TIFF, and I would be reluctant to recommend something that would work for TIFF/IT and not for other, more general uses of TIFF. I would be even more reluctant to recommend such an approach for TIFF/IT if I expected that a future version of TIFF would add the same capability in a different, incompatible, way.

So here I am in a cleft stick.

It does occur to me, however, that your tiling approach is something that might logically fall out of the work we're doing for TIFF/IT. In P2 (and 'full' TIFF/IT in the P2 timeframe) it will be possible to reference many CT (or whatever) files within a single FP file, thus the FP could well be equivalent to your control file (embedding all components within a single file is only one option, it will still be valid to use multiple, separate, files). Obviously that means that the CT specification in TIFF/IT must allow for the colorspaces and compression schemes etc. that are needed for more general work. TIFF/IT-P2 is likely to allow for JPEG and Flate compression of CT data, but not LZW. In P2 it's likely to be limited to CMYK data (optionally plus spot colours). For mono data you could use MP rather than CT. It's possible to use RGB or UVL data if you use the full TIFF/IT spec rather than limiting to only P2.

Does all that make sense?

Regards

Martin Bailey

----------------------------------------------------------
 Digital Print & Publishing                 Harlequin Ltd
 martinb@harlequin.com           http://www.harlequin.com
----------------------------------------------------------
 I try to ensure that my views expressed here accord with
 my employers, but I am not a spokesman for Harlequin and
        the buck stops with me for what I say here
----------------------------------------------------------