AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2016

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2016.01.25 18:25 "OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 19:05 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 19:17 "Re: OpenMP enabled libtiff", by <kandel3@illinois.edu>
2016.01.25 19:18 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.25 20:21 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 20:45 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.25 23:27 "Re: OpenMP enabled libtiff", by <kandel3@illinois.edu>
2016.01.26 09:12 "Re: OpenMP enabled libtiff", by <jcupitt@gmail.com>
2016.01.26 13:45 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 14:46 "Re: OpenMP enabled libtiff", by Olivier Paquet
2016.01.26 16:01 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 17:10 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.26 19:32 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 19:29 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 20:36 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.27 18:32 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.27 19:55 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.29 13:28 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 14:46 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.29 15:48 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 15:49 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 18:12 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.26 09:36 "Re: OpenMP enabled libtiff", by Mat Maher
2016.01.26 09:52 "Re: OpenMP enabled libtiff", by Even Rouault
2016.01.26 14:22 "Re: OpenMP enabled libtiff", by Fred Rothganger
2016.01.27 18:51 "Re: OpenMP enabled libtiff", by Larry Gritz

2016.01.27 18:51 "Re: OpenMP enabled libtiff", by Larry Gritz

It may be instructive to look at what OpenEXR did (technically, libIlmImf).
If you use the API calls that read or write more than one scanline or thread
at a time, it will use a thread pool to work in parallel on the
compression/decompression or data conversion of the separate compressed
chunks that comprise that section of the image, which often is the bulk of
the wall clock time. If you have threads to spare, it really does speed up
the reads/writes almost linearly (it's the disk I/O that is still
serialized). Of course, if you use the API calls to read/write a single
scanline or tile, the threads don't do anything.

This turns out to be a very valuable feature, and in many applications that
tend to read or write whole images at once, can tremendously speed up
throughput. For certain access patterns and thread availability, it can be
used to read or write an exr file many times faster than the equivalent TIFF
file.


> On Jan 27, 2016, at 9:00 AM, Bob Friesenhahn
> <bfriesen@simple.dallas.tx.us> wrote:
> 
> Date: Tue, 26 Jan 2016 11:10:59 -0600 (CST)
> From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
> Subject: Re: [Tiff] OpenMP enabled libtiff
> To: Aaron Boxer <boxerab@gmail.com>
> Cc: TIFF mailing list <tiff@lists.maptools.org>
> Message-ID:
> 	<alpine.GSO.2.01.1601261103040.24533@freddy.simplesystems.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> On Tue, 26 Jan 2016, Aaron Boxer wrote:
>> 
>> Yes, so you don't think there is a "quick and dirty" solution for
>> speeding up compressed reading?
>> 
>> For my purposes, I am only interested in reading uncompressed files, so
>> TIFFClientOpen
>> on a memory buffer should be good enough.
> 
> Libtiff is very fast at reading from uncompressed files and I don't 
> see much performance penalty as compared with accessing files using 
> system APIs.
> 
>> But, I still think it is a shame to leave the library single threaded in
>> this multi-core world.
>> It is just finding the time to work on improvements.
> 
> It is likely that adding threading would just make it slower for many 
> common cases and it adds a link-time dependency which otherwise does 
> not exist.  It is much better to enable threaded applications to make 
> better use of libtiff when accessing one file.  What works in one use 
> case may be totally inappropriate for another.  Preserve the 
> application writer's freedom to chose the best solution for the 
> application.  Most importantly, we can not afford to break the 
> existing libtiff API and ABI.
> 
> Bob
> -- 
> Bob Friesenhahn
> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> 

--
Larry Gritz
lg@larrygritz.com


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