Bug 689979 - Indterministic colors with comparefiles/vasarely.ps
Summary: Indterministic colors with comparefiles/vasarely.ps
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: PC Windows NT
: P1 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-25 02:30 UTC by leonardo
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
rasters.zip (74.87 KB, application/octet-stream)
2008-07-25 03:00 UTC, leonardo
Details
patch to the sample file (675 bytes, patch)
2008-07-26 20:54 UTC, Alex Cherepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description leonardo 2008-07-25 02:30:46 UTC
Revision 8867 generates different colors depending on unknown reason with 
probability about 50%. Command line :

F:\AFPL\MLC2\compr-time-z1>..\..\gs-hd0\bin\gswin32c.exe -IF:/AFPL/gs-
hd0/lib;f:\afpl\fonts -r600 -dMaxBitmap=100000000 -dQUIET  -dNOPAUSE -
dNOOUTERSAVE  -sDEVICE=ppmraw -sOutputFile=z:\t1\\hdr.ppm -dLastPage=1 -c false
0 startjob pop /ttt usertime def -f - -c usertime ttt sub (oldtime=) print == 
quit  0<"H:\AuxFiles\CompareFile s\vasarely.ps" 1>>cur-1.log 2>>cur-2.log

MSVC8 *release* build at 600 dpi. Could not reproduce at 300 dpi or with debug 
build.
Comment 1 leonardo 2008-07-25 02:46:08 UTC
Reproduced with release build at 300, 72 and 6 dpi. Other command line 
arguments are same.

Few older revisions demonstrate same behavior, so it is not related to image 
interpolation and/or to recent change to clist.

Dear Support, please try to determine which revision contributes this effect. 
Note it is not necessarily reproducible with other p;latforms or compilers, 
and please note that the effect is stochastic.

For a while I nsetg P1 for Support to pay atgtention and to set a right 
priority.
Comment 2 leonardo 2008-07-25 03:00:11 UTC
Created attachment 4237 [details]
rasters.zip

Attaching rasters obtained with same command line in 2 consecutuve runs with 72
dpi. I have no idea what the colors depend on.
Comment 3 leonardo 2008-07-25 03:02:38 UTC
With -r72 the probability is some smaller than 50%. here are results of 
consecutive runs :

"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
z:\t1\/cur.ppm: page 1: 484704 different, 484704 out of tolerance, 484704 out 
of window
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
z:\t1\/cur.ppm: page 1: 484704 different, 484704 out of tolerance, 484704 out 
of window
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
z:\t1\/cur.ppm: page 1: 484704 different, 484704 out of tolerance, 484704 out 
of window
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
z:\t1\/cur.ppm: page 1: 484704 different, 484704 out of tolerance, 484704 out 
of window
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
"H:\AuxFiles\CompareFiles\vasarely.ps" 
z:\t1\/cur.ppm: page 1: 484704 different, 484704 out of tolerance, 484704 out 
of window
Comment 4 leonardo 2008-07-25 03:32:19 UTC
A minimal command line that demonstrates the effect is like this :

F:\AFPL\MLC2\compr-time-z1->..\..\gs-hd1\bin\gswin32c.exe -IF:/AFPL/gs-
hd1/lib;f:\afpl\fonts -r72 -dMaxBitmap=100000000 -dQUIET  -dNOPAUSE -
dNOOUTERSAVE  -sDEVICE=ppmraw -sOutputFile=z:\t1\\cur.ppm -dLastPage=1 -c false
0 startjob pop usertime pop -f - -c  quit 
0<"H:\AuxFiles\CompareFiles\vasarely.ps" 1>>cur-1.log 2>>cur-2.log

The effect dissapears when I remove 'usertime pop'. So now I think the 
priority is not so high, but I leave P1 for support to pay attention and to 
assign it properly. 

I viewed vasarely.ps and I see it uses usertime to initialize a random number 
generator. Well I'm unclear why its raster was deterministic before now and 
why do I observe the stochastic effect after calling 'usertime' at once.

BTW possibly I wwas wrong when saying that I can't reproduce it with debug 
build. It needs to check for sure.
Comment 5 Marcos H. Woehrmann 2008-07-25 07:27:17 UTC
The vasarely.ps file regression file changed on July 10th and I spent some time
trying to track down what revision was responsible in preparation for opening a
bug report.  What I found is the same thing you did, the output changed randomly
and why this happened was on my list of things to investigate further.  Another
thing I don't understand is why the file didn't show up in the regression report
more often, it hadn't between May 2006 and July 2008.  

Based on the analysis that output of the file is intentionally non-deterministic
I think we should remove it from the regression and close this bug.
Comment 6 leonardo 2008-07-25 11:17:15 UTC
Fixed a typoe in the bug title.
Comment 7 leonardo 2008-07-25 11:20:41 UTC
I remember I fixed real pattern bugs with vasarely.ps so I'm not sure that 
removing it is a right thing to go. Maybe restoring the old version is better, 
or fixing the indeterminizm in the test file (if it is really in the file 
rather in the interpreter). Note we've got a set of comparefiles/*fixed.* 
files.
Comment 8 Alex Cherepanov 2008-07-25 11:33:41 UTC
Ghostscript has strange implementation of usertime, which starts counting
the time from the 1st call in the given context. The first call always
returns 0. So an extra call to usertime makes the file, which depends
on usertine, indeterministic.
Comment 9 leonardo 2008-07-25 11:43:53 UTC
I suggest to close the bug due to Alex's comment.
Comment 10 Ralph Giles 2008-07-25 11:52:05 UTC
I agree Alex's explanation is sufficient to close the bug. I also think it's
reasonable to set a fixed seed in the comparefiles version so it is more consistent.

I do wonder if our usertime works the way it does to make files like this more
consistent. The usertime implementation dates from before the beginning of svn
history.
Comment 11 leonardo 2008-07-26 02:34:36 UTC
Closing with wontfix to save man*hours for important things.
Comment 12 Alex Cherepanov 2008-07-26 20:54:41 UTC
Created attachment 4242 [details]
patch to the sample file

Seed random number generator with 0 instead of usertime in
comparefiles/vasarely.ps to make the output consistent and suitable
for regression testing. 

No differences are expected, because the 1st call to usertime on Ghostscript
always returns 0. The patch is committed as a rev. 3119.