| Summary: | In black color space of the "cups" output device color images are inversed or incorrectly rendered | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Till Kamppeter <till.kamppeter> |
| Component: | CUPS driver | Assignee: | Michael Vrhel <michael.vrhel> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | htl10, mike, till.kamppeter, twaugh |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
PostScript sample file
PDF sample file |
||
|
Description
Till Kamppeter
2010-11-09 12:00:47 UTC
Created attachment 6880 [details]
PDF sample file
The sample files are from bug 691733. Assigning to Michael Vrhel as this needs to get checked by a color management expert. So here is the issue. With these color spaces, in the current code it is going to be required for one to specify an appropriate destination ICC profile. If a device color space is not specified then a default type is going to be assumed based upon the number of channels. For example with RGBW, we are going to end up using a destination ICC profile, which is default_CMYK.icc. That obviously is not going to work. One could specify a 4CLR ICC profile that has the properties that are required and all would work fine. One possibility is for me to make the default case a bit more sophisticated and have it only use the gray, RGB and CMYK default profiles in cases where the device is as specified. Specialty xCLR destination profiles would need to be generated for these funny color models specified by CUPs. I need to spend a little time thinking about this as the profiles would need to be mapping from CIELAB to the process colorants. For cases like CMY YMC, inverted K the process of generating a profile that gave OK results would be easy. For KCMYcm RGBW the process is not as clear. Generally KCMYcm is really only seen in the printers embedded code where there is a transform from CMYK to CcMmYK. I have designed solutions for this in real printers but it is very printer specific. It would really fall on the user of this device to specify an ICC profile so that we know HOW to map to KCMYcm for that device. RGBW is used in projectors and I probably could come up with something, but it would not really be related to a real physical device and so I don't know how it would be of use to anyone. If someone had such a device they would determine the mapping for that device and specify it to ghostscript. *** Bug 691845 has been marked as a duplicate of this bug. *** I have identified the issue. When we process color, 16bit or interpolated images we usually take advantage of the CMM to do all our color management and have it operate on line buffers as a whole, which is much more efficient than the old way which involved multiple conversions to various data types. Unfortunately, if the device has non-standard color mapping procs then we can't do the CMM method, or it certainly loses its advantage. I am currently working on a solution that detects the presence of "special" color mapping procs, in which case we will go to the old style methods. This should be fixed with rev 12005. Please test Till. I have tested all color spaces with the command line of the initial posting and also the following command line (launch_leaflet.pdf from bug #688495) cat launch_leaflet.pdf | gs -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -dcupsColorSpace=17 -dcupsBitsPerColor=8 -sOutputICCProfile="default_cmyk.icc" -sstdout=%stderr -sOutputFile=%stdout -_ > out.raster and the output displayed with rasterview looks correct now. |