[
https://issues.apache.org/jira/browse/IMAGING-259?focusedWorklogId=438936&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-438936
]
ASF GitHub Bot logged work on IMAGING-259:
------------------------------------------
Author: ASF GitHub Bot
Created on: 29/May/20 20:48
Start Date: 29/May/20 20:48
Worklog Time Spent: 10m
Work Description: kinow closed pull request #78:
URL: https://github.com/apache/commons-imaging/pull/78
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 438936)
Remaining Estimate: 0h
Time Spent: 10m
> Enhance TIFF DataReaders speed for compressed RGB
> -------------------------------------------------
>
> Key: IMAGING-259
> URL: https://issues.apache.org/jira/browse/IMAGING-259
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: TIFF
> Affects Versions: 1.0-alpha1
> Reporter: Gary Lucas
> Assignee: Bruno P. Kinoshita
> Priority: Minor
> Fix For: 1.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TIFF files support many different formats, some of them legacy or specialty
> formats, others that are widely used. DataReaderStrips and DataReaderTiled
> were originally written with a single block of code that collected the raw
> data (samples) for each pixel and then passed it into a single method that
> branched depending on the format. This approach meant that for each pixel,
> the reader loops had the extra overhead of a method call that executed
> multiple conditional evaluations. In 2012, enhancements were added to imaging
> to execute dedicated blocks of code for a few commonly used formats, most
> notably 3-byte RGB. However, at this time, the code does not support the
> case where the RGB is stored with a differencing predictor. Predictors
> improve the compression ratios (often significantly) when compressing RGB
> images. So I propose to enhance the dedicated RGB code to support predictors.
> Here's an example of some performance testing on a large image that uses
> compression with imaging. The time to load images was extracted using the
> ApacheImagingSpeedAndMemoryTest.java code that is included in the examples
> directory in the Commons Imaging code distribution.
> Processing file: CONUS_LandWaterMask_LZW_RGB.tif (original)
> image size: 6000 by 4000
>
> {noformat}
> Processing file: CONUS_LandWaterMask_LZW_RGB.tif (original)
> image size: 6000 by 4000
> time to load image -- memory
> time ms avg ms -- used mb total mb
> 971.817 0.000 -- 213.592 252.000
> 921.690 0.000 -- 143.229 260.000
> 895.587 895.587 -- 96.234 174.000
> 899.227 897.407 -- 117.259 154.000
> 899.078 897.964 -- 134.200 184.000
> 889.602 895.873 -- 143.226 180.000
> 896.170 895.933 -- 128.183 188.000
> 894.250 895.652 -- 97.187 178.000
> 896.436 895.764 -- 103.226 186.000
> 891.540 895.236 -- 119.185 171.000
> Processing file: CONUS_LandWaterMask_LZW_RGB.tif (with changes)
> image size: 6000 by 4000
> time to load image -- memory
> time ms avg ms -- used mb total mb
> 498.123 0.000 -- 212.589 252.000
> 423.136 0.000 -- 110.733 237.000
> 396.021 396.021 -- 100.735 164.000
> 400.435 398.228 -- 115.725 160.000
> 400.901 399.119 -- 114.726 162.000
> 395.092 398.112 -- 118.711 159.000
> 394.106 397.311 -- 118.710 159.000
> 400.866 397.903 -- 118.710 159.000
> 400.972 398.342 -- 115.710 160.000
> 397.218 398.201 -- 109.691 164.000
> {noformat}
>
>
> Additionally, the special-purpose RGB block of code included additional logic
> to support a case for non-RGB formats where image samples were organized 3
> one byte samples, but the photometric interpretation was not RGB. According
> to Coveralls, this block of code is not exercised by any of our test images.
> Thus that part of the code is uncovered by testing. So I will be removing it
> to improve the code-coverage scores. I believe that this change is
> appropriate because, even if there are TIFF files "in the wild" that use this
> configuration, the commons imaging library will still work properly. In such
> a case, the image samples would be handled properly by the original,
> non-specialized block of code. Furthermore, I went through the TIFF
> specification and did not see any obvious examples of a case where that
> configuration would be likely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
