Summary: | Indterministic colors with comparefiles/vasarely.ps | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | leonardo <leonardo> |
Component: | General | Assignee: | Default assignee <ghostpdl-bugs> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P1 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows NT | ||
Customer: | Word Size: | --- | |
Attachments: |
rasters.zip
patch to the sample file |
Description
leonardo
2008-07-25 02:30:46 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. 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.
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 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. 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. Fixed a typoe in the bug title. 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. 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. I suggest to close the bug due to Alex's comment. 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. Closing with wontfix to save man*hours for important things. 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.
|