Summary: | DeviceGray to DeviceCMYK / DeviceRGB conversion produces unexpected result | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | i3v |
Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | 9.26 | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | Word Size: | --- | |
Attachments: | Example pdf with DeviceGray objects |
Description
i3v
2019-03-20 19:15:58 UTC
Just for reference: * This was also discussed here: https://ghostscript.com/irclogs/2019/03/10.html ... https://ghostscript.com/irclogs/2019/03/15.html * This was mentioned few years ago here: https://stackoverflow.com/questions/38310916/pdf-batch-conversion-from-srgb-to-cmyk#comment64167806_38314025 . (In reply to i3v from comment #0) > The `ColorConversionStrategy`-related conversions silently skip DeviceGRAY > colors (e.g. for text). That's expected behaviour, as I already indicated. Since DeviceGray can be mapped directly to the K channnel of CMYK, there is no need to colour convert it. > The following phrase in the documentation (related to `-sSourceObjectICC`) > https://www.ghostscript.com/doc/9.26/GS9_Color_Management.pdf > sounds like GRAY should work just like RGB or CMYK: > "In addition to CMYK and RGB types given above, the user can also specify > Graphic GRAY, Image GRAY and Text GRAY objects". That document does not apply, more or less at all, to the pdfwrite device. In general the pdfwrite device goes to extreme lengths to maintain colour dpecifications from the input unchanged in the output. When ColorConversionStrategy is specified the colour management engine is used, and also when objects have to be rendered (for example when outputting to earlier versions of PDF. > The suggestion: > It would be nice, if the the mentioned phrase "... the user can also specify > Graphic GRAY, Image GRAY and Text GRAY objects." would be accompanied with > e.g. "However, DeviceGRAY is treated as a special case, and is not actually > converted to CMYK/RGB - it remains DeviceGRAY unless "Use Device Independent > Color" is used (in which case it becomes ICCBasedGray)". No, because that document refers to the rendering devices, not to the pdfwrite device. The behaviour for rendering devices is as described. (In reply to Ken Sharp from comment #2) > (In reply to i3v from comment #0) > > That document does not apply, more or less at all, to the pdfwrite device. > ... > No, because that document refers to the rendering devices, not to the > pdfwrite device. The behaviour for rendering devices is as described. Hmm.., My initial impression was the opposite - everything I've tried, except "Text_GRAY" (and other "*_GRAY") do work fine for `-sDEVICE=pdfwrite`. I won't say I've tried everything described in that doc, but those fancy example color conversions for the "text_graphic_image.pdf" do work. Also, I've never seen explicit "this document does not apply to `-sDEVICE=pdfwrite`" there. Even though it might be the case that Color Management is rarely used with pdfwrite, it would be nice if the behavior would be documented. AFAIU, there's no special "Color Management for `-sDEVICE=pdfwrite`" doc. ----------------------------------------------------------------------- For `-sDEVICE=tiff32nc`, I do see that DeviceGRAY color conversion results depends on the "Text_GRAY" line, e.g. adding > Text_GRAY default_gray.icc 0 1 0 to "objsrc_profiles_example.txt" and running > gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sColorConversionStrategy=CMYK -sSourceObjectICC=objsrc_profiles_example_v2.txt -sOutputFile=%1_v2.tiff %1.pdf makes black text cmyk(0.7255, 0.6784, 0.6706, 0.8902) while the original "objsrc_profiles_example.txt" http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=toolbin/color/src_color/objsrc_profiles_example.txt;hb=eec855c9baeaa73c0208ed439fbbf1a0d48a447e or plain > gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sColorConversionStrategy=DeviceCMYK -sOutputFile=%1_v8.tiff %1.pdf makes black text cmyk(0, 0, 0, 1). Thus, indeed, `Text_GRAY` do work somehow for `-sDEVICE=tiff32nc`. ----------------------------------------------------------------------- So, my original suggestion is incorrect in the sense, that it is missing "for `-sDEVICE=pdfwrite`". The more appropriate version would be: "However, for `-sDEVICE=pdfwrite`, DeviceGRAY is treated as a special case, and is not actually converted to CMYK/RGB. ..." |