Created attachment 122084 [details] part of the image is not correctly rendered Summary: The top part of the Figure 2 in 113509.pdf is not rendered correctly. This is visible with pdftocairo, pdftoppm, Evince and Okular. The file is correctly displayed by acroread. Steps to reproduce: 1) pdftoppm 345512.pdf test 2) eog test-1.ppm 3) acroread 113509.pdf 4) Compare the image to acroread rendering. Actual Results: The top of Figure 2 in 113509.pdf is not rendered correctly. Expected Results: The image should be displayed correctly, just like with acroread.
Created attachment 122110 [details] [review] implement jpx streams with depth < 8 This patch fixes it
Pushed.
*** Bug 71159 has been marked as a duplicate of this bug. ***
Thomas I did read the regression run incorrectly and the patch does actually introduce a regression, this pdf that was previously rendered correctly is now a black box. Can you have a look?
Created attachment 122136 [details] pdf that regresses
(In reply to Albert Astals Cid from comment #4) > Thomas I did read the regression run incorrectly and the patch does actually > introduce a regression, this pdf that was previously rendered correctly is > now a black box. > > Can you have a look? Who ever had this idea to scale image data just in case of jpx streams to 8 bit values but then treat index values in the reading function? This prevents a clean solution, in my eyes every solution looks like a dirty hack... And because getImageParams() is called so early which already reads the jpx data and scales it I even have not yet the Gfx colorspace which is parsed later.
Created attachment 122138 [details] [review] Don't scale image comps to 8 bits in case of an indexed colorspace This does the (dirty) trick
Good :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.