2006.10.19 12:56 "Re: [Tiff] Status of ISO JBIG and CIELAB JPEG support", by LERIDANT Jean-Yves

Joris a écrit:

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...

Yes and no! I didn't take anything in offense :-)) Just something like a "hard disk failure" on my main worstation added to parano network administration..., and coming with Thunderbird Please, tell me what about this html <censored> for this list.

Rather, I highly appreciate someone submit my files to his own "inspector". "Le diable habite les détails", especially when... "enhancing" some small area of a so widely dispatched soft as libtiff, and some lack of feed back is one of the reason why this job is "suspended" since one year.

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

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.)

The above "policy" look very like where I came in my jobs, with some difference,

there's no real "codec", and are handled by changes in libtiff ( not so much except tif_jpeg.c )

and tiffcp. This is a *bad thing*, resulting of historical reasons: I have been

long to understand that no serious job could be done without exploring in depth some

process involded around for example JPEG_COLOR_MODE pseudo tag... ;-)))

More, one of my major goal was to "way out horrible jpeg CIELAB files", so I used

this pseudo tag to have a parallel relationship CIE/ICC as RGB/YCC defaut transformation.

Then added a flag to "raw decompress" and it is "logic" : no color

transform but

no upsampling anymore ---> interleaved subsampled file as every one like them :-)))

And ITU is proceeded at end exactely like YCC, except tags.

This is approx "the state of my art".

:-)

Restarting this job ( has someone ITU lab files, is there some "authority" somewhere ?)

I think all this policy could be handled by extendORing the JPEG_COLOR_MODE pseudo tag, with respect of "oldunaware" _RGB _RAW. It is not a tremendous job,

as soon as some mechanism in the lowlevel part of tif_jpeg.c are reliable. It was not the case, in version 3.7.3: I persist some of the problem of too many

too few scanline, tiffcp crashes,... are in tif_jpeg when leaving the usual sheme RGB -->

YCC 2:2 ---> RGB

Best regards

--
Jean-Yves

>
>
>