I think we've hit the point where we need to revisit our rendering and such to include more than just RGB.
This bug is one example: "Export to TIFF to support CMYKA color" https://bugs.launchpad.net/inkscape/+bug/492402
It looks like to be able to solve this case, we would need to be able to have our engine render to four-channel CMYK in order to preserve data. Simply rendering to RGB and then converting to CMYK using LittleCMS won't work, since black ink separation will be lost, etc.
Am I seeing this wrong?
Also, could we perhaps get away with export by rendering n channels, each being grayscale?
Thanks.
On Sat, Dec 19, 2009 at 2:55 PM, Jon Cruz <jon@...18...> wrote:
I think we've hit the point where we need to revisit our rendering and such to include more than just RGB.
This bug is one example: "Export to TIFF to support CMYKA color" https://bugs.launchpad.net/inkscape/+bug/492402
It looks like to be able to solve this case, we would need to be able to have our engine render to four-channel CMYK in order to preserve data. Simply rendering to RGB and then converting to CMYK using LittleCMS won't work, since black ink separation will be lost, etc.
Illustrator (these days) handles this in a sane way IMO. There is a switch for the Document Color Mode - RGB or CMYK. When selecting/creating a color in RGB mode, RGB sliders are presented and vice versa in CMYK mode (actually, you can use any sliders in any mode - it just gets converted on the fly to match the doc's color mode - but not really on-topic). What makes this sane to me is that you never end up with a mix of RGB and CMYK in the same document - which can be a nightmare when getting ready for final output.
So yes - I think it would be nice to store/render CMYK values inside Inkscape. Conversion via lcms would be nice to convert a color from RGB to CMYK *inside* Inkscape, but if I specify a color as c0m100y100k0 and save a TIFF, I would expect everything filled with that color to be 100% black on the MY channels, and 100% white on the CK channels. Trying to get the same result from RGB (with lcms) would be a crap-shoot at best. Another use case: rich black. Some print companies recommend/specify a black that is a particular formula: eg 60%C 40%M 40%Y 100%K.
Also, could we perhaps get away with export by rendering n channels, each being grayscale?
I think so. I know that's how to handle spot channels - and I think CMYK channels are similar - but it's been a while since I looked at the TIFF spec.
My 0.02 from a pre-press/dtp perspective.
Chris
On Dec 19, 2009, at 2:42 PM, Chris Mohler wrote:
Illustrator (these days) handles this in a sane way IMO. There is a switch for the Document Color Mode - RGB or CMYK. When selecting/creating a color in RGB mode, RGB sliders are presented and vice versa in CMYK mode (actually, you can use any sliders in any mode
- it just gets converted on the fly to match the doc's color mode -
but not really on-topic). What makes this sane to me is that you never end up with a mix of RGB and CMYK in the same document - which can be a nightmare when getting ready for final output.
Actually... the insane part of that behavior is that CMYK=>RGB is a *lossy* conversion, and automatically doing it means that artists have their reason for using CMYK in the first place squashed/deleted.
To further complicate things, Adobe recommends keeping parts in RGB as long as possible, and only converting to CMYK as you actually place/print things through their publishing app, InDesign. (Unless you are working directly in the CMYK for the specific print job, it's better to keep the source piece of art in RGB so it can be converted for flyers, t-shirts, etc. with top fidelity).
:-)
On Sat, Dec 19, 2009 at 4:56 PM, Jon Cruz <jon@...18...> wrote:
On Dec 19, 2009, at 2:42 PM, Chris Mohler wrote:
Illustrator (these days) handles this in a sane way IMO. There is a switch for the Document Color Mode - RGB or CMYK. When selecting/creating a color in RGB mode, RGB sliders are presented and vice versa in CMYK mode (actually, you can use any sliders in any mode
- it just gets converted on the fly to match the doc's color mode -
but not really on-topic). What makes this sane to me is that you never end up with a mix of RGB and CMYK in the same document - which can be a nightmare when getting ready for final output.
Actually... the insane part of that behavior is that CMYK=>RGB is a *lossy* conversion, and automatically doing it means that artists have their reason for using CMYK in the first place squashed/deleted.
Well, I set my doc to CMYK mode and I'm 100% sure all colors are in CMYK. That's what I mean by sane :) Switching spaces/profiles mid-job is always going to be messy (read lossy). I was mainly pointing to the per-doc setting: either RGB or CMYK. That part seems sane - automatic conversion is a little less sane, I agree ;)
With that being said, I don't particularly care for having the RGB sliders in CMYK mode but occasionally I sample something like a web page (with say, gColor2) and the colors are given in RGB/hex - being able to create a new color with RGB values and then have it instantly converted to CMYK on the fly is moderately useful - but then I don't do that very often.
To further complicate things, Adobe recommends keeping parts in RGB as long as possible, and only converting to CMYK as you actually place/print things through their publishing app, InDesign. (Unless you are working directly in the CMYK for the specific print job, it's better to keep the source piece of art in RGB so it can be converted for flyers, t-shirts, etc. with top fidelity).
Heh - not the first time I've disagreed with Adobe (seen the UI on CS3 and above?). I stay in CMYK colorspace 90% of the time. Even doing a web page layout (no really - it makes sense: if I use CMYK colors on the site, then their business cards, flyers, etc. can match the site). I get far less of "OMG my colors are totally wrong!!!" and "Why can't it be BLUE like my email sig?!" than the other way around. Plus, I can avoid those colors like #0000FF - which are not only painful to view, but will never, ever print properly in CMYK.
But then again, I don't like surprises much :)
Chris
On Dec 19, 2009, at 2:42 PM, Chris Mohler wrote:
So yes - I think it would be nice to store/render CMYK values inside Inkscape. Conversion via lcms would be nice to convert a color from RGB to CMYK *inside* Inkscape, but if I specify a color as c0m100y100k0 and save a TIFF, I would expect everything filled with that color to be 100% black on the MY channels, and 100% white on the CK channels. Trying to get the same result from RGB (with lcms) would be a crap-shoot at best. Another use case: rich black. Some print companies recommend/specify a black that is a particular formula: eg 60%C 40%M 40%Y 100%K.
FYI that is half-there in Inkscape now.
That is, Inkscape will store things in CMYK values if you use a CMYK ICC profile (which is how any real app works anyway).
What is not happening is calculating the rendering or exporting in CMYK. Although... on can grab the development version of Scribus, import a SVG with icc colors and have it do the right thing for publishing.
On 12/20/09, Jon Cruz wrote:
FYI that is half-there in Inkscape now.
That is, Inkscape will store things in CMYK values if you use a CMYK ICC profile (which is how any real app works anyway).
Only on Ubuntu 9.10 assigning a profile to a document doesn't work, because the combo box doesn't list any profiles (the one in Preferences dialog does list profiles).
Alexandre
On Sat, Dec 19, 2009 at 6:58 PM, Jon Cruz <jon@...18...> wrote:
That is, Inkscape will store things in CMYK values if you use a CMYK ICC profile (which is how any real app works anyway).
Jon: what if I have a CMYK TIFF with embedded profile - will Inkscape import it properly, preserving CMYK channels and the profile? If not what needs to be done for this? Is it possible with gdkpixbuf at all?
2009/12/19 Chris Mohler <cr33dog@...400...>:
Illustrator (these days) handles this in a sane way IMO. There is a switch for the Document Color Mode - RGB or CMYK.
Disclaimer: I don't know much about DTP, and I never worked in a print shop, but I'd like to learn more. Is there any benefit to having a CMYK document without an ICC profile? Here's my line of thought: if you have a CMYK document, and no ICC profile for the monitor, you have no guarantee that the built-in CMYK to RGB conversion that is required to display the document on the screen is correct.
I recently spent 3+ hours arguing with my father that you can't magically get better results by changing the colorspace, unless your equipment or programs are broken (e.g. you have no ICC profiles, and you know that black won't print correctly unless it's C100 M100 Y100 K100). Right now I think working in CMYK without color management is voodoo, but as mentioned before I am just a random opinionated non-expert.
Is CMYK rendered exactly the same by every printer? Are there such things as ICC profiles for printers? Why don't the print companies use those profiles with the customers' color-managed RGB documents?
Regards, Krzysztof
On Dec 20, 2009, at 10:20 AM, Krzysztof Kosiński wrote:
Is CMYK rendered exactly the same by every printer? Are there such things as ICC profiles for printers? Why don't the print companies use those profiles with the customers' color-managed RGB documents?
No, CMYK is rendered differently by each printer. In fact, two of the same model printer by the exact same company will render those colors differently. (Not "can", but "will". The only question is the amount that those colors will differ)
And, yes, ICC profiles are very common for printers. Or to be more precise, profiles for a specific printer with a specific type of paper and a specific type of ink are common.
For some workflows, explicit profiles are not always required to be included. For example, sRGB is a very specific colorspace with specific details, and ICC profiles exist for it. But since it is a common fallback, it is built in to many systems. LittleCMS, for example, has a call to return the sRGB profile... so one does not require an explicit .icc file for it. The W3C has declared its standards (incuding SVG) to use sRGB, so for those one does not need to explicitly attach an external ICC file.
There are several different "standardized" CMYK profiles out there that are comparable to sRGB. So one can use one of those profiles, "Sep Euro UCR340" or "U.S. Web Coated (SWOP) v2" perhaps, and then the print shop will do a conversion from that to the specific offset printer they have on the second floor when they run their job. There will be some data loss in that conversion, but if the target profile is close enough to the actual one used for the final print, then it will minimize issues.
For home users, on the other hand, one should have a specific ICC file per printer to be used. Test samples should be printed and then measured with a colorimeter to get that specific printer's results with that specific paper and that specific ink set. Then when proofs are printed locally the user can be sure it will be close to the final result. Given how low cost these have become, anyone who does any art jobs for at least some pay really has no excuse for not doing so.
And as to the question of using those profiles for RGB documents... sometimes one needs to work in CMYK. That used to be required, but nowadays wide-gamut RGB for photos and such will give better results. For things like overprint, sharpness in text, etc. an artist might need to go to explicit CMYK, but otherwise it can be compared to a programmer trying to optimize code by manually unrolling loops, etc. Compilers became smarter than programmers back in the early nineties, but many people kept the habits that now hurt instead of helped.
Oh, and a final caveat is that colors can and do change over time. Monitors will change their behavior over time (LCD's becoming dimmer, shifting hue, etc.), printers can change over time as things wear or even as the next ink cartridges are installed. So for a person's local system (printer, monitor, scanner) ICC profile files should be created periodically (perhaps monthly).
2009/12/20 Krzysztof Kosiński <tweenk.pl@...400...>:
2009/12/19 Chris Mohler <cr33dog@...400...>:
Illustrator (these days) handles this in a sane way IMO. There is a switch for the Document Color Mode - RGB or CMYK.
Disclaimer: I don't know much about DTP, and I never worked in a print shop, but I'd like to learn more. Is there any benefit to having a CMYK document without an ICC profile?
Yes - you can submit jobs for printing :) Many companies require CMYK files - see one example - it's item #1: http://home.sharpdots.com/index.cfm?HDID=GP&PAGE_ID=15
Here's my line of thought: if you have a CMYK document, and no ICC profile for the monitor, you have no guarantee that the built-in CMYK to RGB conversion that is required to display the document on the screen is correct.
Even a generic CMYK profile will eliminate many of the out-of-gamut colors present in RGB.
I recently spent 3+ hours arguing with my father that you can't magically get better results by changing the colorspace, unless your equipment or programs are broken (e.g. you have no ICC profiles, and you know that black won't print correctly unless it's C100 M100 Y100 K100). Right now I think working in CMYK without color management is voodoo, but as mentioned before I am just a random opinionated non-expert.
Yes, to be effective, both the screen and the doc should be managed. OTOH, assigning a default sRGB to the screen and default like SWOP for the doc should be enough for most cases (of sending a file to a print co, that is).
Is CMYK rendered exactly the same by every printer? Are there such things as ICC profiles for printers? Why don't the print companies use those profiles with the customers' color-managed RGB documents?
No, yes, and in theory that would work. In practice, the customer would likely use colors that are way out of gamut, so forcing CMYK mode causes what is on the customer's screen to more accurately reflect the final output. Basically, it lessens disputes. At least that's my theory. At any rate, I've yet to find any large print company that does not specify CMYK.
Chris
On Dec 20, 2009, at 11:15 AM, Chris Mohler wrote:
Yes, to be effective, both the screen and the doc should be managed. OTOH, assigning a default sRGB to the screen and default like SWOP for the doc should be enough for most cases (of sending a file to a print co, that is).
Well... sRGB doesn't work for any of the monitors in my house. Someone *really* needss to get a hardware device and measure the screen (they're not expensive at all nowadays).
LCD monitors are especially bad as far as range goes. Although a nice HDTV might do better. If you want details, you can see the slides from my presentation to linux.conf.au last year for some side-by-side comparisons of profiles.
Yes, to be effective, both the screen and the doc should be managed. OTOH, assigning a default sRGB to the screen and default like SWOP for the doc should be enough for most cases (of sending a file to a print co, that is).
Well... sRGB doesn't work for any of the monitors in my house. Someone *really* needss to get a hardware device and measure the screen (they're not expensive at all nowadays).
Well, I never trust a monitor anyway - calibrated or not ;) Do you have a recommendation for (linux-friendly) colorimeter?
LCD monitors are especially bad as far as range goes. Although a nice HDTV might do better. If you want details, you can see the slides from my presentation to linux.conf.au last year for some side-by-side comparisons of profiles.
Yes - I checked those out, thanks (http://lca2009.linux.org.au/slides/179.odp). Getting further off-topic, does anyone here use the ColorSync utility that ships with OSX? It has a nice (rotatable) visualization of each profile. Anyone know of a similar app for linux?
Chris
2009/12/20 Chris Mohler <cr33dog@...400...>:
Yes - I checked those out, thanks (http://lca2009.linux.org.au/slides/179.odp). Getting further off-topic, does anyone here use the ColorSync utility that ships with OSX? It has a nice (rotatable) visualization of each profile. Anyone know of a similar app for linux?
Chris
There is LPROF: http://lprof.sourceforge.net/ It is based on LittleCMS, and judging from the screenshots it looks advanced, but I don't know whether it is any good.
Regards, Krzysztof
On Dec 20, 2009, at 11:15 AM, Chris Mohler wrote:
2009/12/20 Krzysztof Kosiński <tweenk.pl@...400...>:
Here's my line of thought: if you have a CMYK document, and no ICC profile for the monitor, you have no guarantee that the built-in CMYK to RGB conversion that is required to display the document on the screen is correct.
Even a generic CMYK profile will eliminate many of the out-of-gamut colors present in RGB.
Or...
Just work in RGB and have CMYK set as the target profile for proofing. Inkscape will work that way, and will warn of out-of-gamut colors and everything.
participants (5)
-
Alexandre Prokoudine -
bulia byak -
Chris Mohler -
Jon Cruz -
Krzysztof Kosiński