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.26 16:01 "Re: OpenMP enabled libtiff", by Aaron Boxer

On Tue, Jan 26, 2016 at 9:46 AM, Olivier Paquet <olivier.paquet@gmail.com>
wrote:

> 2016-01-26 8:45 GMT-05:00 Aaron Boxer <boxerab@gmail.com>:
> > Sounds like the simplest approach is to allow the user to set a lock
> > callback method,
> > which, if not null, will protect the global/static variables with a lock
> of
> > the user's choice.
>
> I'm not sure that would do much without a lot of other work. As has
> been said, the bulk of CPU work is in the compressors and if I
> remember correctly they have a significant amount of preallocated
> state. This needs to be duplicated for each thread to get any useful
> speedup.
>
> IMO, the cleanest approach is to split read/write and
> decompression/compression and make the latter thread safe (no
> global/static data in that part of the code). Then OpenMP or whatever
> else can be used at a higher level to run the compression work in
> multiple threads.
>
> It's all a lot of work though because the code is not written with
> that in mind at all and the compressor can change when you move to a
> different IFD. As we only needed multithread reading in our project,
> what we did instead is use several TIFF handles on the same file. This
> works well enough for reading.
>


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.

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.

Aaron