Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0.7
Description
1)
PDICCBased.java detects if the colorspace is sRGB, but does not use this advantage fully. toRGB() should return its argument when the colorspace is sRGB.
The files from PDF.js issues 8446 and 6737 are much faster now. The speed improvement can be experienced with files that use such pseudo ICC colorspaces for shading, because there a large number of colors have to be converted.
2)
PDDeviceRGB.java also converts colors to itself. awtColorSpace is the sRGB color space and so is /DeviceRGB, yet toRGB() calls awtColorSpace.toRGB() instead of just returning its argument.
This second change does not have much influence on the speed of rendering on my old computer (4 cores). But on the new computer (8 cores, 16 threads) the complete rendering tests are now done in 300 instead of 400 seconds.
Rendering regression tests show a lot of small differences. I assume that differences of 1/255 in a color somehow propagate and worsen, e.g. through transparency layers. I looked at a few, the differences are detected by the rendering tests but are invisible to my eye (in the diff file, the difference can be made visible by setting Gamma to minimum). I've therefore increased the tolerance to 3 units to avoid the work of analyzing hundreds of file differences. Those that remain are still invisible to my eye, except PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than Adobe before (the whole file is very broken and the first page logs over 3000 errors). I suspect it is an incorrect RGB value that isn't clipped anymore now.