| Summary: | Unwanted dots in halftone screen (on high resolution?) | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Martin Schulze <martin.schulze> |
| Component: | Color | Assignee: | Ray Johnston <ray.johnston> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | diuming_wen |
| Priority: | P4 | ||
| Version: | 9.50 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
Magenta channel with 600DPI at ditherPPI=20
Fixed magenta channel |
||
*** Bug 701814 has been marked as a duplicate of this bug. *** This bug is particular to the tiffsep1 device which uses its own function to create threshold arrays from the ht_order. Changing tiffsep1 to use the gsht.c function gx_ht_construct_threshold that Michael developed fixes this problem. Taking this bug, and will commit the fix shortly. Fixed in commit bf689ee0bff720f202ebc98f301c765f34e2c1fa For patterns with > 256 dots, threshold_from_order would put in 0 value cells which would then always be imaged. Change this device to (finally) use the gx_ht_construct_threshold used by the fast_ht thresholding code so that it should match the other devices, such as pbmraw. Also vertically invert the use of the threshold array to match the dots of the other devices. The commit also adds missing dependencies for gdevtsep.c in devs.mak Thanks for your fine work. I tried current master and the artifacts are gone. However, I noticed that the output from my test above now looks different: The angles seem to work in the opposite direction now as you can see the attached new magenta image. The orientation seems to be from lower left to upper right now, instead of upper left to lower right as in the old image. Created attachment 18749 [details]
Fixed magenta channel
I was able to see the angle change -- it was due to an invalid attempt to get the halftone phase to match the output from other halftone methods (such as that used by pbmraw). The phase and angle can be made to match by the latest patch: commit d1aa5fdfdbea4c55445ee1bdbe08b822a1bd7a8c As noted in the comment for that patch, the pattern is slightly darker, but that might be a result of the gx_ht_construct_threshold. It looks good now. Thanks again for your work on this. |
Created attachment 18498 [details] Magenta channel with 600DPI at ditherPPI=20 When using custom angles and frequencies for RIP I noticed unwanted dots in white (zero tone value; blue circle in the attachment) areas and within the "glades"* in non-white (non zero tone value; red circle in the attachment) areas. At first I thought this only happens with custom screensets and high resolution but now I found a reproducer that exhibits (part of) this earlier: ``` << /PageSize [20 10] >> setpagedevice % draw two filled rects that contrast different tone values per CMYK channel 0.75 0.5 0 0 setcmykcolor newpath 0 0 moveto 10 0 lineto 10 10 lineto 0 10 lineto closepath fill 0.5 0 0.75 0.5 setcmykcolor newpath 10 0 moveto 20 0 lineto 20 10 lineto 10 10 lineto closepath fill showpage quit ``` Running this with `gs -r600 -dDITHERPPI=20 -sOutputFile=test%d.tif -sDEVICE=tiffsep1 -f test.gs` gives black dots in "white" areas (where the channel has value 0) and I get black dots in the middle of the white "glades" of the screen in non zero channels. Both is unintended. With -r300 the zeros stay clean but the unwanted dots in the nonzero channels are still there. When looking closely you can see, that the dots in zero channels are located in the same grid as the wanted dots in the non zero channels, so I am not sure if they stem from the same problem. I lowered the ditherDPI to better separate the unwanted dots from the rest. With default ditherPPI the unwanted dots in the zeros are gone but the other unwanted dots remain. * I lack knowledge of the exact terminology for this. What I mean is the white area that is encroached by increasing amounts of black when the tone value increases until it vanishes.