[matplotlib-devel] imsave function

[Gary Ruben]

Hi,

I've attached a patch against the mpl head in response to John's 
suggestion and helpful pointers on the users list. This adds a new 
function imsave to complement imread in the image module. I've also 
exposed it in the pyplot interface.
If this is presumptuous, feel free to remove it from the patch or ask me 
to remove it. This is my first contribution to matplotlib for a while 
and my first attempt at a patch like this.


Because I don't build matplotlib from source, I've done what testing I 
can without fully rebuilding matplotlib. I'd be reluctant to have this 
patch applied without someone else checking it first. It's pretty simple 
so applying it locally and running the demo file should be a good enough 
test.


thanks,
Gary Ruben
Index: matplotlib/CHANGELOG
===
--- matplotlib/CHANGELOG(revision 6889)
+++ matplotlib/CHANGELOG(working copy)
@@ -1,3 +1,6 @@
+2009-02-08 Added a new imsave function to image.py and exposed it in
+   the pyplot interface - GR
+
 2009-02-04 Some reorgnization of the legend code. anchored_text.py
added as an example. - JJL
 
Index: matplotlib/doc/_templates/index.html
===
--- matplotlib/doc/_templates/index.html(revision 6889)
+++ matplotlib/doc/_templates/index.html(working copy)
@@ -567,6 +567,17 @@
 
 
   
+imsave
+
+  
+
+  
+save array as an image file
+  
+
+
+
+  
 imshow
 
   
Index: matplotlib/doc/api/api_changes.rst
===
--- matplotlib/doc/api/api_changes.rst  (revision 6889)
+++ matplotlib/doc/api/api_changes.rst  (working copy)
@@ -19,6 +19,9 @@
 
 Changes for 0.98.x
 ==
+* Added new :func:`matplotlib.image.imsave` and exposed it to the
+  :mod:`matplotlib.pyplot` interface.
+
 * Remove support for pyExcelerator in exceltools -- use xlwt
   instead 
 
Index: matplotlib/lib/matplotlib/pyplot.py
===
--- matplotlib/lib/matplotlib/pyplot.py (revision 6889)
+++ matplotlib/lib/matplotlib/pyplot.py (working copy)
@@ -6,6 +6,7 @@
 from matplotlib.figure import Figure, figaspect
 from matplotlib.backend_bases import FigureCanvasBase
 from matplotlib.image import imread as _imread
+from matplotlib.image import imsave as _imsave
 from matplotlib import rcParams, rcParamsDefault, get_backend
 from matplotlib.rcsetup import interactive_bk as _interactive_bk
 from matplotlib.artist import getp, get, Artist
@@ -1181,6 +1182,7 @@
 legend  add a legend to the axes
 loglog  a log log plot
 imread  load image file into array
+imsave  save array as an image file
 imshow  plot image data
 matshow display a matrix in a new figure preserving aspect
 pcolor  make a pseudocolor plot
@@ -1230,7 +1232,7 @@
 def get_plot_commands(): return ( 'axes', 'axis', 'bar', 'boxplot', 'cla', 
'clf',
 'close', 'colorbar', 'cohere', 'csd', 'draw', 'errorbar',
 'figlegend', 'figtext', 'figimage', 'figure', 'fill', 'gca',
-'gcf', 'gci', 'get', 'gray', 'barh', 'jet', 'hist', 'hold', 'imread',
+'gcf', 'gci', 'get', 'gray', 'barh', 'jet', 'hist', 'hold', 'imread', 
'imsave',
 'imshow', 'legend', 'loglog', 'quiver', 'rc', 'pcolor', 'pcolormesh', 
'plot', 'psd',
 'savefig', 'scatter', 'set', 'semilogx', 'semilogy', 'show',
 'specgram', 'stem', 'subplot', 'table', 'text', 'title', 'xlabel',
@@ -1370,6 +1372,11 @@
 if _imread.__doc__ is not None:
 imread.__doc__ = dedent(_imread.__doc__)
 
+def imsave(*args, **kwargs):
+return _imsave(*args, **kwargs)
+if _imsave.__doc__ is not None:
+imsave.__doc__ = dedent(_imsave.__doc__)
+
 def matshow(A, fignum=None, **kw):
 """
 Display an array as a matrix in a new figure window.
Index: matplotlib/lib/matplotlib/pylab.py
===
--- matplotlib/lib/matplotlib/pylab.py  (revision 6889)
+++ matplotlib/lib/matplotlib/pylab.py  (working copy)
@@ -50,6 +50,7 @@
   ion  - turn interaction mode on
   isinteractive - return True if interaction mode is on
   imread  

Re: [matplotlib-devel] imsave function

[Gary Ruben]

Thanks for the quick test and comments Andrew. I've made your suggested 
changes and attached a new patch.


Gary

Andrew Straw wrote:

Hi Gary, I have a couple comments:

1) No need for:

+ax = fig.add_subplot(111)
+ax.set_axis_off()

2) It's probably best to have maximum compatibility with imshow().
Therefore, use vmin=None and vmax=None as keyword arguments (rather than
clims).

Otherwise, I tested and it works for me.

-Andrew


Index: matplotlib/CHANGELOG
===
--- matplotlib/CHANGELOG(revision 6889)
+++ matplotlib/CHANGELOG(working copy)
@@ -1,3 +1,6 @@
+2009-02-08 Added a new imsave function to image.py and exposed it in
+   the pyplot interface - GR
+
 2009-02-04 Some reorgnization of the legend code. anchored_text.py
added as an example. - JJL
 
Index: matplotlib/doc/_templates/index.html
===
--- matplotlib/doc/_templates/index.html(revision 6889)
+++ matplotlib/doc/_templates/index.html(working copy)
@@ -567,6 +567,17 @@
 
 
   
+imsave
+
+  
+
+  
+save array as an image file
+  
+
+
+
+  
 imshow
 
   
Index: matplotlib/doc/api/api_changes.rst
===
--- matplotlib/doc/api/api_changes.rst  (revision 6889)
+++ matplotlib/doc/api/api_changes.rst  (working copy)
@@ -19,6 +19,9 @@
 
 Changes for 0.98.x
 ==
+* Added new :func:`matplotlib.image.imsave` and exposed it to the
+  :mod:`matplotlib.pyplot` interface.
+
 * Remove support for pyExcelerator in exceltools -- use xlwt
   instead 
 
Index: matplotlib/lib/matplotlib/pyplot.py
===
--- matplotlib/lib/matplotlib/pyplot.py (revision 6889)
+++ matplotlib/lib/matplotlib/pyplot.py (working copy)
@@ -6,6 +6,7 @@
 from matplotlib.figure import Figure, figaspect
 from matplotlib.backend_bases import FigureCanvasBase
 from matplotlib.image import imread as _imread
+from matplotlib.image import imsave as _imsave
 from matplotlib import rcParams, rcParamsDefault, get_backend
 from matplotlib.rcsetup import interactive_bk as _interactive_bk
 from matplotlib.artist import getp, get, Artist
@@ -1181,6 +1182,7 @@
 legend  add a legend to the axes
 loglog  a log log plot
 imread  load image file into array
+imsave  save array as an image file
 imshow  plot image data
 matshow display a matrix in a new figure preserving aspect
 pcolor  make a pseudocolor plot
@@ -1230,7 +1232,7 @@
 def get_plot_commands(): return ( 'axes', 'axis', 'bar', 'boxplot', 'cla', 
'clf',
 'close', 'colorbar', 'cohere', 'csd', 'draw', 'errorbar',
 'figlegend', 'figtext', 'figimage', 'figure', 'fill', 'gca',
-'gcf', 'gci', 'get', 'gray', 'barh', 'jet', 'hist', 'hold', 'imread',
+'gcf', 'gci', 'get', 'gray', 'barh', 'jet', 'hist', 'hold', 'imread', 
'imsave',
 'imshow', 'legend', 'loglog', 'quiver', 'rc', 'pcolor', 'pcolormesh', 
'plot', 'psd',
 'savefig', 'scatter', 'set', 'semilogx', 'semilogy', 'show',
 'specgram', 'stem', 'subplot', 'table', 'text', 'title', 'xlabel',
@@ -1370,6 +1372,11 @@
 if _imread.__doc__ is not None:
 imread.__doc__ = dedent(_imread.__doc__)
 
+def imsave(*args, **kwargs):
+return _imsave(*args, **kwargs)
+if _imsave.__doc__ is not None:
+imsave.__doc__ = dedent(_imsave.__doc__)
+
 def matshow(A, fignum=None, **kw):
 """
 Display an array as a matrix in a new figure window.
Index: matplotlib/lib/matplotlib/pylab.py
===
--- matplotlib/lib/matplotlib/pylab.py  (revision 6889)
+++ matplotlib/lib/matplotlib/pylab.py  (working copy)
@@ -50,6 +50,7 @@
   ion  - turn interaction mode on
   isinteractive - return True if interaction mode is on
   imread   - load image file into array
+  imsave   - save array as an image file
   imshow   - plot image data
   ishold   - return the hold state of the current axes
   legend   - make an axes legend
Index: matplotlib/lib/matplotlib/image.py
===
--- matplotlib/lib/matplotlib/image.py  (revision 6889)
+++ matplotlib/lib/matplotlib/image.py  (working copy)
@@ -747,7 +747,43 @@
 return handler(fname)
 
 
+def imsave(fname, arr, vmin=None, vmax=None, cmap=None, format=None, 
origin=None):
+"""
+Saves a 2D :class:`numpy.array` as an image with one pixel per element.
+The output formats available depend on the backend being used.
 
+Arguments:
+  *fname*:
+A string containing a path to a filename, or a Python file-like object.
+If *format* is *None* and *fname* is a string, the output
+format is deduced from the extension of the filename.
+  *

Re: [matplotlib-devel] imsave function

[Gary Ruben]

Hi Andrew,

I don't have commit access. If you would check it in, that would be great.

thanks for offering,
Gary

Andrew Straw wrote:
> Gary, this looks fine to me. Do you have commit access? If not, I'll be
> happy to check it in for you.
> 
> -Andrew


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo Backend and Subpixel Rendering

[Gary Ruben]

John Hunter wrote:

> The matplotlib.lines.Line2D objects has an antialiased property -- we
> could add the same property to matplotlib.text.Text to turn on/off
> subpixel rendering (which could also be supported as an rc param)
> 
> JDH

What are the supported combinations of subpixel rendering and 
antialiasing? Are they mutually exclusive? If Cairo supports both at the 
same time, I don't think it would be a good idea to enable subpixel 
rendering using a property called "antialiased".

Gary R.

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Color map gamma

[Gary Ruben]

I think this would be useful.
While you're at it, in the attached file I have a function 
"rescale_cmap" that effectively changes the autoscaling of the colormap 
to the data by allowing specification of the range limits - I find this 
useful.
You might like to look at this to see if it's worth generalising your 
additions a little,


Gary

Reinier Heeres wrote:

Hi all,

I would like to propose the attached patch to be able to use a gamma
value for color maps. This will make it simple to make your color
scale more 'sensitive' at the bottom or at the top, as can be seen in
the attached example. This could in principle also be solved by adding
a gamma normalizer, but I think that applying it to a color map is
quite coming practice, so in this case the preferred way.

I'd also like to add a few extra color maps (at least one plain
blue-white-red and one with darker shades at the high and low ends, as
in the attachment). I also remember a particular one ('terrain') in a
measurement program called 'Igor' that would be nice.

Looking at _cm.py, I would guess that could be done a bit more
efficient than the current 5880 lines as well by just specifying a few
colors and using LinearSegmentedColormap.from_list(). Is it ok if I
try to refactor that?

Let me know what you think.

Cheers,
import numpy as np
from numpy import dstack, pi
import matplotlib.pyplot as plt
import types
import matplotlib.colors as colors
import matplotlib._cm as _cm
from scipy.ndimage import maximum_filter

def rescale_cmap(cmap_name, low=0.0, high=1.0, plot=False):
'''
Example 1:
my_hsv = rescale_cmap('hsv', low = 0.5) # equivalent scaling to 
cplot_like(blah, l_bias=0.33, int_exponent=0.0)
Example 2:
my_hsv = rescale_cmap(cm.hsv, low = 0.5)
'''
if type(cmap_name) == types.StringType:
cmap = eval('_cm._%s_data' % cmap_name)
else:
cmap = eval('_cm._%s_data' % cmap_name.name)
LUTSIZE = plt.rcParams['image.lut']
r = np.array(cmap['red'])
g = np.array(cmap['green'])
b = np.array(cmap['blue'])
range = high - low
r[:,1:] = r[:,1:]*range+low
g[:,1:] = g[:,1:]*range+low
b[:,1:] = b[:,1:]*range+low
_my_data = {'red':   tuple(map(tuple,r)),
'green': tuple(map(tuple,g)),
'blue':  tuple(map(tuple,b))
   }
my_cmap = colors.LinearSegmentedColormap('my_hsv', _my_data, LUTSIZE)

if plot:
plt.figure()
plt.plot(r[:,0], r[:,1], 'r', g[:,0], g[:,1], 'g', b[:,0], b[:,1], 'b', 
lw=3)
plt.axis(ymin=-0.2, ymax=1.2)

return my_cmap
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib image tutorial

[Gary Ruben]

Very nice addition Michael.

I note that the plt.colormap() line must have gotten lost. It's referred 
to but not there.
I'll add some ideas to John's list:

* Demonstrate the imsave() command.
* Rather than show 50 lines or so of array data, just show a few lines, 
but demonstrate what img.shape is before and after slicing out the B 
channel with img[:,:,0]
* It may be worth mentioning explicitly that img[:,:,0] will give you 
the blue channel for an RGB and an RGBA image.
* Demonstrate the "upper" and "lower" keywords where relevant.
* Add a pointer to the scipy.ndimage module
* Extend the examples with RGB and RGBA images.
* You might like to show how to recarrays and views on the individual 
colour channels. There are examples in the mailing list archives or 
maybe on the scipy website - I can't remember where.
* If you want to get more advanced, talk about higher bit depth images 
than 8 bits per channel.
* If you want to get even more advanced, show how to change the UI to 
probe the pixel value (I wish matplotlib did this by default).

Gary R.

John Hunter wrote:
> On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan 
> wrote:
>> Here you go.  If you can think of anything else to include, I'll work
>> on it.  I think the next thing I'll add is something on embedding
>> images in the corners of plots.  figimage is the way to do this,
>> right?


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] imsave function

[Gary Ruben]

Currently imsave (implemented in the image.py file) only deals with 
greyscale single-plane images, i.e. 2D arrays, and in my defence, it's 
in the docstring, so I wouldn't call it a bug. However, it's a 
reasonable expectation that it support rgb and rgba since it is 
basically a thin wrapper around figimage.


My first try at this was to change the line

fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)

to

fig = Figure(figsize=(arr.shape[1],arr.shape[0]), dpi=1, frameon=False)

since we just want to take the first two shape values.

(note figsize=arr.shape[:2][::-1] also works)

This may be all you need. My tests (in the attached test.py) appear to 
work. However, I don't think it's what you want. By default, figimage 
even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging 
from 0-1. What you probably want is a raw RGB mapping where pixel planes 
 are unsigned 8 bit values. I thought calling figimage with a 
norm=no_norm(0,255) instance achieved this but it doesn't work as I 
expect. So the first question is, what is the expected behaviour here, 
and a follow-up is does anyone here understand how to do the colour 
mapping to achieve it?


Gary

Stéfan van der Walt wrote:

Hey all,

2009/2/10 Andrew Straw :

Gary Ruben wrote:

Hi Andrew,

I don't have commit access. If you would check it in, that would be great.

Committed to the trunk in r6899... Thanks!

And, sheesh, SourceForge's SVN server is slooow today for me, although
it seems to have finally improved.


While trying to write a matplotlib plugin for scikits.image, we
noticed that `imsave` isn't currently working (that goes for the one
in Ubuntu [0.99 I think] as well as the latest SVN):

Traceback (most recent call last):
  File "test_imsave.py", line 6, in 
plt.imsave('test.jpg', img)
  File "/Users/stefan/lib/python2.6/site-packages/matplotlib/pyplot.py",
line 1412, in imsave
return _imsave(*args, **kwargs)
  File "/Users/stefan/lib/python2.6/site-packages/matplotlib/image.py",
line 1025, in imsave
fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
  File "/Users/stefan/lib/python2.6/site-packages/matplotlib/figure.py",
line 180, in __init__
self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
TypeError: from_bounds() takes exactly 4 arguments (5 given)

The commands needed to reproduce the error are:

import matplotlib.pyplot as plt
import numpy as np

img = np.ones((50, 50, 3), dtype=np.uint8)

plt.imsave('test.jpg', img)

Regards
Stéfan

def imsave(fname, arr, vmin=None, vmax=None, cmap=None, format=None, 
origin=None):
"""
Saves a 2D :class:`numpy.array` as an image with one pixel per element.
The output formats available depend on the backend being used.

Arguments:
  *fname*:
A string containing a path to a filename, or a Python file-like object.
If *format* is *None* and *fname* is a string, the output
format is deduced from the extension of the filename.
  *arr*:
A 2D array.
Keyword arguments:
  *vmin*/*vmax*: [ None | scalar ]
*vmin* and *vmax* set the color scaling for the image by fixing the
values that map to the colormap color limits. If either *vmin* or *vmax*
is None, that limit is determined from the *arr* min/max value.
  *cmap*:
cmap is a colors.Colormap instance, eg cm.jet.
If None, default to the rc image.cmap value.
  *format*:
One of the file extensions supported by the active
backend.  Most backends support png, pdf, ps, eps and svg.
  *origin*
[ 'upper' | 'lower' ] Indicates where the [0,0] index of
the array is in the upper left or lower left corner of
the axes. Defaults to the rc image.origin value.
"""
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure

fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
canvas = FigureCanvas(fig)
fig.figimage(arr, cmap=cmap, vmin=vmin, vmax=vmax, origin=origin)
fig.savefig(fname, dpi=1, format=format)


def newimsave(fname, arr, vmin=None, vmax=None, cmap=None, format=None, 
origin=None):
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure

fig = Figure(figsize=arr.shape[:2][::-1], dpi=1, frameon=False)
canvas = FigureCanvas(fig)
fig.figimage(arr, cmap=cmap, vmin=vmin, vmax=vmax, origin=origin)
fig.savefig(fname, dpi=1, format=format)
import numpy as np
import matplotlib.pyplot as plt
from my_plottools import newimsave

arr = np.empty((20,20,3),dtype=np.uint16)
arr[...,0] = np.tri(20)*255/3
arr[...,1] = arr[:,::-1,0]
arr[...,2] = arr[::-1,:,0]

newimsave(r'd:\temp\test1.png', arr)

arr = np.empty((20,30,3),dtype=np.uint16)
ar

Re: [matplotlib-devel] imsave function

[Gary Ruben]

So I think the change I suggested takes care of the floating point case, 
except that the vmin and vmax values don't default to 0.0 and 1.0. I 
wonder whether this is enough of a surprise to warrant some logic to set 
  vmin and vmax in some cases, such as iff all array values are floats 
in the range 0.0-1.0 and neither vmin nor vmax have been specified as 
arguments, then use vmin=0.0 and vmax=1.0. Should we aim to replicate 
the scipy imsave behaviour exactly? Another possible problem with the 
current behaviour is that single bit plane arrays currently get saved as 
RGB - I don't know if this can be changed easily.

Gary

Stéfan van der Walt wrote:
> Hi Gary
> 
> Sorry, I didn't even read the docstring since I have been using
> SciPy's "imsave" so far.
> 
> 2009/11/8 Gary Ruben :
>> This may be all you need. My tests (in the attached test.py) appear to
>> work. However, I don't think it's what you want. By default, figimage
>> even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging
>> from 0-1. What you probably want is a raw RGB mapping where pixel planes
>>  are unsigned 8 bit values. I thought calling figimage with a
>> norm=no_norm(0,255) instance achieved this but it doesn't work as I
>> expect. So the first question is, what is the expected behaviour here,
>> and a follow-up is does anyone here understand how to do the colour
>> mapping to achieve it?
> 
> We assume that arrays of dtype uint8 represent intensities 0 through
> 255, and that floating point arrays are between 0-1.
> 
> Regards
> Stéfan
> 

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] auto range limits for spines: please kick the tires

[Gary Ruben]

This looks nice Andrew,
I haven't tried it, but I wonder whether it's possible to add a keyword 
arg to suppress the 0's at the origin which are cut through by the axes 
in the zeroed case (and/or possibly shift the 0 on the horizontal axis 
left). The same thing is happening in the (1,2) case on the vertical axis.

Gary

Andrew Straw wrote:
> I have implemented something I'm calling "smart bounds" for the axis
> spines, and have just committed it to svn r8048. I modified
> examples/pylab_examples/spine_placement_demo.py to illustrate the basic
> idea -- the spines and ticks should be able to automatically limit
> themselves to the data range. There are some subtleties beyond that in
> terms of the algorithmic details, but I think if you update from svn and
> play around with the demo, especially by panning and zooming in the
> figures, you'll get an idea of what I've done. I've attached two images
> from such a session.
> 
> The key API addition is this:
> 
>   spine.set_smart_bounds(True)
> 
> Doing so turns on the smart bounds mode in the spine and the axis.
> 
> Anyhow, I'd be happy to receive any feedback on this new feature.
> 
> -Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] imsave, image size

[Gary Ruben]

Just saw this thread and thought I should explain that this was indeed a 
hack by me which was aimed to do exactly what Michael said. I never 
thought there'd be any side effects from doing this - it's interesting 
that pdfLaTeX balks because it has never done so for me. Anyway, thanks 
Michael for addressing this.

Gary R.

Michael Droettboom wrote:
> Ok, I have a better fix in SVN r8300.  imsave now accepts a "dpi" kwarg 
> (default of 100) to set the DPI metadata in the file.
> 
> Mike
> 
> Michael Droettboom wrote:
>> You're right.  Thanks for the sanity check.
>>
>> What's happening is that when using imsave is used, it generates a 
>> figure image with a dpi of 1 (to force 1 output pixel per input pixel), 
>> but this is sort of a hack.  Let me see if I can find a way around this 
>> hack.
>>
>> Mike


--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Re: collection initializer color handling vs quiver

[Gary Ruben]

Hi Jordan,

Thanks for your heads-up. I actually left this and went back to using 
polygon patches for the arrows, mainly because I thought I'd have more 
control over the size without having to do any fancy line collection 
stuff. Re. your change, the call to the LineCollection__init__ function 
in axes.py just needs an extra set of []'s around the list comprehension 
and all is OK, but your solution could work too.
I do intend to look again at the transform stuff to try to get arrows 
transforming properly - just very busy at the moment, but then I usually am.


Gary R.

I've found one problem with your Arrow LineCollection; it's not actually 
a line collection.  It's one line, so some of the LineCollection 
functions fail on it.  You need to break up the arrow into segments, 
like this:


'barbed': array([ [ [0.,0.], [L,0.] ],
 [ [L,0.], [L-S,S/3] ],
 [ [L,0.], [L-S,-S/3] ] ]

Except just doing this will break the matrixmultiply.  Just a heads-up.

Jordan





---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] new Quiver progress

[Gary Ruben]

This is good news Eric and sounds like the desired behaviour.
Thanks for letting me know. I was intending to try to work it out this 
weekend but have spent my time instead learning to build 
numpy/scipy/matplotlib from source - a worthwhile exercise. I don't 
think JDH/Charlie should wait for new quiver plots before doing another 
release.

On the scaled down arrows, do you see strange artifacts when viewing at 
certain magnifications? JDH thought this might be due to subpixel 
rendering problems, although I wasn't sure that was the reason. I look 
forward to seeing how the transform stuff works. I found it all a bit 
unfathomable.

thanks,
Gary

Eric Firing wrote:
> Jordan, Gary,
> 
> I have been working on another implementation of quiver functionality.  It is 
> not ready to commit yet, but I think I have the transforms worked out 
> reasonably well.  The arrows never get distorted, and their orientation is 
> preserved as the axes are manipulated.  Length can be preserved or not, 
> depending on the units one chooses. Below a threshold, the whole arrow is 
> scaled down as its length is reduced; above that threshold, only the length 
> changes. I am subclassing PolyCollection, so there is full flexibility in 
> rendering with or without an edge.
> 
> I expect I will be ready to commit something within a week.
> 
> Eric



___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] new Quiver progress

[Gary Ruben]

Hi Eric,

Having entered the build-from-source world with the latest ubuntu, I 
applied your patch and tried it out with the example code I sent you 
using a call similar to

quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2)

This works very nicely for my purposes - perfectly in fact.
Many thanks for your work on this.
The only thing I think might be nice to add is some sort of minsize 
parameter so that you could get a pixel or something marking the 
existence of a data value for a grid point or a tiny arrowhead, sort of 
like the current svn quiver behaves, but size settable. I tried adding 
linewidths=(1,) to see if this would work. It sort of works, but looks 
pretty ugly and I think confirms my suspicion that the problems I had 
seen in my attempts were due to line stroking.

Thanks and good work!

Gary


___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] new Quiver progress

[Gary Ruben]

Eric Firing wrote:
> Gary,
> 
> Thanks for the prompt test and report.
> 
> I agree that the ability to put a dot at locations where arrows are 
> below a threshold would be good.  I will add it.  I think it should be 
> similar to a circle marker that scales with the arrow width, and has a 
> diameter that is a fraction of that width.

That sounds like a good idea.

> I also observed the stroking problem with small arrows and finite 
> linewidth.  I haven't checked into it, but I am wondering whether the 
> problem is in the specification of the line join type.

I suspect you're right about the join type. When I was building arrows 
out of LineCollections I had my suspicions that this was the problem. I 
didn't look into what control Agg gives you over this - there may not be 
an appropriate join type which always looks good.

regards,
Gary


___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Questions about mathtext, unicode conversion etc.

[Gary Ruben]

Hi Edin,

Edin Salković wrote:
> Hi all,
> 

> Also, if anyone has some good online sources about parsing etc. on the
> net, I vwould realy appreciate it.

Everything that David Mertz wrote about text processing in his excellent 
"Charming Python" articles:


and "Building Recursive Descent Parsers with Python":
http://www.onlamp.com/pub/a/python/2006/01/26/pyparsing.html

If you were after a book on the subject, Mertz's book "Text Processing 
in Python"  would be an obvious choice or you 
could pick up any book about writing compilers.

Gary R.


___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] bug 1798196: Axes3D bug

[Gary Ruben]

If someone decides to poke around in the 3D plotting files in response 
to Leon's efforts, there's another fix posted a while back which was not 
applied:

I tried this at the time and it worked with no obvious side effects.

Gary R.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ghostscript version fix

[Gary Ruben]

Yep. Works.

C:\WINDOWS>gswin32c --version
8.51


Darren Dale wrote:

> gs --version works with AFPL. Could someone please check that this works on 
> windows: gswin32c --version
> 
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] future of mpl documentation

[Gary Ruben]

My 2 cents:
I think it looks better if you reduce the number of histogram bins from 
50 down to 15 or 20.
Gary R.

John Hunter wrote:
> I played around with this a bit this morning -- it may be too busy for
> your OS X sensibilities, but let me know if you think think this is an
> approach wotrh pursuing.  I've added the mathtext background and a few
> axes and there are a few more axes to do.  In svn as
> examples/api/logo2.py

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[gary ruben]

I also see this in mpl 1.1.0, python 2.7.2 with the iPython Qt console
and also with the WXAgg backend

Gary R.

On 30 October 2012 03:16, Nicolas Rougier  wrote:
>
>
> matplotlib 1.2.x
> python 2.7.2
> osx10.7.5
>
>
> Nicolas
>
> On Oct 29, 2012, at 16:29 , Benjamin Root wrote:
>
>>
>>
>> On Mon, Oct 29, 2012 at 11:25 AM, Nicolas Rougier  
>> wrote:
>>
>>
>> Thanks for testing.
>>
>> If I zoom at any line cross, the lines are definitely at the wrong place for 
>> me.
>> As for screen aliasing I'm not sure since both the png and pdf seems to be 
>> wrong in my case.
>> Weird !
>>
>>
>>
>> Which version of matplotlib are you using, just for reference.
>>
>> Ben Root
>>
>
>
> --
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Bug in imsave

[gary ruben]

Hi, I haven't looked at this list for a long time, so hi to all the active
devs.
I just came across a problem in the image.py imsave() function.

Problem:
At an ipython --pylab prompt, typing

a = rand(29,29)
imsave('test.png', a)

incorrectly generates a 28x28 pixel image.
This happens for several array sizes (I initially saw it for 226x226).

Line 1272 of image.py is
figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]

figsize interacts with the bounding box code somehow to create off-by-one
results for certain values of array shape.


Possible solution:
To fix this properly, I think the float cast should be removed and
integer-based math should be used, but I thought that since it was rounding
down in the cases I saw, a change to the following should fix this:

figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]

and indeed this seems to work.
To verify this, I ran the following brute-force test of all image sizes up
to 1024x1024 at some common dpi values:

import matplotlib.pyplot as plt
import numpy as np
import os

for dpi in [75, 100, 150, 300, 600, 1200]:
for i in range(1,1025):
print dpi, i,
im = np.random.random((i,i))
fname = 'test{:03d}.png'.format(i)
plt.imsave(fname, im, dpi=dpi)
im = plt.imread(fname)[:,:,0]
print im.shape
assert im.shape == (i, i)
os.remove(fname)

and everything passed.

For completeness I also explored the dpi-space with these loop ranges and
the above loop body:

for dpi in range(1, 101):
for i in range(25, 36):
...

and all was still well.


Workaround:
For the moment I've set dpi=1 in my call to imsave which effectively
reverts its behaviour to the original imsave code prior to the introduction
of the dpi parameter.

I think this testing is rigorous enough to make this change.
If you agree, has anyone got time to change this, or shall I do a pull
request when I have time?

thanks,
Gary
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in imsave

[gary ruben]

ceil doesn't work for me
I tried
figsize = [np.ceil(x / float(dpi)) for x in (arr.shape[1], arr.shape[0])]
and it fails on my second test when dpi=2 and i=25
result=26x26

Gary


On 9 April 2013 07:03, Michael Droettboom  wrote:

>  On 04/08/2013 02:38 PM, Benjamin Root wrote:
>
>
>
>
> On Sun, Apr 7, 2013 at 4:39 AM, gary ruben  wrote:
>
>>   Hi, I haven't looked at this list for a long time, so hi to all the
>> active devs.
>>  I just came across a problem in the image.py imsave() function.
>>
>> Problem:
>> At an ipython --pylab prompt, typing
>>
>> a = rand(29,29)
>> imsave('test.png', a)
>>
>>  incorrectly generates a 28x28 pixel image.
>> This happens for several array sizes (I initially saw it for 226x226).
>>
>> Line 1272 of image.py is
>> figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>> figsize interacts with the bounding box code somehow to create off-by-one
>> results for certain values of array shape.
>>
>>
>> Possible solution:
>> To fix this properly, I think the float cast should be removed and
>> integer-based math should be used, but I thought that since it was rounding
>> down in the cases I saw, a change to the following should fix this:
>>
>> figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>>  and indeed this seems to work.
>>  To verify this, I ran the following brute-force test of all image sizes
>> up to 1024x1024 at some common dpi values:
>>
>> import matplotlib.pyplot as plt
>> import numpy as np
>> import os
>>
>> for dpi in [75, 100, 150, 300, 600, 1200]:
>> for i in range(1,1025):
>> print dpi, i,
>> im = np.random.random((i,i))
>> fname = 'test{:03d}.png'.format(i)
>> plt.imsave(fname, im, dpi=dpi)
>> im = plt.imread(fname)[:,:,0]
>> print im.shape
>> assert im.shape == (i, i)
>> os.remove(fname)
>>
>>  and everything passed.
>>
>>  For completeness I also explored the dpi-space with these loop ranges
>> and the above loop body:
>>
>> for dpi in range(1, 101):
>> for i in range(25, 36):
>> ...
>>
>> and all was still well.
>>
>>
>>  Workaround:
>>  For the moment I've set dpi=1 in my call to imsave which effectively
>> reverts its behaviour to the original imsave code prior to the introduction
>> of the dpi parameter.
>>
>>  I think this testing is rigorous enough to make this change.
>>  If you agree, has anyone got time to change this, or shall I do a pull
>> request when I have time?
>>
>>  thanks,
>>  Gary
>>
>>
>  Good catch on this.  So you are saying that this bug was introduced
> relatively recently with the dpi kwarg?  I would suggest you make a PR so
> that this doesn't get lost (or at the very least file a bug report).  As
> for the fix itself, off the top of my head, wouldn't math.ceil() do what we
> want?  I prefer to be explicit in any intents rather than just simply (x +
> 0.5) / float(dpi).  As for the test, I would wonder if some sort of
> restricted version of that test might not be good to do?  I am thinking
> about 10 different sized plots and we wouldn't even need to have a the
> assert check or file removal test, as the image comparison framework would
> throw an exception when attempting to compare two images of different sizes
> (I think...).
>
>
> I think this bug goes back at least to hash 17192518, by me in May 2010.
> The suggested fix (probably using ceil to be more explicit as you suggest)
> seems right.
>
> As for the test, I think just `imsave` to a buffer, and loading that
> buffer back in with `imread` and asserting the sizes are the same should be
> sufficient.
>
> Mike
>
>
> --
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Better defaults all around?

[gary ruben]

A few thoughts to add to the excellent ones to date, to do with colorbar
behaviour.
My general comment would be that if the axis tick formatter defaults are
changed not to forget about the colorbar as I typically find it needs more
tweaking than the main axes.
I'll make a couple of suggestions, but these are low on the list compared
to the suggestions that others have made.

1. consider rasterizing colorbar contents by default
2. make colorbar axis sizing for matshow behave like imshow


1. consider rasterizing colorbar contents by default
Eric describes this here
http://matplotlib.1069221.n5.nabble.com/rasterized-colorbar-td39582.html
and suggests that rasterizing the colorbar may not be desirable, although
I'm not totally sure why. Perhaps it is because I have noticed that mixing
rasterized content with vector lines/axes in matplotlib is generally
imperfect. If saving the figure as a pdf or svg with dpi left at default,
you can usually see offsets and scaling problems. For example after
rasterizing a colorbar I usually see white pixels along the top and side
within the vector colorbar frame. This also shows up when using imshow or
matshow to show images. I don't know if this is an agg limitation, a
backend limitation or a bug. If it's a known limitation, maybe avoid this
suggestion, but if it's a bug, maybe it can be fixed and then rasterizing
the colorbar might become a better default option.

For colorbars I usually do lots of tweaking along the lines of:

cb = plt.colorbar(format=ScalarFormatter(useMathText=True))
cb.formatter.set_useOffset(False)
cb.formatter.set_scientific(True)
cb.formatter.set_powerlimits((0,2))
cb.update_ticks()
cb.solids.set_rasterized(True)

although I'm not sure about advocating useMathText and set_scientific for
defaults. I wonder what other think about this?

Things like default powerlimits for the colorbar might be rethought. I
think colorbars typically have too many ticks and associated labels and
they should perhaps favour integer labels over floating point
representation if possible.
In the extreme case, for continuous colormaps, often a tick at just the top
and bottom of the range would be adequate.

2. I'm not sure how much pyplot.matshow is generally used but I still use
it.
Could the colorbar height for matshow pick up the axis height of the main
figure, or maybe imshow could default to interpolation='nearest' so I
wouldn't be tempted to use matshow any more?

For example,
plt.matshow(rand(20,20))
plt.colorbar()

doesn't behave nicely like

plt.imshow(rand(20,20), interpolation='nearest')
plt.colorbar()


Gary

On 22 November 2014 at 19:06, Nicolas P. Rougier 
wrote:

>
> I would be also quite interested in having better defaults.  My list of
> "complains" are:
>
> * Easy way to get only two lines for axis (left and down, instead of four)
> * Better default font (Source Sans Pro / Source Code Pro for example (open
> source))
> * Better default colormap
> * Better axis limit (when you draw with thick lines, they get cut)
> * Better icons for the toolbar (there are a lot of free icons around)
> * Better colors (more pastel)
> * Less "cluttered" figures
> * Lighter grids
>
> + All Nathaniel's suggestions
>
>
> Ideally, we could have a set of standard figures for each main type (plot,
> scatter, quiver) and tweak parameters to search for the best output.
>
>
> Nicolas
>
>
> > On 22 Nov 2014, at 04:18, Benjamin Root  wrote:
> >
> > With regards to defaults for 2.0, I am actually all for breaking them
> for the better. What I find important is giving users an easy mechanism to
> use an older style, if it is important to them. The current behavior isn't
> "buggy" (for the most part) and failing to give users a way to get behavior
> that they found desirable would be alienating. I think this is why projects
> like prettyplotlib and seaborn have been so important to matplotlib. It
> enables those who are in the right position to judge styles to explore the
> possibilities easily without commiting matplotlib to any early decision and
> allowing it to have a level of stability that many users find attractive.
> >
> > At the moment, the plans for the OO interface changes should not result
> in any (major) API breaks, so I am not concerned about that at the moment.
> Let's keep focused on style related issues in this thread.
> >
> > Tabbed figures? Intriguing... And I really do need to review that MEP of
> yours...
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <
> ariza.feder...@gmail.com> wrote:
> > I like the idea of aligning a set of changes for 2.0 even if still far
> away.
> >
> > Regarding to backwards compatibility I think that indeed it is important
> but when changing mayor version (1.x to 2.0) becomes less important and we
> must take care of prioritizing evolution.
> > Take for example the  OO interface (not defined yet) this is very
> probable to break the current pyplot interface but still this is a change
> that needs to be don

Re: [matplotlib-devel] Matplotlib's new default colormap

[gary ruben]

There was a talk by Kristen Thyng at scipy2014 that might be a good
backgrounder for this:
http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps

At the end she references this site http://mycarta.wordpress.com/ of Matteo
Niccoli which is full of good content. I wonder if it's worth contacting
Kristen or Matteo to let them know there's a discussion going on here that
they might be interested in?


On 22 November 2014 at 09:53, Eric Firing  wrote:

> On 2014/11/21, 4:42 PM, Nathaniel Smith wrote:
> > On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale  wrote:
> >> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson 
> wrote:
> >>>
> >>> Please use this thread to discuss the best choice for a new default
> >>> matplotlib colormap.
> >>>
> >>> This follows on from a discussion on the matplotlib-devel mailing list
> >>> entitled "How to move beyond JET as the default matplotlib colormap".
> >>
> >>
> >> I remember reading a (peer-reviewed, I think) article about how "jet"
> was a
> >> very unfortunate choice of default. I can't find the exact article now,
> but
> >> I did find some other useful ones:
> >>
> >>
> http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
> >> http://www.sandia.gov/~kmorel/documents/ColorMaps/
> >> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
> >
> > Those are good articles. There's a lot of literature on the problems
> > with "jet", and lots of links in the matplotlib issue [1]. For those
> > trying to get up to speed quickly, MathWorks recently put together a
> > nice review of the literature [2]. One particularly striking paper
> > they cite studied a group of medical students and found that (a) they
> > were used to/practiced at using jet, (b) when given a choice of
> > colormaps they said that they preferred jet, (c) they nonetheless made
> > more *medical diagnostic errors* when using jet than with better
> > designed colormaps (Borkin et al, 2011).
> >
> > I won't suggest a specific colormap, but I do propose that whatever we
> > chose satisfy the following criteria:
> >
> > - it should be a sequential colormap, because diverging colormaps are
> > really misleading unless you know where the "center" of the data is,
> > and for a default colormap we generally won't.
> >
> > - it should be perceptually uniform, i.e., human subjective judgements
> > of how far apart nearby colors are should correspond as linearly as
> > possible to the difference between the numerical values they
> > represent, at least locally. There's lots of research on how to
> > measure perceptual distance -- a colleague and I happen to have
> > recently implemented a state-of-the-art model of this for another
> > project, in case anyone wants to play with it [3], or just using
> > good-old-L*a*b* is a reasonable quick-and-dirty approximation.
> >
> > - it should have a perceptually uniform luminance ramp, i.e. if you
> > convert to greyscale it should still be uniform. This is useful both
> > in practical terms (greyscale printers are still a thing!) and because
> > luminance is a very strong and natural cue to magnitude.
> >
> > - it should also have some kind of variation in hue, because hue
> > variation is a really helpful additional cue to perception, having two
> > cues is better than one, and there's no reason not to do it.
> >
> > - the hue variation should be chosen to produce reasonable results
> > even for viewers with the more common types of colorblindness. (Which
> > rules out things like red-to-green.)
> >
> > And, for bonus points, it would be nice to choose a hue ramp that
> > still works if you throw away the luminance variation, because then we
> > could use the version with varying luminance for 2d plots, and the
> > version with just hue variation for 3d plots. (In 3d plots you really
> > want to reserve the luminance channel for lighting/shading, because
> > your brain is *really* good at extracting 3d shape from luminance
> > variation. If the 3d surface itself has massively varying luminance
> > then this screws up the ability to see shape.)
> >
> > Do these seem like good requirements?
>
> Goals, yes, though I wouldn't put much weight on the "bonus" criterion.
>   I would add that it should be aesthetically pleasing, or at least
> comfortable, to most people.  Perfection might not be attainable, and
> some tradeoffs may be required. Is anyone set up to produce test images
> and/or metrics for judging existing colormaps, or newly designed ones,
> on all of these criteria?
>
> Eric
>
> >
> > -n
> >
> > [1] https://github.com/matplotlib/matplotlib/issues/875
> > [2]
> http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
> > [3] https://github.com/njsmith/pycam02ucs ; install (or just run out
> > of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
> > the perceptual distance between two RGB colors. It's also possible to
> > use the underlying color m

Re: [matplotlib-devel] release strategy and the color revolution

[gary ruben]

Just wondering whether anyone has suggested checking candidate colormaps
against typical printer color gamuts?
On 6 Apr 2015 1:11 pm, "Eric Firing"  wrote:

> On 2015/04/04 10:10 PM, Nathaniel Smith wrote:
>
>> We'd welcome any feedback from readers with non-simulated color
>> deficiency!
>>
>
> I checked with my red-green color-blind colleague, Niklas Schneider, and
> his evaluation is attached.
>
> Eric
>
>
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy and the color revolution

[gary ruben]

I guess you could just load some test patterns into any commercial software
graphics or design package that supports color gamut alarms, and try some
typical printer settings to make sure that the candidate color maps aren't
excessively blowing the boundaries. I'm not advocating that the default
color map needs to be perfectly reproducible in print, but it might be
worth sanity checking this; it might mean avoiding bright greens and
yellows for example. I see that PIL/pillow contains littlecms support and I
see its ImageCms.py file contains a GAMUTCHECK flag, so it might be
possible to use that, along with some common icc profiles to automate the
checking, or build it into an optimiser as a constraint.

On 6 April 2015 at 15:57, Nathaniel Smith  wrote:

> On Apr 5, 2015 8:29 PM, "gary ruben"  wrote:
> >
> > Just wondering whether anyone has suggested checking candidate colormaps
> against typical printer color gamuts?
>
> How would you go about doing this in practice? Is it even possible to
> choose a subset of sRGB space and have printers take advantage of that when
> doing gamut mapping? (I guess I always assumed that printer gamut mapping
> applied to an RGB image would map all of RGB into their gamut, so there
> would be no advantage to restricting oneself go a subspace. But maybe I'm
> wrong -- color management is pretty fancy these days.)
>
> -n
>
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Moving color overhaul forward

[gary ruben]

It's good to hear Stefan is working on circular colormaps as the hsv
colormap is way too saturated, ignoring any perceptual aspects. For this,
it might be possible to provide some sort of saturation parameter in a
function along the lines of the parameters in the cubehelix function? Also,
sympy/mpmath's cplot function allows you to modulate the
nominally-perceptually-flat hsv map with a value-related function, which
they take as the absolute value of the function, but ideally it would be
any function or array that could ideally be passed in as a parameter. I
have plotted images like this in the past, where I was plotting the phase
of a complex number field but only wanted to use the envelope of the
overall function to control the saturation so you could see the structure
near the singularities but the brightness would fall off in the outer parts
of the image.

Gary R

On 10 June 2015 at 09:17, Thomas Caswell  wrote:

> Hey all,
>
> Today we had a phone call with myself, Eric Firing, Micheal
> Droettboom, Stéfan van der Walt, and Nathaniel Smith to discuss the path
> forward for the changes to the default color map / style.  The notes are
> below:
>
>  - re-order feature release/style change if needed
>- can focus sprint effort at scipy on new features
>- release order may be 2.0 -> 2.1 or 1.5 -> 2.0
>  - keep style change-only release plan
>  - start adding color maps as named maps on master
>  - color map
>- D seems to be leader, maybe variation on theme
>- stefan is working on circular color maps
>  - other style changes
>- adopt most of seaborn as defaults ?
>- start putting in style sheets as soon as possible
>- may not be worth big drawn out decision, just change them
>- line color cycle
>  - need to do something, maybe related to circular color maps
>  - use something from seaborn
>  - get time for style BoF at scipy
>
> Any feed back is welcome.
>
> Tom
>
>
>
> --
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel