OK.  This one has a funny decoding that is not being handled properly in the creation of the cache for converting from source to device colors.  Hopefully I will have a fix for this shortly.

Reassigning to Alex to dig into where and why the decode range is set to what it is for this file.  (and cc'ing Ken since this may fall into ps2write area and this file came from pcl to ps conversion)

The file was generated by GS.  It is odd because the source images do not seem to have a decode range but the postscript interpreter is sending zimage.c a dictionary that has a decode range from 0 to 256.  The image source data ranges contains 0 and 1 values for an indexed color space that is indexed into RGB color space.  The decode for the incoming data fails though since entry 0 is black and entry 1 is white.  When we have an input value of 1 then, because of the decode range we map this to 256 which is not at all correct.  What we want is to go to a value of 1 which will get us to the proper index position.  So, the question is where is the 256 value coming from?  Is it in the procset on the top of the source file?  Is that what we really want to have for this file?

(In reply to comment #3)
> Reassigning to Alex to dig into where and why the decode range is set to what
> it is for this file.  (and cc'ing Ken since this may fall into ps2write area
> and this file came from pcl to ps conversion)
> 
> The file was generated by GS.  It is odd because the source images do not seem
> to have a decode range but the postscript interpreter is sending zimage.c a
> dictionary that has a decode range from 0 to 256.  The image source data ranges
> contains 0 and 1 values for an indexed color space that is indexed into RGB
> color space.  The decode for the incoming data fails though since entry 0 is
> black and entry 1 is white.  When we have an input value of 1 then, because of
> the decode range we map this to 256 which is not at all correct.  What we want
> is to go to a value of 1 which will get us to the proper index position.  So,
> the question is where is the 256 value coming from?  Is it in the procset on
> the top of the source file?  Is that what we really want to have for this file?

This sounds like a problem I recently fixed in ps2write. The Decode array was using 0->2^n instead of 0->2^n-1. This didn't cause a problem *unless* the Indexed space was larger than the actual used colours, because if the index > the number of samples in the space, then it is silently clamped to the maximum.

So if a space had 2 colours and an image with a Decode of [0 2] instead of [0 1] then the '2' would be clamped to '1' by the indexed colour conversion. However if the space had 4 colours, then the 2 would not be clamped, and the actual colour might be indeterminate. In the case I fixed the sample array was initialised to 0, so (RGB space) always returned as black for indices off the end..

Given that the PostScript file has been generated incorrectly there is probably little hope of resurrecting it, but a new conversion using ps2write should (now) give a correct file. Do you have the original (before conversion via ps2write).

As for this file, I'm assuming that, in the absence of a Decode array, the interpreter is using the maximum of the colour space.

I confirm that the problem is fixed now, although I'd rather use
integer operations.

Index: opdfread.ps
--- opdfread.ps	(revision 12333)
+++ opdfread.ps	(working copy)
@@ -3842,7 +3842,7 @@
   /DeviceRGB { [0 1 0 1 0 1] } def

   /DeviceCMYK { [0 1 0 1 0 1 0 1] } def 

   /Indexed { 

-  dup /BitsPerComponent get 2 exch exp 1 sub [exch 0 exch] 

+  dup /BitsPerComponent get 1 exch bitshift 1 sub [exch 0 exch] 

   } def

   /Separation { [0 1] } def

   /CIEBasedA { [0 1]  /RangeA //GetColorSpaceRange exec } def

Regarding the generated file, it can be rescued by idiom recognition.
We can also patch the sample file by hand, just to justify the use
of Subversion to store sample files.

(In reply to comment #5)
> I confirm that the problem is fixed now, although I'd rather use
> integer operations.

revision 12366 makes this simple change in both opdfread.ps and opdfread.h.

I'm passing this one back to Marcos. We need to decide what to do about the original regression test file which was generated incorrectly from an old version of ps2write, we could:

1) Fix the test file. Gives correct result but does nothing for any other files of this nature (I believe such files to be *extremely* rare).

2) Write an idiom which spots the problem declaration and fixes it. This would
fix the regression test, and also any other files with the same problem but 
potentially costs performance.

3) Ignore the fact that the output has changed and carry on. The file created
by ps2write was incorrect, so maybe we should just accept this.

My own inclination is to do '1' and close the issue.

I agree with Ken that the correct course of action(In reply to comment #6)
> (In reply to comment #5)
> 
> 1) Fix the test file. Gives correct result but does nothing for any other files
> of this nature (I believe such files to be *extremely* rare).
> 

I agree that fixing the file makes sense.  Reassigning to Ken to do that.

Created attachment 7651 [details]
Modified sample file

The attached file has been modified as per the change to opdfread.ps noted above. However I'm unable to see a difference in the output. Maybe I'm missing something...

Marcos could you check this please ?

Re-assigning to Marcos to test file.

Fixed.  I'll update the test file with this new one.