Closed melissalinkert closed 5 years ago
Removing exclude label for retesting, as discussed with @sbesson. I will check the build tomorrow and re-exclude if needed.
The Ventana files currently in the repo have much smaller tile sizes than what this was meant to target (~1024x1360 vs. ~2300x1700).
/uod/idr/scratch/inbox/jpeg-big-tiles/77928-big-jpeg-tiles.tiff
is generated from curated/svs/public/77928.svs
and has 2400x1600 JPEG tiles that should make use of this case.
Tested with a variety of TIFF and OME-TIFF, mostly generated in a similar way to /uod/idr/scratch/inbox/jpeg-big-tiles/77928-big-jpeg-tiles.tiff
which was also tested. Comparisons were made with 6.2.0.
Overall this has certainly speed up the decompress time (the degree of which varies) and has no negative effect for other JPEG compressed images which are not impacted by this change.
The actual byte arrays returned matched the previous versions and have not been impacted.
@dgault now released as http://repo1.maven.org/maven2/org/openmicroscopy/ome-codecs/0.2.5/
Related to https://github.com/openmicroscopy/bioformats/pull/3336, backported from a private PR.
Increasing the buffer size for
BufferedInputStream
shows a modest improvement for large images (~2500x1600). The special case that checks if the type and dimensions of the buffer backing theBufferedImage
will reduce the amount of array allocation and copying needed for RGB images that are requested in interleaved order.This shouldn't have any impact on the actual byte array that is returned by
decompress(...)
. I wouldn't expect to see much of a performance difference for small JPEG files, but for most larger files and TIFF-based formats that use JPEG tiles there should be a noticeable improvement.