Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-v.one.com (mx-v.one.com [195.47.247.147])
	by mail6.local.one.com (Postfix) with ESMTP id 90C84300306283
	for <filtered@awaresystems.be>; Mon, 15 Dec 2014 23:48:17 +0000 (UTC)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-v: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.217.172 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172])
	by mx-v.one.com (Postfix) with ESMTP id 5D76AFC9BAC
	for <filtered@awaresystems.be>; Mon, 15 Dec 2014 23:48:17 +0000 (UTC)
Received: by mail-lb0-f172.google.com with SMTP id u10so10153582lbd.3
        for <filtered@awaresystems.be>; Mon, 15 Dec 2014 15:48:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-original-authentication-results:delivered-to:delivered-to
         :mime-version:in-reply-to:references:date:message-id:from:to:cc
         :subject:precedence:list-id:list-unsubscribe:list-archive:list-post
         :list-help:list-subscribe:content-type:content-transfer-encoding
         :sender:errors-to;
        bh=UDRXi6eweLoyIpWWWNsBhQ+spBhsa5eDgk3lGvzCGz8=;
        b=Z5gkl2fFb8zsGRrdo8JP9mqPOTrg+zWCQ0/7TjOZOZLyc+exwU6ua0NALsdITyhgf2
         RWG5s9f7J8O0ADw3CJjRP2iS+Y5k69h9wOgEvNLzM4v17Fi49FW0snvj4qrn7FhXb0Eq
         b+D8+H6GQsYON8vQ2VJCMJA1NPiCiz3BSzXn2Ty3am7deQTyi85ZsX+T1DQwTVPQafJ1
         4T+wdZUXZ/61hBZlO54UhZXw4hoThpRkdLosoU2OrtnIY/pHzp41TsDZc5FVIUM8xRXi
         tY96qpY1aErjukSObqL916OqLjcBauNT+/LSpTI/i0VvpP0x6DnYDzVKhG4Mm1sJWVFd
         CaMg==
X-Original-Authentication-Results: mx.google.com;       spf=none (google.com: tiff-bounces@lists.maptools.org does not designate permitted sender hosts) smtp.mail=tiff-bounces@lists.maptools.org
X-Received: by 10.152.5.198 with SMTP id u6mr33434923lau.42.1418687297016;
        Mon, 15 Dec 2014 15:48:17 -0800 (PST)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.114.181.134 with SMTP id dw6csp325807ldc;
        Mon, 15 Dec 2014 15:48:16 -0800 (PST)
X-Received: by 10.112.145.37 with SMTP id sr5mr33690456lbb.76.1418687295626;
        Mon, 15 Dec 2014 15:48:15 -0800 (PST)
Authentication-Results: mx.google.com;
       spf=none (google.com: tiff-bounces@lists.maptools.org does not designate permitted sender hosts) smtp.mail=tiff-bounces@lists.maptools.org
Received-SPF: none (google.com: tiff-bounces@lists.maptools.org does not designate permitted sender hosts) client-ip=195.47.247.73;
Received: by 10.152.105.137 with POP3 id gm9mf4821772lab.39;
        Mon, 15 Dec 2014 15:48:15 -0800 (PST)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx02.one.com (mx02.one.com [195.47.247.73])
	by mail6.local.one.com (Postfix) with ESMTP id B22E0300306283
	for <info@awaresystems.be>; Mon, 15 Dec 2014 23:45:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (ks365428.kimsufi.com [94.23.4.142])
	by mx02.one.com (Postfix) with ESMTP id 7DF2FFBE71B
	for <info@awaresystems.be>; Mon, 15 Dec 2014 23:45:28 +0000 (UTC)
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 0BACE35C030;
	Mon, 15 Dec 2014 18:44:41 -0500 (EST)
Received: from mailrelay8.public.one.com (mailrelay8.public.one.com
	[91.198.169.216])
	by lists.maptools.org (Postfix) with ESMTPS id CF36635C024
	for <tiff@lists.maptools.org>; Mon, 15 Dec 2014 18:44:21 -0500 (EST)
X-HalOne-Cookie: a91ac99de0fa9ec31aa031911560783fcef8ac43
X-HalOne-ID: fc5d47e1-84b3-11e4-bf9a-b82a72cffc46
Received: from mail-la0-f51.google.com (unknown [209.85.215.51])
	by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA
	for <tiff@lists.maptools.org>; Mon, 15 Dec 2014 23:42:09 +0000 (GMT)
Received: by mail-la0-f51.google.com with SMTP id ms9so10332097lab.10
	for <tiff@lists.maptools.org>; Mon, 15 Dec 2014 15:44:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.170.7 with SMTP id ai7mr33419066lbc.67.1418687066914;
	Mon, 15 Dec 2014 15:44:26 -0800 (PST)
Received: by 10.114.246.4 with HTTP; Mon, 15 Dec 2014 15:44:26 -0800 (PST)
In-Reply-To: <201412152349.08894.even.rouault@spatialys.com>
References: <201412151849.41073.even.rouault@spatialys.com>
	<201412152117.36105.even.rouault@spatialys.com>
	<CA+NZCsS8Om-hNsSTH6h_n3GEATD3t+qcVgJDa0UcLw--4ewSAQ@mail.gmail.com>
	<201412152349.08894.even.rouault@spatialys.com>
Date: Tue, 16 Dec 2014 00:44:26 +0100
Message-ID: <CA+NZCsS7sHoCUY37ZRE91qiR6PCghXXLvSW=Wk0pXaFzM0PhTw@mail.gmail.com>
From: "Joris Van Damme (AWare Systems)" <info@awaresystems.be>
To: Even Rouault <even.rouault@spatialys.com>
Cc: gdal-dev@lists.osgeo.org, TIFF <tiff@lists.maptools.org>
Subject: Re: [Tiff] Unnecessary bigger JPEG-compressed TIFF
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

Even,

>> Besides, my reasoning is, if table size
>> does contribute even remotely significantly to the file size, then
>> RowsPerStrip or TileWidth+TileHeight is very badly chosen.
>
> Well, I think the intent of TIFFTAG_JPEGTABLESMODE = 3 (the default mode) is
> to avoid writing quantization&huffman tables in tiles/strips when it is not
> necessary. And more generally achieving the smallest binary size seems to be a
> reasonable objective.

Absolutely.

Of course, the whole scheme (nearly) dates back to times when
recommended strip/tile data size was 8 kilobyte uncompressed. These
days, I'd say a recommended size for a strip or tile is several orders
of magnitude larger, maybe around a megabyte or such, uncompressed, so
maybe something like 100 kilobyte JPEG compressed with reasonably low
quality and 2,2 subsampling. So you'd have to weigh the size of the
tables against that. I figure the average size of the tables is about
half a kilobyte.

Still, absolutely some people/files still lean towards having
strip/tile sizes a bit smaller, maybe quite a bit smaller. And even if
they are not, achieving smallest binary size is absolutely a
reasonable objective, and so is any attempt to stop duplication of the
same data, as a matter of principle. In that light, maybe my "not
significant" comment is not all that correct. Of course, the context
of that comment was merely a secondary bullet point in a decision I
made inside a library that defaults to strip/tile sizes of about a
megabyte uncompressed.

> perhaps it does, just haven't a test example
> handy
> ...
> I'm not saying doing something better is impossible, it is just that I don't
> feel pursuing that right now ;-) Trivial changes in that code have a high
> chance of causing issues in some cases, so non-trivial changes, and especially
> since I don't think the test suite actually tests that a lot.

Absolutely.

If at any point in the future testfiles with any particular variations
on these schemes are required, I can easily generate those, and we'd
have the added benefit of crosstesting.


Best regards,

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