Bug 694850

Summary:	Threshold tables are not generated entirely evenly.
Product:	Ghostscript	Reporter:	Robin Watts <robin.watts>
Component:	Images	Assignee:	Michael Vrhel <michael.vrhel>
Status:	RESOLVED WONTFIX
Severity:	enhancement	CC:	sphinx.pinastri
Priority:	P4
Version:	master
Hardware:	All
OS:	All
Customer:		Word Size:	---
Attachments:	Test case

Description Robin Watts 2013-12-17 06:59:30 UTC

This is a spin off from bug 694842.

In order to do halftoning we build threshold tables. These are then used to map contone values to dithered values, such that if contone(x,y) < threshold(x,y), we set the pixel at (x,y).

For an n pixel area, there are n+1 possible levels (ranging from 0 to n pixels set). As such we'd expect the threshold table to map roughly equal divisions of the source contone range into each level of dither.

The existing code fails to do this. For a source range of 0..255 it divides the range into n 256/n sized blocks (for the middle cases) and two 512/n sized blocks (for the 0 and n cases). We should fix this.

Also, we should check the behaviour of the code in the case where we are dithering with more than simple black and white.

Comment 1 Robin Watts 2013-12-17 07:00:55 UTC

Assigning to Michael, as requested.

Comment 2 Peter Cherepanov 2021-01-03 00:20:02 UTC

Created attachment 20415 [details]
Test case

I don't know how to observe any effects of this in rendering. When the test case is rendered as:
 ~/ghostpdl/debugbin/gs -r1000 -o a.tiff -sDEVICE=tiffg4 a.ps

it produced a few steps of a tint ramp. These steps occur due to internal rounding to 8 bit. The width of every step is about the same. IMHO Ghostscript works fine.