Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx016.isp.belgacom.be (inmx016.isp.belgacom.be [195.238.2.219])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i92AKiGJ010324
        for <joris.at.lebbeke@skynet.be>; Sat, 2 Oct 2004 12:20:44 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx016.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i92AKQcJ005444
        for <joris.at.lebbeke@skynet.be>; Sat, 2 Oct 2004 12:20:30 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id D686834768A; Sat,  2 Oct 2004 06:20:04 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from hog3.hogserve1.com (hog3.hogserve1.com [217.199.182.233])
	by xserve.flids.com (Postfix) with ESMTP id E7D60347666
	for <tiff@remotesensing.org>; Sat,  2 Oct 2004 06:20:02 -0400 (EDT)
Received: from 81-178-2-108.dsl.pipex.com ([81.178.2.108] helo=PLATO)
	by hog3.hogserve1.com with smtp (Exim 4.34)
	id 1CDgzf-0003k8-DP; Sat, 02 Oct 2004 11:19:59 +0100
Message-ID: <02ec01c4a869$6139d8f0$0200a8c0@PLATO>
From: "Andy Cave" <andy.cave@hamillroad.com>
To: "Joris" <joris.at.lebbeke@skynet.be>,
        "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>
References: <4.3.2.7.2.20041001123059.016e72d0@mailsrv1><415D8B80.5000300@pobox.com><p06110403bd833f3c7cf9@[153.32.220.138]><001d01c4a7de$cf92f6f0$e8c8c950@dfgrrxsknr4e><6.0.0.22.1.20041001135607.0263e220@pop.earthlink.net><p05210607bd837ef12142@[153.32.48.223]><005401c4a81e$228281c0$e8c8c950@dfgrrxsknr4e>
	<Pine.SOC.4.60.0410012039410.2727@blade.simplesystems.org>
Subject: Re: [Tiff] Re: BigTIFF extension issue
Date: Sat, 2 Oct 2004 11:20:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hog3.hogserve1.com
X-AntiAbuse: Original Domain - remotesensing.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - hamillroad.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: tiff@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 20d871dcf3d3abda5216d9a8ed8143d1

Hi All.

Lots of mails on this subject, so I'll add my £/p worth.

I don't think you can use the argument that no existing standard TIFF reader 
can read BigTIFF. The case of tiled tiff vs previous tiff is one example, 
but perhaps not a good one. So, take PostScript or PDF as perhaps a better 
example. We had PS Level 1, then Level 2 then Level 3. We had PDF 1.0, then 
1.2, then 1.3, then 1.4. I think everyone would agree that there was no new 
file format. But no laserprinter that was Level 1 could print a Level 2 
file. In this case one would argue that the file format was the same, but 
the commands/operators were different.

Re BigTIF, I think the file format is the same, but the data types are 
different (an 8 byte offset data type instead of a 4 byte). In fact I think 
one could argue that TIFF already supports varying data types of different 
byte lengths, albeit for tags, as values can often be SHORT or LONG etc... I 
think a 64bit offset type vs a 32bit offset type is exactly the same thing, 
but just applied in a different place (for offsets & sizes et al).

The actual format of the file is the same (header, offset tables, etc... 
compressed bands, tiles,...).

Re JPEG vs JPEG2000, the file format is not the same, as the file is only 
the compressed data stream, which is different. So, here I can see why a new 
extension was required.

If there is a tag in there indicating it's big tiff, apps can very soon rev 
to support this and give a warning. People have to upgrade their apps 
periodically, as older apps don't even run on later OSs. So within a few 
years all (most) the apps people use will deal with big tiff .tif[i] file 
correctly. And big tiff files will only be common in general open use (as 
opposed to closed loop systems) in a while anyway.

Yes sticking with .tif[f] does put pressure on us as a company to support 
it, as otherwise we get lots of support headaches. But then to stay 
competitive, we'd need to do this anyway. So it's a meaningless argument.

I think we should stick with .tif[f].

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.hamillroad.com

----- Original Message ----- 
From: "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>
To: "Joris" <joris.at.lebbeke@skynet.be>
Cc: <tiff@remotesensing.org>
Sent: Saturday, October 02, 2004 2:45 AM
Subject: Re: [Tiff] Re: BigTIFF extension issue


> On Sat, 2 Oct 2004, Joris wrote:
>> uncommon for applications to not be able to foresee future incompatible 
>> versions
>> of file formats, users do know that, and expect Photoshop 4.0 to eg not 
>> know
>> what a DNG file extension means. That is merely logical, no user expect 
>> up to
>> date behaviour from an outdated version.
>
> GraphicsMagick would attempt to read the DNG file like a normal TIFF file 
> and obtain poor results.  Extensions are almost meaningless except for as 
> a hint since responsible readers look at the file header instead (if they 
> can).  Users are usually illogical when something doesn't work.  Most 
> users won't know what BigTIFF is.
>
>> I feel the primary issue is: Is BigTIFF a new version? Or is it a new 
>> file
>> format? Let's decide, and be consistent, is what I propose. Do you plan 
>> to write
>
> Since no existing standard TIFF reader can read BigTIFF, it must be a new 
> file format.
>
> Bob
> ======================================
> Bob Friesenhahn
> bfriesen@simple.dallas.tx.us
> http://www.simplesystems.org/users/bfriesen
> _______________________________________________
> Tiff mailing list
> Tiff@remotesensing.org
> http://xserve.flids.com/mailman/listinfo/tiff
>
>
> 


_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
