Hi, > Publishers sometimes require electronic figures as tif or eps, and using > the cymk color system. We do everything in rgb. I don't understand > color systems well. What would be needed to give mpl the ability to > produce files using the cymk system? I don't understand color systems very well, either, but I ran into this problem when I printed out some color figures recently. I saved a mpl line plot containing 'r', 'g' and 'b' lines to a PDF file. The file displayed on-screen as expected, using both Linux acroread and Mac OS X Preview as viewer. It also printed out as expected on an HP Color Laserjet via Linux acroread. On the Mac, however, a straightforward printout resulted in purple instead of blue lines. The problem disappeared when I selected ColorSync -> Color Conversion -> In Printer in the print dialog. When I printed out an OmniGraffle PDF diagram, however, the colors were messed up using "In Printer" and correct when using "Standard" color conversion. This forced me to print the color pages in my thesis containing OmniGraffle diagrams and mpl figures using different printer settings, which is quite annoying. There is another option, which makes Linux and Mac PDFs much more compatible (especially for color), and that is PDF/X-3 (http://en.wikipedia.org/wiki/PDF/X). This subset of PDF forces the document to include all fonts and color profiles, leaving nothing to chance. While the file is possibly bigger, it is more likely to display correctly on all manner of printers and screens. I eventually converted my Omnigraffle diagrams to PDF/X-3, and now their colors and shadows appear correct on Linux, while they were psychedelic before. PDF/X-3 might be a worthwhile standard to follow for mpl figure output (even only as an option). At least embedding ICC profiles is probably a good idea. Regards, Ludwig
Ludwig Schwardt wrote: >> Publishers sometimes require electronic figures as tif or eps, and using >> the cymk color system. We do everything in rgb. I don't understand >> color systems well. What would be needed to give mpl the ability to >> produce files using the cymk system? > > PDF/X-3 might be a worthwhile standard to follow for mpl figure output > (even only as an option). At least embedding ICC profiles is probably > a good idea. That seems like a great suggestion (without knowing the details of what is really involved). I wonder if that would appease some of the publisher's requirements that Eric mentioned. I vaguely recall seeing CMYK requirements myself in the past, but I can't dig up any of them. I just wonder what *specifically* publishers may require, and whether providing an ICC profile in the PDF or converting rgb colors to cmyk on output (within matplotlib) is the better way to go. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Hi, On Nov 21, 2007 3:39 PM, Gael Varoquaux <gae...@no...> wrote: > I have had some problems printing posters on a plot where indeed the > colors came out a bit wrong. I was told by the staff that it was because > the conversion RGB->CMYK was handled differently by different printers > and screens. I don't know if providing and ICC profile would solve the > problem, but it can't harm. The ICC profile maps the device-dependent RGB (or CMYK) values stored in the plot to a device-independent color space (either CIE Lab or the equivalent XYZ). This independent color space describes *absolute* color - a point in Lab space is therefore intended to look the same on any screen or printer. When this profile is combined with a second ICC profile for the target screen or printer on which the plot is to be viewed/printed, it allows the color management software to convert the RGB values in the PDF to the appropriate RGB or CMYK values that will produce the intended absolute color on the target device. It is therefore important to realise that both RGB and CMYK are *relative* color spaces, relative to some device. The R, G and B values are merely weights mixing together the device's interpretation of true R, G and B (the same goes for CMYK). Some problems: - Devices produce different subsets of the set of all visible colors (the issue of color gamut). For example, CMYK printers struggle with highly saturated green. If you make an RGB plot on your LCD screen, a pure green line with color 'g' or 0x00FF00 may not ever come out the same way on your printer. - Matplotlib plots typically use an abstract concept of color. Lines are usually colored to distinguish them from each other, and frequently the absolute color is not that important. More importantly, there is typically no device associated with the input color (as is the case with images derived from scanners or digital cameras), and therefore no way to map the RGB relative values to absolute color. Possible solutions: - Use colors that are safe for printing and displaying (less saturated colors?). - Use Lab color, which is absolute. This is cumbersome, and RGB is much more commonplace and well-understood in plotting packages, including Matlab. - Associate a generic ICC profile with the mpl plot, to attach absolute color values to the RGB values in the plot in a consistent way. Maybe this is the default in many graphics file formats and therefore redundant, or maybe it does make a difference specifying it explicitly, I'm not sure. > Is this also possible for EPS, or are we stuck with the problem without a > good solution? As far as I can tell, you can embed ICC profiles in most graphic file formats, including PDF, EPS, JPG, PNG, SVG, TIFF, etc. Regards, Ludwig
Ludwig Schwardt wrote: > Possible solutions: > > - Use colors that are safe for printing and displaying (less saturated colors?). Avoid the extreme (255,0,0), (0,255,0), (0,0,255) colors, yes. For reasons which are fairly obvious given the physics, RGB devices do better displaying those than CMYK devices. Blues are especially poorly represented in CMYK media. OS X users can play around with these things using the ColorSync Utility.app program. Click on the "Profiles" button. On the left, there is a tree of profiles. Select "Generic RGB Profile". On the 3D plot, click the triangle in the upper left-hand corner and select "Hold for comparison". Now click the "Generic CMYK Profile". This shows a CMYK color gamut and an RGB color gamut in Lab space. The intersection of these two is the "safe region" where the colors on your screen can be represented in print. Of course, that is only if the printer driver knows about both profiles. > - Use Lab color, which is absolute. This is cumbersome, and RGB is > much more commonplace and well-understood in plotting packages, > including Matlab. Yeah, that's probably not too practical. > - Associate a generic ICC profile with the mpl plot, to attach > absolute color values to the RGB values in the plot in a consistent > way. Maybe this is the default in many graphics file formats and > therefore redundant, or maybe it does make a difference specifying it > explicitly, I'm not sure. It might be reasonable to specify that matplotlib uses the W3C standard sRGB colorspace. It was meant to be good for representability on a wide variety of computer monitors. Some monitors may even be manufactured to match that standard. It is the default colorspace for SVG and PNG. It misses a fair chunk of most the usual CMYK space in the greens and cyans, though. Adobe RGB (1998) would be better for print, but that "wastes" a lot of space on greens that most monitors can't represent. Some journals require figures in Adobe RGB (1998). Really implementing this still requires one to apply calibrated ICC profiles of your viewing device and potential output devices, but it does standardize the files matplotlib outputs. I have some code that wraps the lcms library for applying ICC profiles to numpy arrays. Those who saw my lightning talk at SciPy '07 saw an app I had for showing colormaps in perceptual colorspaces like Lab and with transformations to simulate colorblindness. I'm snowed under work next week, but after that I'll try to clean it up for doing soft-proofs of images. Maybe I'll even get to integrating that soft-proofing with matplotlib such that every interactive plot can be displayed as if it were printed (or seen through my colorblind eyes). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
I have had some problems printing posters on a plot where indeed the colors came out a bit wrong. I was told by the staff that it was because the conversion RGB->CMYK was handled differently by different printers and screens. I don't know if providing and ICC profile would solve the problem, but it can't harm. Is this also possible for EPS, or are we stuck with the problem without a good solution? By the way, what is the status of TeX support in PDF. On the version I have on my box it is not running, but I don't run svn. Cheers, Gaël