Bug 693163 - gs has problems with DeviceN images
Summary: gs has problems with DeviceN images
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: 9.05
Hardware: PC Windows XP
: P4 normal
Assignee: Alex Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-01 08:52 UTC by Thomas Freitag
Modified: 2012-07-12 03:55 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
image with (Black) (PANTONE 265 C) (None) (None) (None) (447.35 KB, application/postscript)
2012-07-01 08:52 UTC, Thomas Freitag
Details
image with (Black) (GWG Green) (None) (None) (None) (403.35 KB, application/postscript)
2012-07-01 08:54 UTC, Thomas Freitag
Details
image with (Cyan) (Black) (329.00 KB, application/postscript)
2012-07-01 08:56 UTC, Thomas Freitag
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Freitag 2012-07-01 08:52:34 UTC
Created attachment 8721 [details]
image with (Black) (PANTONE 265 C) (None) (None) (None)

If an image is set in a DeviceN colorspace, gs seems to have problems when the DeviceN contains colors other than process colors. If I use acrobat X to create a pdf from it, the output is as I would expect it.
Comment 1 Thomas Freitag 2012-07-01 08:54:31 UTC
Created attachment 8722 [details]
image with (Black) (GWG Green) (None) (None) (None)

another testcase
Comment 2 Thomas Freitag 2012-07-01 08:56:34 UTC
Created attachment 8723 [details]
image with (Cyan) (Black)

Image with DeviceN and only process colors, this looks fine
Comment 3 Alex Cherepanov 2012-07-02 04:13:51 UTC
The tint transform function in the /DeviceN color space used in the
1st 2 files is clearly incorrect. 

[/DeviceN
 [(Black) (PANTONE 265 C) (None) (None) (None)]

  [/CIEBasedABC 
      << /RangeABC [0 1 0 1 0 1]

         /DecodeABC [{100 mul 16 add 116 div} bind 
                     {0.51 mul  -0.256 add } bind 
                     {1.275 mul -0.64 add  } bind]

        ...  
      >>
  ]
  { 5 3 roll pop pop 
%   3 -1 roll 100.000000 mul 0.000000 add 
%   3 -1 roll 255.000000 mul -128.000000 add 
%   3 -1 roll 255.000000 mul -128.000000 add 
 }
]

After commenting out spurious scaling, the DeviceN image renders correctly.
I don't know why Acrobat Distiller is not sensitive to this bug.

There's something strange with the gradient too, but Ghostscript matches
Distiller in this respect. So I didn't look into this problem further.
Comment 4 Thomas Freitag 2012-07-05 08:23:41 UTC
(In reply to comment #3)
Thanks for Your hint, Alex. It wasn't such easy, because the tint transform function wasn't generated but read from the PDF source, but now I was able to solve it in concatenating an invert function. I also changed RangeABC and DecodeABC, so the actual postscript code is now:

[/DeviceN
 [(Black) (PANTONE 265 C) (None) (None) (None)]

  [/CIEBasedABC 
      << /RangeABC [0 100 -128 127 -128 127]

         /DecodeABC [{16 add 116 div} bind {500 div} bind {200 div} bind]

        ...  
      >>
  ]
  { 5 3 roll pop pop 
   3 -1 roll 100.000000 mul 0.000000 add 
   3 -1 roll 255.000000 mul -128.000000 add 
   3 -1 roll 255.000000 mul -128.000000 add 
   3 -1 roll 100 div 
   3 -1 roll 128 add 255 div 
   3 -1 roll 128 add 255 div
 }
]

Okay, it looks confusing, but I find no other way! And Ghostscript now matches the Distiller output.
Comment 5 Chris Liddell (chrisl) 2012-07-05 09:00:01 UTC
Thomas, did you check the tint transform in the PDF? To establish for sure that this isn't a problem with poppler's emitting of the tint transform?
Comment 6 Thomas Freitag 2012-07-05 09:15:04 UTC
(In reply to comment #5)
> Thomas, did you check the tint transform in the PDF? To establish for sure that
> this isn't a problem with poppler's emitting of the tint transform?

Yes, I checked it in the debugger, that was the first I'd done. You can proof it, the attached EPS were produced by the freely available patches from the Ghent PDF workgroup, 08_DeviceN patches:

128 0 obj[/Indexed 129 0 R 255 136 0 R]
endobj
129 0 obj[/DeviceN[/Black/PANTONE#20265#20C/None/None/None]130 0 R 132 0 R 133 0 R]
endobj
130 0 obj[/Lab<</BlackPoint[0.0 0.0 0.0]/WhitePoint[0.9642 1.0 0.82491]/Range[-128.0 127.0 -128.0 127.0]>>]
endobj
131 0 obj 65
endobj
132 0 obj<</Length 131 0 R/FunctionType 4/Filter/FlateDecode/Domain[0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]/Range[0.0 100.0 -128.0 127.0 -128.0 127.0]>>stream
:: decoded:
{ 5 3 roll pop pop 
   3 -1 roll 100.000000 mul 0.000000 add 
   3 -1 roll 255.000000 mul -128.000000 add 
   3 -1 roll 255.000000 mul -128.000000 add 
 }
endstream
endobj
133 0 obj<</Colorants 134 0 R>>
endobj
134 0 obj<</PANTONE#20265#20C 116 0 R>>
endobj
136 0 obj<</Length 1183/Filter/FlateDecode>>stream
<< lookup table >>
endstream
endobj
Comment 7 Alex Cherepanov 2012-07-12 03:55:40 UTC
The fragment of the PDF file looks reasonable but the generated EPS isn't.
In any case this is not a Ghostscript bug.