Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-q.b-one.net (mx-q.one.com [91.198.169.248])
	by mail9.b-one.net (Postfix) with ESMTP id DF4C840024C
	for <info@awaresystems.be>; Tue, 29 Mar 2011 22:25:34 +0200 (CEST)
Received: by mx-q.b-one.net (Postfix, from userid 106)
	id 9C83DFD5B; Tue, 29 Mar 2011 22:24:34 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=0 required=4
 tests=[HTML_MESSAGE=0.001]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-q.b-one.net (Postfix) with ESMTP id 65A8039285 for <info@awaresystems.be>;
 Tue, 29 Mar 2011 22:24:27 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id CF1C586CB5; Tue, 29 Mar 2011
 15:22:58 -0500 (EST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by
 lists.maptools.org (Postfix) with SMTP id B13A386BFE for
 <tiff@lists.maptools.org>; Tue, 29 Mar 2011 15:17:26 -0500 (EST)
Received: (qmail invoked by alias); 29 Mar 2011 20:17:24 -0000
Received: from 91-65-64-125-dynip.superkabel.de (EHLO [192.168.0.101])
 [91.65.64.125] by mail.gmx.net (mp038) with SMTP; 29 Mar 2011 22:17:24 +0200
X-Authenticated: #27160015
X-Provags-ID: V01U2FsdGVkX18z+K1zQ+kzVM5ZGRpKx9Bp2Fp8JpXaVjWRAiEqZY
 DVJuccY6qcWuDe
Date: Tue, 29 Mar 2011 22:17:20 +0200
From: Stephan Busch <squeezechart@gmx.de>
Organization: SqueezeChart Stephan Busch, Compression Strength Auditor
X-Priority: 3 (Normal)
Message-ID: <1867702403.20110329221720@gmx.de>
To: Thomas Richter <thor@math.tu-berlin.de>
In-Reply-To: <4C20BEB1.3020309@math.tu-berlin.de>
References: <983549761.20100621141400@gmx.de> <4C1F69C7.20607@pobox.com>
 <1782495269.20100621234917@gmx.de> <1571714274.20100622113328@gmx.de>
 <4C20BEB1.3020309@math.tu-berlin.de>
MIME-Version: 1.0
X-Y-GMX-Trusted: 0
Cc: tiff@lists.maptools.org
Subject: [Tiff] LibTIFF compression enhancements
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>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Dear Thomas,

it has been a while since we last talked.
I suggested a new lossless code for usage within your TIFF library.
Neither PackPNM nor the popular JPEG2000 has been implemented by now.

Today I also want to suggest a new codec.

It is fast. It is free. It is open-sourced.

BCIF by Stefano Brocchi

http://www.dsi.unifi.it/users/brocchi/

The caveat is that it supports 24-bit color images only by now.

The author would be interested in adding BCIF to your TIFF library.
What do you think?



Looking forward to your answer

Regards,
Stephan

________________________________________________________________________
> Hi,

>> So far I haven't heard of any TIFF libraries that use jpeg2000 algorithm=
s,
>> but its sad that all those maintainers could not agree to use a unified=
=20
>> version all libraries could read.

> I'm not quite clear what you mean by that. JPEG2000 is standardized, and
> if TIFF tags for J2K are specified, you should be able to include it.=20
> However, I probably don't see the point. J2K defines its own file=20
> format, avoiding typical TIFF problems like the 4GB barrier, thus I=20
> wonder why anyone would want to do that.

>> LOCO-I is the algorithm behind JPEG-LS. It was designed a decade ago by=
=20
>> HP Labs,
>> gives better compression than jpeg2000 in most cases and there are many=
=20
>> implementations;
>> some of them are open-sourced such as:
>> www.stat.columbia.edu/~jakulin/jpeg-ls

> While I certainly agree for lossless compression, just a note: Please do
> not use the above implementation, it has a bug in bit depths > 8 and=20
> creates files that do not conform to the specs - it's an endian issue=20
> that can be easily fixed, but that is nevertheless there.

> JPEG-LS is certainly a nice tiny codec that shouldn't take up too much
> time to implement (hopefully then correctly) but are there TIFF tags for =
it?

>> In the case neither jpeg2000 nor jpeg-ls are implementable, I wanted to=
=20
>> suggest
>> another codec that will be free and open-sourced soon. The algorithm is=
=20
>> called PackPNM at present
>> and it performs like jpeg-ls.

> I have never seen or heard about this one. I would prefer algorithms=20
> that are openly available, actually.

>> Also, in my opinion only the codec that you will chose might survive.=20
>> All high performance image codecs
>> have been designed but were never implemented for practical use.=20

> What do you mean by that? JPEG-LS and JPEG 2000 have been implemented=20
> for practical use for sure.

> So long,
>         Thomas
Stephan Busch
