matplotlib-devel Mailing List for matplotlib

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

Eric Firing wrote:
> Yes, I understand, and I am sorry--but I hope it is one-time pain to 
> avoid continuing pin-pricks. If svn ignored trailing whitespace, then 
> there would be no problem; I could continue to use an editor that 
> removes it, and you could continue to use editors that gratuitously add 
> it, and usually it would make no difference. This is not the case, 
> however. As it is now, if a file comes into svn without any trailing 
> whitespace, and one of you loads it up, maybe makes a trivial change 
> after running your cursor through it, and saves it--it will end up with 
> a big changeset--lots of trailing whitespace. This is just plain bad. 
> All downside, no upside.
> 
FWIW, you can get svn diff to ignore (trailing whitespace) -- by not
using svn diff.
svn diff --diff-cmd diff -x -uw path/to/file.py
With apologies for previously hijacking your thread into an emacs
configure-a-thon, :)
Andrew