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
