Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-f.b-one.net (mx-f.one.com [91.198.169.53])
	by mail9.b-one.net (Postfix) with ESMTP id 0892B400164
	for <info@awaresystems.be>; Mon, 30 Nov 2009 10:15:55 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-f.b-one.net (Postfix) with ESMTP id 3F59797C
	for <info@awaresystems.be>; Mon, 30 Nov 2009 10:15:54 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id D45D11D1940CD;
	Mon, 30 Nov 2009 04:15:01 -0500 (EST)
Received: from mail.howardsilvan.com (216-235-106-HCC-115.hcc.net
	[216.235.106.115])
	by lists.maptools.org (Postfix) with ESMTPS id 3B8CB1D0E52A0
	for <tiff@lists.maptools.org>; Mon, 30 Nov 2009 04:05:12 -0500 (EST)
Received: from fangorn.howardsilvan.com (localhost [127.0.0.1])
	by mail.howardsilvan.com (Postfix) with ESMTP id 5BA0DC4200F;
	Mon, 30 Nov 2009 01:05:10 -0800 (PST)
Received: from bilbo.x101.com ([64.146.212.27] helo=bilbo.x101.com) with
	IPv4:25 by fangorn.howardsilvan.com; 30 Nov 2009 01:05:09 -0800
Message-ID: <4B138AC6.3010001@howardsilvan.com>
Date: Mon, 30 Nov 2009 01:05:10 -0800
From: Lee Howard <faxguy@howardsilvan.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: "Joris Van Damme (AWare Systems)" <info@awaresystems.be>
References: <4B1352B6.4000504@howardsilvan.com>
	<882876211D76438BB45D22ADE316B054@awarec74cb3e1c>
In-Reply-To: <882876211D76438BB45D22ADE316B054@awarec74cb3e1c>
Cc: TIFF mailing list <tiff@lists.maptools.org>
Subject: Re: [Tiff] TIFFTAG_JPEGTABLES mandatory for JPEG-in-TIFF since
 3.8.x ?
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Joris Van Damme (AWare Systems) wrote:
> From a JPEG point of view, there roughly exists two options.
> - One is to use standard tables. One good reason for doing this, is 
> that you want compression to be a single-pass process, when you need 
> compression speed and/or want to avoid the buffer involved in a 
> two-pass compression process.
> - The other option is to use optimized tables. One good reason for 
> doing this, is if you want the best possible compression ratio.

In this particular case I'm dealing with a JPEG image that is provided 
from a fax machine, and I'm merely wrapping it with TIFF in order to 
provide the application with multi-page color fax reception support in 
one file... as well as the ability to use other TIFF tags for data 
storage.  So unless I intend to alter the image that is provided by the 
fax machine (and I don't), then I just will be dealing with the JPEG as-is.

This is complicated somewhat by two things: 1) fax machines generally 
omit image length from the SOF marker and instead use a DNL marker - I 
take the data from the DNL marker and "fix" the SOF marker because DNL 
is largely unsupported by JPEG viewers/processors other than fax 
machines, and 2) fax machines use ITULAB colorspace - and I am now using 
LittleCMS to convert the colorspace to sRGB because ITULAB is largely 
unsupported by JPEG viewers/processors.  So those are two exceptions to 
the statement I made above.

> From a TIFF point of view, there roughly exist three options that make 
> sense, and then there's a fourth that sneaks in when there's editing 
> and recompressing being done on a limited number of strips or tiles.
> - One option corresponds to the use of standard tables in JPEG. When 
> you want the best possible compression speed and/or want to avoid the 
> buffer involved in a two-pass compression process, you can prefer to 
> have standard tables on all strips/tiles. In this case, it makes sense 
> not to include the tables in every single strip/tile, but to write 
> them only once in the JpegTables tag.

The entire JPEG image is written in one strip with TIFFWriteRawStrip.  
So I don't think that there's any savings to be had in this option.

> - Another option corresponds to the use of optimized tables. If you 
> want the best possible compression ratio, and your strips/tiles are 
> not too small, it may very well make sense to not include the 
> JpegTables tag, but include tables in every strip/tile, individually 
> optimized for the best possible compression ratio of that particular 
> strip/tile.

I can't speak to the optimization - I'd like to leave this as provided 
by the fax machine as much as possible although I am processing the 
image with LittleCMS - but this sounds like the case I am dealing with.  
I'd prefer to trust the fax machine (or LittleCMS) to be responsible for 
optimization.

> - If your strips/tile are reasonably small, and/or your picture is 
> reasonably uniform, I guess it may turn out the best possible 
> compression ratio may be to use tables that are optimized for the 
> complete picture instead of a single strip or tile, and include those 
> in a JpegTables tag, and not include them in every strip/tile. It may 
> be that the gain from including tables only once outweights the gain 
> from table optimization on an individual strip/tile basis.

I don't know exactly what "reasonably small" means, but I don't think 
that this is the case - see the sample to which I linked in the last 
mail.  But since there is only one strip I don't think that this option 
is applicable.

> - Last but not least, TIFF can support editing and rewriting of a 
> single tile or strip. In such cases, it can happen that the rewriter 
> includes tables in an individual strip/tile, that may be optimized for 
> that particular strip/tile, while the original writer choose to use 
> the JpegTables tag instead. As such, there can be tables in both the 
> JpegTables tag and in some or all of the strips/tiles. This too, is 
> perfectly legal, the latter taking precedence on any individual 
> strip/tile.

As the strip data will contain the same JPEG table information as would 
be included in any JPEGTABLES TIFF tag, I don't think this option is 
applicable, either.

>> Since I need to make the application be compatible with libtiff 3.8.2 -
>> if there's not a way to avoid writing TIFFTAG_JPEGTABLES with that
>> version when writing JPEG-in-TIFF, then I'll probably just need to write
>> TIFFTAG_JPEGTABLES properly... but I wanted to understand if this was
>> intentional behavior by libtiff, or if this is a bug, or if I just don't
>> know what I'm doing (likely).
>
> Must be categorized as a bug.

In libtiff/tif_jpeg.c there is this code at the very bottom of the file:

        /*
        ** Create a JPEGTables field if no directory has yet been created.
        ** We do this just to ensure that sufficient space is reserved for
        ** the JPEGTables field.  It will be properly created the right
        ** size later.
        */
        if( tif->tif_diroff == 0 )
        {
#define SIZE_OF_JPEGTABLES 2000
            TIFFSetFieldBit(tif, FIELD_JPEGTABLES);
            sp->jpegtables_length = SIZE_OF_JPEGTABLES;
            sp->jpegtables = (void *) _TIFFmalloc(sp->jpegtables_length);
            _TIFFmemset(sp->jpegtables, 0, SIZE_OF_JPEGTABLES);
#undef SIZE_OF_JPEGTABLES
        }

This code was added after 3.7.2 and before 3.8.2, and it is this code 
which is causing TIFFTAG_JPEGTABLES to be added to the created TIFF 
file.  If I comment-out this code then the tag is not put there.

Unfortunately, without the tag there I'm still not out of the woods.  
For example, running the TIFF file through tiff2ps gives me...

JPEGPreDecode: Warning, Improper JPEG sampling factors 2,2
Apparently should be 1,1..
JPEGPreDecode: Cannot honour JPEG sampling factors that exceed those 
specified..

Does this mean that I should be setting YCBCRSUBSAMPLING?

Thanks,

Lee.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
