You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parallelizing decoding is straight-forward with TIFFs since they are composed of separately-encoded strips or tiles
One might say this should be done at the client/file level, but for large files it may be convenient to have it done at the strip level, especially in an interactive context
Here are results I get for a variety of LZW-compressed images--from tiny to huge, for white noise and solid color--showing a win for all but the smallest, simplest images
white noise
serial (s)
parallel (s)
25.06848
3.21034
2.06287
0.30021
0.27048
0.07222
0.06873
0.02438
0.00174
0.00331
solid color
serial (s)
parallel (s)
1.35969
0.88756
0.08941
0.05104
0.00777
0.01789
0.00193
0.00331
0.00012
0.00023
The text was updated successfully, but these errors were encountered:
💯 This would be great to have, it would potentially resolve #19 as well. I agree that the TIFF format lends itself nicely to parallelization. I just haven't had the bandwidth to tackle it, but would review any PR if you want to tackle it (looks like you might have a first draft already?)
The small TIFF issue could be fixed with some simple logic to parallelize if an image above a certain size/# of strips/etc
Parallelizing decoding is straight-forward with TIFFs since they are composed of separately-encoded strips or tiles
One might say this should be done at the client/file level, but for large files it may be convenient to have it done at the strip level, especially in an interactive context
Here are results I get for a variety of LZW-compressed images--from tiny to huge, for white noise and solid color--showing a win for all but the smallest, simplest images
white noise
solid color
The text was updated successfully, but these errors were encountered: