Bug 702581 - Halftones get normalized
Summary: Halftones get normalized
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-21 18:25 UTC by Alex Cherepanov
Modified: 2023-05-23 16:55 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
sample file (1.06 KB, application/postscript)
2020-07-21 18:25 UTC, Alex Cherepanov
Details
Generated file (convert'ed to PNG to save space) (36.84 KB, image/png)
2020-07-21 18:29 UTC, Alex Cherepanov
Details
Expected (32.28 KB, image/png)
2020-07-21 18:29 UTC, Alex Cherepanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Cherepanov 2020-07-21 18:25:12 UTC
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
Comment 1 Alex Cherepanov 2020-07-21 18:29:00 UTC
Created attachment 19484 [details]
Generated file (convert'ed to PNG to save space)
Comment 2 Alex Cherepanov 2020-07-21 18:29:55 UTC
Created attachment 19485 [details]
Expected
Comment 3 Ray Johnston 2020-08-31 23:37:15 UTC
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.
Comment 4 Alex Cherepanov 2020-09-01 01:52:19 UTC
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.