| Summary: | PDF 1.7 FTS: image incorrect | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
| Component: | Images | Assignee: | Michael Vrhel <michael.vrhel> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | CC: | alex |
| Priority: | P1 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | 532 | Word Size: | --- |
| Attachments: |
A temporary patch for 16 bit support (at least for CIELAB data)
an improved patch yet another improvement Final patch |
||
|
Description
Marcos H. Woehrmann
2010-07-22 06:40:30 UTC
An SMask issue is transparency, so assigning to Michael. SMask is unrelated to the bug and can be commented to simplify the test. The bug is caused by 2 problems in Jasper. 1. Jasper silently converts 16-bit data to 8-bit data but PostScript expects 16-bit ones. This is easy to work around. 3. Lab data returned by Jasper have unexpected format. I didn't figure out yet what it is. I any case, it is now what [/Lab ...] color space expects. s/it is now/it is not/ Made some progress on this one. The main image is 16bpp CIELAB jpx for which the interface to jasper has a problem in computing the stride. Jasper does decode the image correctly as 16 bits. Fixing the stride, it is clear that we have some issues with the head and 16 bit ICC support. Working on that right now. Should have something shortly. Also, I have a fix that properly handles the jpeg2000 enumerated color spaces. When I get all of this in place, I will post a patch for review as it involves changes in the pdf interpreter. I have a patch for this now. This will also include a fix to speed up our 16 bit image rendering within the icc branch. Will post patch tomorrow morning. Created attachment 6562 [details]
A temporary patch for 16 bit support (at least for CIELAB data)
An improved patch is coming shortly that also supports 16 bit RGB data.
*** Bug 691492 has been marked as a duplicate of this bug. *** Created attachment 6572 [details]
an improved patch
Created attachment 6573 [details]
yet another improvement
I had an impression that SMask image data source can be interleaved with the base image data source using several interleave methods. IN FACT, this is true only for transparent/opaque mask in PostScript Type 3 images. Our implementation needs a separate SMask stream. This stream can be extracted from the interleaved stream on the interpreter level at the cost of calling one PS procedure per pixel. Probably, we need a new JPXDecode parameter to select the channels from JPX image. As a stopgap measure, we can drop opacity channel completely. It would be easy to add in the ability in our Jasper interface to stream just the alpha channel or to stream everything but the alpha channel. If you can get things in place on the interpreter side, I can handle the Jasper end of things. Created attachment 6580 [details]
Final patch
This patch fixes the issues that we are seeing with the JPEG2000 images in the FTS files EXCEPT for the issues related to SmaskInData. Those images will be addressed by a different patch.
With this patch, support is also in place for faster 16 bit image rendering due to the improved ICC support, which lets us avoid the multiple conversions from 16 bit to frac to float to unsigned short to byte which occurred in the old flow. Also, the jasper interface will now, when it encounters a 16 bit or 12 bit image, use the higher bit depth renderer and pass the data along. Previously, we were truncating to 8bits in our jasper interface. This patch has been regression tested and checked with bmpcmp.
Fixed with commit of patch at rev 11571. Bug 691470 remains open for the handling of the SmaskInData issue. Changing customer bugs that have been resolved more than a year ago to closed. |