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.10.03 13:09 "Re: Status of ISO JBIG and CIELAB JPEG support", by Joris Van Damme
Jean-Yves,
Jean-Yves Le Ridant wrote:
> I agree and its for parts a result, when trying to add some general
> support for lab/jpeg/tiff files, of dealing with specs, some "state of
> art" of libtiff 3.7.3 ( don't know if things have changed ), tifftools
> ( mainly tiffcp ), photoshop, and ... my own user's requests.
> ;-)
I think we've some communication problems going on... Let me again
attempt to be clear on one thing at least: most of these files are
perfectly OK. In fact, it's a surprise to see such good work and eye for
detail in an area where the producer of the files needs to put a lot of
specs and tools together, and that still is vague to some degree (as for
example when Subsampling mixes with Lab - some people say that
Subsampling simply doesn't apply to Lab, but then there's RFC 2301
(IIRC) saying otherwise, some other people have written ITULab files
with Subsampling and we need to be able to at least read these... So you
can't escape reality with an easy decision, this is a mess no matter
what).
> For what I remember, ( I have done this job in 06/2005), a problem
> for example, rely on default 2,2 subsampling ( when you enter "wide
> view" of subsampling).
> NB : photoshop handle jpeg/cielab ( with progressive in jpegtiff ?)
> and when saving an uncompressed cielab file, do not write a
> subsampling tag 1,1 ...
As far as this problem is concerned, the way my decoder handles this is
the following:
- if colorspace is YCbCr
- if Subsampling tag is not present
-> assume TIFF 6.0 default [2,2] applies
- else
-> assume Subsampling tag is correct
- else if colorspace is CIE, ICC or ITU Lab
- if Subsampling tag is not present
-> assume writer thinks subsampling doesn't apply, i.e. assume
[1,1]
- else
-> assume writer thinks subsampling applies, i.e. that this tag
is correct
- else
-> assume no subsampling, regardless of tag presence
Next, if compression scheme can support deriving Subsampled values from
the compressed data, as does for instance JPEG and OJPEG compression, I
allow this to correct the values. This last bit is expense, well, not
really, but it's expensive overhead compared to the simple reading of a
tag anyway. The good news is that it's not really that necessary, above
scheme without this last bit will yield correct values (as in writer
intention that corresponds to the actual data in there) 99% of the time.
With this last bit in place, I arrive at something like 99.9%. (All
percentage are a figure of speech to give you some idea - I'm not able
to measure since it's impossible to guarantee any set of testfiles is
representative for the hole of the files out there.)
I've not yet made a definite choice in the encoder, though. So I for one
am hoping someone with authority tries to clean up this confusion in a
proper manner. (For example by allowing encoders to either disregard or
apply subsampling to CIE, ICC, and ITU Lab, at will, by making the
default for this tag be [1,1] as far as these Photometrics is concerned.
Messy to have the default depend on the value of another tag, but it may
very well be the only way out, and it certainly is consistent with the
files out there already.)
Best regards,
Joris