AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
February 2008

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



Valid HTML 4.01!



Thread

2008.02.15 14:36 "bug? JPEGQUALITY seems not to be read correctly", by <jcupitt@gmail.com>
2008.02.15 14:57 "Re: bug? JPEGQUALITY seems not to be read correctly", by Ed Grissom
2008.02.15 15:02 "Re: bug? JPEGQUALITY seems not to be read correctly", by <jcupitt@gmail.com>
2008.02.15 15:14 "Re: bug? JPEGQUALITY seems not to be read correctly", by Ed Grissom
2008.02.18 10:44 "Re: bug? JPEGQUALITY seems not to be read correctly", by Gerben Vos
2008.02.18 12:29 "Re: bug? JPEGQUALITY seems not to be read correctly", by <jcupitt@gmail.com>
2008.02.18 13:12 "Re: bug? JPEGQUALITY seems not to be read correctly", by Joris Van Damme
2008.02.18 14:23 "Re: bug? JPEGQUALITY seems not to be read correctly", by Joris Van Damme
2008.02.15 17:51 "Re: bug? JPEGQUALITY seems not to be read correctly", by Bob Friesenhahn

2008.02.18 13:12 "Re: bug? JPEGQUALITY seems not to be read correctly", by Joris Van Damme

John,

jcupitt@gmail.com wrote:
> On 18/02/2008, Gerben Vos <Gerben@zylab.com> wrote:
> > Some rather sophisticated code is available on the Internet to
> > reconstruct the quality value from the tables in a JPEG.
>
> Another approach might be to make TIFFTAG_JPEGQUALITY into a real tag.
> This could be a simpler solution, and almost as good.
>
> I noticed that TTN2 (the revised JPEG-in-tiff note) obsoleted tags 512
> -- 521. Perhaps one of these could be reused? RESTART interval,
> perhaps (it's a TIFF_SHORT):

Reusing obsoleted tags for new purposes isn't a legit approach. New
purposes, requires new tags, to be newly allocated from Adobe.

> Old-style jpeg-in-tiff would be unaltered. Of course Q settings are
> not transferrable between jpeg implementations, but it sounds like the
> Q guessers are not exact either. It seems to me that saving the Q
> setting as a hint would not be any worse in practice than adding a Q
> guesser and would be far simpler (just a few lines of code).

One point that makes this whole argument moat is that this LibJpeg quality
setting we're all familiar with, ranging from 0 to 100 is itself a LibJpeg
specific measure. Other JPEG codec implementations might use a quality
parameter with three different settings, or five, or whatever. Some
implementations don't reflect quality as a direct scaling of quanitzation
tables, but have specific experimentally derived optimal quantization tables
for a more limited range of quality settings. Defining a tag that reflects a
measure very specific to the LibJpeg implementation is dodgy, at best.

Another thing is, there's a number of other things that influence quality,
aside from the one you all seem to be focussing on which is quantization
table scaling. There's also, for example, rounding issues that can become
significant in fast small-bit-sized integer approaches that sit well with
SIMD, measured against double precision floating point reference approaches.
And last but not least, there's the quality and file size impact of
subsampling, in TIFF speak that could range from [1,1] to [4,4] which does
make a very substantial impact.

This already hints there's two more fundamental questions to ask, here. What
is 'quality'? And last but certainly not least, why should we care to make
any guess or preservation? Could the need in some cases perhaps be an 
indication of some wrong thinking somewhere else along the process path?


Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html