When the attached file is ripped with gs8.71, head (r10824), or earlier versions the gray gradient on the right and side of the image is rendered with visible steps. When the file is converted using the tiff32nc device the gradient is rendered correctly (compared to Acrobat 9.3.1). There are other differences in the file as well, including a semi-transparent blue rectangle near the top of the image and the text near the top rendered in gray instead of white. The command line I'm using for testing: bin/gs -sDEVICE=tiffsep -o test.tif ./38781-359-ART.pdf
Created attachment 5998 [details] 38781-359-ART.pdf.gz
Created attachment 5999 [details] tiffsep.tif Tiff file generated by head (r10824) using -sDEVICE=tiffsep
Created attachment 6000 [details] tiff32nc.tif Tiff file generated by head (r10824) using -sDEVICE=tiff32nc
Created attachment 6001 [details] acrobat.tif Tiff file generated by Acrobat 9.3.1
The tiffsep device issues are either mine or Michael's. Since Michael is in Japan, I will look at this and decide who needs to address this.
Created attachment 6018 [details] gradient_test_rgb.pdf A second customer has reported the same gradient issue with tiffsep. The attached file is a simpler test case. Note that there is a separate issue with this file when converted with the tiff24nc device. The gradient steps are smoother but the center of the image is not correct. I'll attach a screen shot showing the problem.
Created attachment 6019 [details] screenshot.png Comparison of Adobe Acrobat 9.3.1, Apple Preview 5.0.1, and Ghostscript head (r10826). Ghostscript output was written using the command line: bin/gs -sDEVICE=tiff24nc -r1000 -o test.tif gradient_test_rgb.pdf
This appears to be a regression. Both the tiffsep and tiff24nc issue noted with gradient_test_rgb.pdf do not appear in r7935. The log message for r7936: r7936 | leonardo | 2007-05-09 08:45:54 -0700 (Wed, 09 May 2007) | 51 lines Fix (shadings) : The decomposition limit must depend on resolution. DETAILS : This partially improves performance for the test case of the bug 689189 "PDF fails with /unregistered in --shfill--". The old code limits the decomposition of a shading with 1 pixel. It gives a good precision for low resolution devices, such as display with 72dpi. However for high resolution devices the decomposition limit may be bigger, because tinny parts are not visible. Now we make it be dependent on the device resolution. It speeds up the high resolution rendering with quickly varying colors. The worker formula is : decomposition_limit = float2fixed(HWResolution / 72) With 300 dpi the file "self-intersect2.ps" renders a few worse near the self-intersection. It may be visible when viewing the ppmraw output with a monitor. We think it's a reasonable tradeof for the performance. Actually the monitor performs a significant zoom when viewing "actual pixels", because the monitor's resolution is much smaller. The quality degradation shouldn't be visible with a 300 dpi printer.
There are 2 components to this bug. 1) That tiffsep and tiff24nc give different results 2) That tiff24nc gives the wrong result. 1) is explained by the fact that tiffsep has "non separable and linear colors", and tiff24nc has "separable and linear colours". This means that the shadings end up decomposed into linearly filled traps in one, and constant color traps in the other. This wouldn't matter if the targets of the decomposition were small enough (1 pixel in size), but they aren't beecause of... 2) The commit that marcos points to (rev 7936, git hash 81fb15c), changes the shading code to only decompose to 1 pixel, or one point, whichever is larger. His claim was that we'd never notice differences in shadings smaller than this. I don't believe that's true, especially as people frequently abuse the resolution field to get images large enough to support zooming. I am tempted to revert the change - but need to test the timing differences it makes. Ken suggested a setting (perhaps -dSHADINGQUALITY=) along the lines of jpeg quality.
Timings: existing code vs accurate code (code with revision 7936 backed out). 1000dpi gradient_test_rgb: 0.485 vs 0.422 (new code is faster!) 1000dpi Anniversaire.pdf: 22.563 vs 28.766 (new code is slower) 300dpi Anniversaire.pdf: 10.7 vs 13.2 (new code is slower) That's a 27% performance loss in the worst measured case. If anyone feels that's too much, speak up, and we can examine other options.
For users that don't need more than 8 total components (CMYK + 4 spot colors), the tiffsep device can be built to use "ordinary" (not compressed) color encoding. Then the gx_color_index remains separable and linear. One thing we may want to consider is to make the use of compressed color encoding dynamically configurable (parameter) _or_ clone the device and have one that uses compressed encoding, but that can support up to GS_CLIENT_COLOR_MAX_COMPONENTS and one that only supports up to 8 components.
Fixed: commit 585cac9d3aa6bca9e877c3e12ef3e28fd4f7f571 Author: Robin Watts <Robin.Watts@artifex.com> Date: Thu Jun 2 12:38:40 2011 +0100 Fix bug 691152; gradients appear 'stepped'. The original bug report was that tiffsep and tiff24nc give noticably different results. This turns out to be because tiffsep is set to use non 'linear-and-separable' colours. When shadings are rendered, they are 'decomposed' down into smaller and smaller regions, until they are smaller than a given threshold. These regions are then filled either with linear filled traps (in the linear and separable case) or with constant colour (in the non linear and separable case). This means that we can get away with a larger threshold in the linear and separable case (tiff24nc) and still see smooth results. The original version of the code (pre SVN rev 7936) used to decompose until the regions were smaller than a pixel. At rev 7936 this was upped to be 1 point (1/72 of an inch) (or 1 pixel, whatever was larger). Reverting to this original code solves the problem by making the constant color regions small enough so that they still look smooth. There would therefore appear to be several possible approaches to solve the problem: 1) We could back out the change in 7936. This trades time (27% in the worst measured test case) for correctness. 2) We could change tiffsep to use linear and separable colours. I've opted for an approach based on 1) here, because a bmpcmp clearly shows easily visible differences in some files in other devices, for example: tests_private/comparefiles/470-01.ps.pgmraw.300.0 By default, the code now operates as pre revision 7936. Should the change in speed be considered unacceptable, gs can be build with the symbol MAX_SHADING_RESOLUTION defined to maximum dpi to which shadings should be decomposed; building with -DMAX_SHADING_RESOLUTION=72 will give the same results as the existing code.
Created attachment 7873 [details] RGB vector graphic with Cyan coloured gradient I can confirm that the reversion to pre-7936 behaviour has fixed the gradient issue for the file gradient_test_rgb.pdf. However, I have been testing Ghostscript 9.04 against some other gradient images and unfortunately I am still seeing a difference between tiffsep and tiff32nc (tiffsep producing stepped gradients where tiff32nc is smooth). To reproduce, use the following command lines: ghostscript-9.04/bin/gs -sDEVICE=tiff32nc -r300 -o img_tiff32nc.tif cyan_gradient_rgb.pdf ghostscript-9.04/bin/gs -sDEVICE=tiffsep -r300 -o img_tiffsep.tif cyan_gradient_rgb.pdf The stepped gradient is visible in img_tiffsep.Cyan.tif whereas the Cyan channel of img_tiffsep.tif is smooth. I have also tested this exact same scenario on Ghostscript 8.56 which I believe was built before the 7936 commit. The behaviour is identical in that version so I suspect this issue isn't purely due to that regression. Can anyone confirm they are seeing the same behaviour? Any ideas on workarounds would be much appreciated. I would just use tiff32nc but in other images there are spot colours which must be preserved. Kind regards, Paul