| Summary: | Halftones get normalized | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Alex Cherepanov <alex> |
| Component: | General | Assignee: | Michael Vrhel <michael.vrhel> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
sample file
Generated file (convert'ed to PNG to save space) Expected |
||
Created attachment 19484 [details]
Generated file (convert'ed to PNG to save space)
Created attachment 19485 [details]
Expected
Alex, can you please explain "normalizes". The PLRM doesn't use this term with respect to halftones. Is it that a transfer function is being applied? The example seems to have several cases, and it seems to me that the Type 6, 10 and 16 would be preferred and the Type 3 output is the problem (in that it provides they provide a linear "ramp" but the Type 3 does not). Where does the "Expected" output come from? Adobe Acrobat Distiller seems to TOTALLY ignore the halftone from the PS and just generate 4 gray ramps. Lastly, does this matter in some way? I can see that someone would object to the GS gray ramp for Type 3, but the others seem "better" and match what comes out from a device with gray shade capability (8 bit per component). The "Expected" output is really far from the gray shade output. I use Ghostscript as a development environment for PostScript programs that run on a brand name PostScript interpreter. If Ghostscript deviates from the spec, even to the better side, it it becomes less useful for testing. When a vendor supplied a presumably correct halftone and this halftone appeared to produce reasonable results on Ghostscript, it was very tempting to look for a bug elsewhere. In fact, Ghostscript quietly repaired broken 16-bit halftones. PLRM expects the values of the threshold array to span the whole range from 0 to 2**16-1 . Ghostscript has a complicated scheme to reduce the number of gray levels and save memory. In particular, when the highest value of the threshold array is less than 2**16-1, it is effectively stretched to the full range. Initially, I thought that threshold arrays are handled like the values obtained from a spot function, or "normalized". The sample file has halftones that covers about a half of the range 0..2**16-1. As a result, a half of 0..1 ramp must be rendered white. So does a brand name interpreter. Ghostscript scales the range and renders the whole ramp. The 8-bit threshold array halftone in Ghostscript does not have this bug and renders a half of the ramp, as it was designed. |
Created attachment 19483 [details] sample file Contrary to the PLRM, Ghostscript normalizes the content of some threshold arrays similarly to normalization of spot function values. To reproduce: gs -DEVICE=tiffg4 -r600 -o 953.tiff hty.ps