Libtiff 4.4.0beta4 Released

[Bob Friesenhahn]

Libtiff 4.0.0beta4 is now released.  Please read about it at
http://www.remotesensing.org/libtiff/v4.0.0.html.

Source packages are available at ftp://ftp.remotesensing.org/pub/libtiff and
will soon be available at mirror sites.

Libtiff 4.0.0beta4 is produced from the default branch in the libtiff
CVS repository.  Its focus is to introduce major new features such as
support for BigTIFF.  Libtiff 4.0.0 is NOT ABI compatible with 3.X.X
releases.  In particular, it uses a 64-bit toff_t and 64-bit tmsize_t.

Existing applications are likely to work with libtiff 4.0.0 with a
simple re-compile as long as they took care to use libtiff typedefs
and avoid sloppy casting.  The most common problem is with code which
assumes that a returned file offset or size can be stored in a 32-bit
type.  Users of libtiff are encouraged to test their applications with
libtiff 4.0.0beta4 and make any required changes so that their
application will work with it.

There is reason to believe that libtiff 4.0.0beta4 is as reliable as
the stable releases.

Please report any bugs according to the procedure documented at
http://www.remotesensing.org/libtiff/bugs.html.

Thanks,

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Kevin Myers-2]

Sometime within the past few months, I recall seeing a message posted on the
Tiff list where the poster had some kind of idea regarding how to support
both old and new JPEG compression in tiff files using the same libtiff, i.e.
no need to compile separate versions.  Does anyone else recall this?  Does
anyone know if or when this might get included in a release?

The reason I ask is that because I recently found that my high dollar Kodak
i280 scanner produces *old* JPEG compressed grayscale images of standard
documents, while on the other hand it also produces *new* JPEG compressed
color images for stitched long documents (e.g. well logs).  Stuff like this
just kills me.  What kind of developer would implement conflicting garbage
like that, especially for a multi-thousand dollar scanner?  Anyway, I also
found out that my irreplaceable legacy well log display application is only
capable of displaying *old* JPEG compressed images, while most of my other
image related applications expect to deal with *new* JPEG compressed images.

I hate to keep two separate versions of libtiff around just for dealing with
these issues.  The libtiff message that I recall seeing appeared to be a
potential solution to these problems, but I wasn't aware of the related
problems with my own applications, and didn't realize how important this
would end up being for my own usage.  Therefore I didn't keep the original
message, and don't recall the poster's name or the actual subject of the
message.

Hope I wasn't dreaming...

Thanks,
Kevin M.




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

[Edward Lam]

Hi,

Bob Friesenhahn wrote:
> Libtiff 4.0.0beta4 is now released.  Please read about it at
> http://www.remotesensing.org/libtiff/v4.0.0.html.

There's a new JPEG_DUAL_MODE_8_12 define, but it is only mentioned in
the tif_config.h and NOT in the other platform specific versions like:
       tif_config.h-vms tif_config.vc.h tif_config.wince.h
It would be nice if it was alse mentioned in those files as well.

So this brings up a second issue. Is the code for this define safe to
enable when compiling libtiff for general purpose usage? What are its
requirements? Is libjpeg6b enough?

Regards,
-Edward
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

On Thu, 27 Aug 2009, Kevin Myers wrote:

> Sometime within the past few months, I recall seeing a message
> posted on the Tiff list where the poster had some kind of idea
> regarding how to support both old and new JPEG compression in tiff
> files using the same libtiff, i.e. no need to compile separate
> versions.  Does anyone else recall this?  Does anyone know if or
> when this might get included in a release?

Is there a libtiff which writes old JPEG format?  If so, it must be
really old (3.5.6?).  The Adobe technical note which describes new
JPEG format is dated 2002.  Libtiff 3.9.0 and later provide decent
support for reading old JPEG format.

There are no future plans for libtiff to write old JPEG format.

> The reason I ask is that because I recently found that my high
> dollar Kodak i280 scanner produces *old* JPEG compressed grayscale
> images of standard documents, while on the other hand it also
> produces *new* JPEG compressed color images for stitched long
> documents (e.g. well logs).  Stuff like this just kills me.  What
> kind of developer would implement conflicting garbage like that,
> especially for a multi-thousand dollar scanner?  Anyway, I also

Ugggh!

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Edward Lam]

Bob Friesenhahn wrote:
> The most common problem is with code which
> assumes that a returned file offset or size can be stored in a 32-bit
> type.  

Are there tag values that have been changed from 32-bit to 64-bit? Does
it still work if we call something like:

     TIFFSetField(myTiff, TIFFTAG_ROWSPERSTRIP, rowsperstrip);

where rowsperstrip is a 32-bit integer?

Thanks,
-Edward

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

[Bob Friesenhahn]

On Thu, 27 Aug 2009, Edward Lam wrote:

> There's a new JPEG_DUAL_MODE_8_12 define, but it is only mentioned in the
> tif_config.h and NOT in the other platform specific versions like:
>      tif_config.h-vms tif_config.vc.h tif_config.wince.h
> It would be nice if it was alse mentioned in those files as well.
>
> So this brings up a second issue. Is the code for this define safe to enable
> when compiling libtiff for general purpose usage? What are its requirements?
> Is libjpeg6b enough?

See http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG for a description of
what this is.

Libjpeg 7 is out now, but there are not yet similar patches for it.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Frank Warmerdam-2]

Edward Lam wrote:

> Hi,
>
> Bob Friesenhahn wrote:
>> Libtiff 4.0.0beta4 is now released.  Please read about it at
>> http://www.remotesensing.org/libtiff/v4.0.0.html.
>
> There's a new JPEG_DUAL_MODE_8_12 define, but it is only mentioned in
> the tif_config.h and NOT in the other platform specific versions like:
>        tif_config.h-vms tif_config.vc.h tif_config.wince.h
> It would be nice if it was alse mentioned in those files as well.
>
> So this brings up a second issue. Is the code for this define safe to
> enable when compiling libtiff for general purpose usage? What are its
> requirements? Is libjpeg6b enough?

Edward,

I would note that the JPEG_DUAL_MODE support is for both 8bit and 12bit
jpeg in tiff.  It is unrelated to "old jpeg" mode.  The effort is
discussed at:

   http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG

It requires the latest libjpeg code from the libjpeg.sourceforge.net
cvs repository which may be considered a fork outside of the
independent jpeg group of jpeg 6b for maintenance purposes.

It is desirable to better describe this functionality in the libtiff
docs if there is interest; however, outside the geospatial community I
haven't heard of much interest in 12bit jpeg in tiff.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

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

[Bob Friesenhahn]

On Thu, 27 Aug 2009, Edward Lam wrote:

> Bob Friesenhahn wrote:
>> The most common problem is with code which
>> assumes that a returned file offset or size can be stored in a 32-bit
>> type.
>
> Are there tag values that have been changed from 32-bit to 64-bit? Does
> it still work if we call something like:
>
>     TIFFSetField(myTiff, TIFFTAG_ROWSPERSTRIP, rowsperstrip);
>
> where rowsperstrip is a 32-bit integer?

TIFFTAG_ROWSPERSTRIP is still limited to 32-bits.  However, tags which
return file offsets or object sizes are necessarily 64-bits.  These
tags are 64-bits:

   TIFFTAG_STRIPOFFSETS
   TIFFTAG_STRIPBYTECOUNTS
   TIFFTAG_FREEOFFSETS
   TIFFTAG_FREEBYTECOUNTS
   TIFFTAG_TILEOFFSETS
   TIFFTAG_TILEBYTECOUNTS

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/