Bug 692339 - Wrong screening for 40 lpi
Summary: Wrong screening for 40 lpi
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: 9.02
Hardware: PC Windows XP
: P2 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-11 15:26 UTC by Leonid Lukomskij
Modified: 2011-11-25 04:12 UTC (History)
1 user (show)

See Also:
Customer: 582
Word Size: ---

Attachments
Source file for tests (477.22 KB, application/pdf)
2011-07-11 15:26 UTC, Leonid Lukomskij 		Details
initialization file for 40 lpi (945 bytes, text/plain)
2011-07-11 15:28 UTC, Leonid Lukomskij 		Details
initialization file for 39 lpi (945 bytes, text/plain)
2011-07-11 15:28 UTC, Leonid Lukomskij 		Details
initialization file for 41 lpi (945 bytes, text/plain)
2011-07-11 15:29 UTC, Leonid Lukomskij 		Details
Simplified sample file (709 bytes, application/postscript)
2011-07-16 19:00 UTC, Alex Cherepanov 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Leonid Lukomskij 2011-07-11 15:26:49 UTC 
Created attachment 7663 [details]
Source file for tests

I have problems with tiffsep1 device if I set screening frequency to 40 lpi. 39 and 41 lpi are ok.

I use follow command line:

gswin32c -dBATCH -dSAFER -dNOPAUSE -sDEVICE=tiffsep1 -r1200x600 -sOutputFile=ltt-40.tif kst-40.ps LucidTrapTest.pdf

All output separations except Yellow have wrong screening.

I tried resolution 1200 dpi instead of 1200x600. In this case Cyan and Magenta separations are wrong. Other separations seems to be ok.

Note. kst-40.ps is my initialization file. I attach it (and files for 39 and 40 lpi too)
Comment 1 Leonid Lukomskij 2011-07-11 15:28:18 UTC 
Created attachment 7664 [details]
initialization file for 40 lpi
Comment 2 Leonid Lukomskij 2011-07-11 15:28:47 UTC 
Created attachment 7665 [details]
initialization file for 39 lpi
Comment 3 Leonid Lukomskij 2011-07-11 15:29:13 UTC 
Created attachment 7666 [details]
initialization file for 41 lpi
Comment 4 Henry Stiles 2011-07-16 02:17:12 UTC 
Assigned to Alex for preliminary analysis and regression check.
Comment 5 Alex Cherepanov 2011-07-16 19:00:31 UTC 
Created attachment 7677 [details]
Simplified sample file

This is not a regression. The bug can be found in all versions starting from 8.71, which has introduced tiffsep1 device.

The problem can be reproduced running the attached file as
  ~/ghostpdl/gs/debugbin/gs -dBATCH -dSAFER -dNOPAUSE \
  -sDEVICE=tiffsep1 -r1200x600 -sOutputFile=ltt-40.tif a.ps 

Valgrind finds nothing unusual, -dNOGC doesn't help, /AccurateScreens false changes the appearance but doesn't fix everything.
Comment 6 Leonid Lukomskij 2011-08-18 19:42:40 UTC 
I tried latest version (9,04). Nothing changed, still wrong screening
Comment 7 Michael Vrhel 2011-09-21 18:32:55 UTC 
Verified that we have an issue here.  Looking into the generation of the threshold from the order array as the possible issue (threshold_from_order in gdevtsep.c).  Since pkmraw comes out ok and is using the order array to generate its tiles it would seem that the order array was generated correctly leaving an issue with the threshold array or the tiling of it.
Comment 8 Michael Vrhel 2011-09-21 19:34:29 UTC 
Threshold generation is fine.  The order array information coming in is incorrect.  Digging into that now.
Comment 9 Michael Vrhel 2011-09-22 05:37:35 UTC 
OK so I have figured out what the issue is.  Hopefully this will not take too long to fix.  Essentially, the order array at 40lpi ends up in a strip form, which means it is represented as a line and a shift parameter which would be used to offset the strip as as function of Y during tiling.  The current threshold array creation code in threshold_from_order in gdevtsep.c can not currently create a proper threshold array from this form.  It assumes the order is in a "complete" shift free form, so it ends up creating an array that is 1-D horizontal strip.  This problem also likely would occur with the fast thresholding code, which relied upon threshold_from_order in gdevtsep.c in its creation.  I will fix the code to create the proper threshold and also make it so that the code in gdevtsep.c shares the threshold creation function that is used for the fast image thresholding.
Comment 10 Michael Vrhel 2011-09-24 06:26:55 UTC 
Testing fix for this now.