matplotlib-users Mailing List for matplotlib

Gregor Thalhammer wrote:
> Tobias Wood
> [...]
[...]
> I also noticed you used C++ constructs in your code. I think this is not 
> recommended.

Gregor,

Would you elaborate, please, to satisfy my curiosity?  The original file 
is C++, so use of C++ constructs in the patch would seem natural.

Thank you.

Eric

Tobias Wood
[...]
> These have thrown up an interesting issue - to what maximum value 
> should n-bit images be scaled when n is between 8 and 16? The png spec 
> and test images suggest it should be (2^n - 1). This means that higher 
> bit depths give higher precision over the same intensity range and the 
> same maximum value. However for my particular camera and software this 
> would be wrong, as the CCD has a fixed 12-bit dynamic range and the 
> lower png bit depths are only used to save file space. Hence at the 
> moment I have set my software to scale to (2^16 - 1) for 8 < n < 16, 
> but it follows the png spec for n < 8, so there are two contradictory 
> behaviours and I am unsure which is the best approach. Personally I 
> would prefer matplotlib to return raw integer values, not floats 
> scaled between 0 and 1 and then I can apply the scaling myself, but I 
> am aware that this is not particularly user friendly for anyone else. 
> imshow() seems to handle integer values fine and correctly scales for 
> display, provided that no alpha channel is present.
In the past I worked on a similar problem, saving and loading images 
from a 14bit monochrome CCD camera to a PNG file. The PNG specification 
gives precise recommondations how to handle such a case: for saving an 
n-bit image which is not directly supported by the PNG specs the image 
needs to be scaled up to one of the supported bit depths, i.e. 1,2,4,8 
or 16. The original bit depth should be stored in the sBIT chunk to 
recover the original data. Explicitely, a 12 bit image needs to be 
scaled by a factor (2^16 - 1)/(2^12-1).
The approach I have chosen is: I have png_save_image(filename, img, 
significant_bits) that behaves as specified in the specs, i.e., 14bit 
images are scaled up to 16bit. For loading an image I use img, metadata 
= png_load_image(filename) that returns the downscaled image  as an 
integer array and a dict containing some metadata (which includes the 
original bit depth). I also noticed that neither pnglib, PIL nor matlab 
perform this downscaling. With this approach the loaded image data is 
identical to the original raw image. For further processing I typically 
normalize the image to the range 0 to 1.0, using the bit depth 
information. A float array is sufficiently precise, also for 16bit 
images. For your enhancements to imread, introducing a new keyword 
'normalized' would allow to switch between both these possibilies.As I 
understand I have essentially chosen the same approach like you, at 
least for bitdepths > 8. I didn't get the point what is different for 
bitdepth s<=8.

Another remark to your first posting: I didn't experience a problem with 
PIL to load 16bit PNG grayscale images.
I also noticed you used C++ constructs in your code. I think this is not 
recommended.

Gregor

On Sat, Apr 4, 2009 at 06:37, C M <cmp...@gm...> wrote:
> I am pretty happy with the default for how dates ticks
> are updated with zooming the plot with the navigation
> toolbar...until it gets down to the level of hours.
>
> Hours are by default displayed in a format like:
> "23:00:00 UTC".  How can I get it to display it in a
> more common way, such as "11:00 pm", or better,
> "11 pm, 3/15"?

something like:

# init figures
fig = figure()
ax = fig.add_subplot(111)
# plot the lines
ax.plot_date(...)
# x data (dates) formatter
ax.xaxis.set_major_formatter( DateFormatter('PUT YOUR FORMAT HERE') )

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

> Tobias,
>
> I would like to apply your patch, but the test in
> examples/tests/pngsuite fails. If you can submit a new patch where this
> test passes, and, even better, if a small example 12-bit PNG of yours is
> added to the test, I will apply it.
>
> Apart from that, I would echo Eric's thanks for the patch and  
> explanation.
>
> -Andrew

Hi Andrew and Eric,
Thanks for the responses. I was unaware of the png test suite. I have  
attached a new diff that passes this test correctly. It originally failed  
because I was not handling greyscale images with an alpha channel, but it  
also brought to light several other issues with my code that I have fixed.  
I have changed the structure of the code significantly - the if/else  
struct has gone and a single loop returns the different image matrices.  
Although this is more concise, it no longer informs the user if it hits an  
unsupported image type.

Unfortunately I do not have a small test image available, all of ours are  
a minimum of 512x620. However the pngsuite page,  
http://libpng.org/pub/png/pngsuite.html, does have a set of suitable  
images labelled cs*n*.png. These have thrown up an interesting issue - to  
what maximum value should n-bit images be scaled when n is between 8 and  
16? The png spec and test images suggest it should be (2^n - 1). This  
means that higher bit depths give higher precision over the same intensity  
range and the same maximum value. However for my particular camera and  
software this would be wrong, as the CCD has a fixed 12-bit dynamic range  
and the lower png bit depths are only used to save file space. Hence at  
the moment I have set my software to scale to (2^16 - 1) for 8 < n < 16,  
but it follows the png spec for n < 8, so there are two contradictory  
behaviours and I am unsure which is the best approach. Personally I would  
prefer matplotlib to return raw integer values, not floats scaled between  
0 and 1 and then I can apply the scaling myself, but I am aware that this  
is not particularly user friendly for anyone else. imshow() seems to  
handle integer values fine and correctly scales for display, provided that  
no alpha channel is present.

Should I post another message to the developer list about this to see what  
people think? I'd very much like to discuss this with someone who has a  
lot more experience of pngs than me.

Thanks,
Tobias

Careful, "reply" doesn't send your note to the list.

I just looked on the MPl download page in source forge. It looks like 
there are binary eggs there for Windows. You should be able to install 
those in your virtualenv and have it all just work. Just make sure you 
use the right copy of easy_install

-Chris

R. Haynie wrote:
> Christopher Barker wrote:
>> R. Haynie wrote:
>>   
>>> I am using VirtualEnv to have multiple virtual environments that have
>>> their own site-packages folder.  So each environment is its own sandbox.
>>>     
>> another reason why core python really needs to have an "official" 
>> versioning system - either something like virtualenv, or (my 
>> preference), package versioning built in.
>>
>> Anyway, in the mean time, two ideas to try:
>>
>> 1) "easxy_install matplotlib" run with the easy_install in your virtual 
>> env -- hopefully, it will install a binary Windows egg -- does one exist?
>>
>>   
> Tried this towards the end of 2008 a few times, did not fair well at all
> in Windows.
> 
>> 2) try manually moving the matplotlib package from the system 
>> site-packages to your virtualenv.
>>
>> Ok, this is what I tried today:
>>   
> Uninstalled any python package I had installed with a windows installer,
> uninstalled all of python, and cleared the cache folder, deleted
> python25 folder.
> Installed python 2.5 with windows installer.
> Took note of what was in site-packages.
> Ran NumPy windows installer, and moved all new files and folders out of
> Site-Packages.  Moved them to a folder I named c:\site-packages_NumPy.
> Did the same for MatPlotLib windows installer.  Moved them to a folder I
> named c:\site-packages_MatPlotLib.
> Got real anal here and uninstalled numpy and matplotlib using the
> windows uninstallers.  Then uninstalled Python and cleared the cache
> folder and deleted python25.
> 
> Now this is where I thought I could go and make some nice virtual
> environments and have some safe sandboxes.  But of course not.
> Installed python, easy_install, virtualenv, pywin32.
> Created new virtual environment and activated it.  Copied the files from
> the numpy and matplotlib site-packages folders into the new virtual
> environment site-packages folder.
> Tryed a simple plot, and got an error that pylab module did not exist.
> So, I figured that the windows installers did more than met the eye. 
> They probably install some DLLs etc.
> I then installed numpy and matplotlib using the windows installers.
> Tried my plot test from within the virtual environment and it worked.
> 
> I created a new virtual environment, installed nothing, tried the plot
> test from within that environment and the test worked.  It should not
> have worked.
> 
> Looks like I can only have 1 numpy and 1 matplotlib on a windows box at
> a time, virtual environments or not.
> 
> 
>> Let us know how it works out...
>>
>>   
> I sure hope someone reads this and finds something glaringly wrong with
> my process.
> 


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Thomas Robitaille wrote:
> Hi,
> 
> I've found that the match_original=True option in PatchCollection  
> causes matplotlib to crash. I have submitted two bug reports:
> 
> https://sourceforge.net/tracker/?func=detail&aid=2732455&group_id=80706&atid=560720
> https://sourceforge.net/tracker/?func=detail&aid=2723527&group_id=80706&atid=560720

Both are now fixed in the 0.98.5 maintenance branch and in the trunk.

Eric

Thomas Robitaille wrote:
> Hi,
> 
> I've found that the match_original=True option in PatchCollection  
> causes matplotlib to crash. I have submitted two bug reports:
> 
> https://sourceforge.net/tracker/?func=detail&aid=2732455&group_id=80706&atid=560720
> https://sourceforge.net/tracker/?func=detail&aid=2723527&group_id=80706&atid=560720
> 
> I was wondering whether these are problems that other people have  
> encountered too? (description in the bug reports)

Maybe not, but they are certainly bugs.  I have fixed the first and am 
looking at the new one, so I hope both will be resolved shortly.

Eric

> 
> Thanks,
> 
> Thomas
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Cohen-Tanugi Johann wrote:
> indeed, I obviously just got entangled in my own debugging. I do manage 
> to get it to do what I want now.
> 
> sorry for the fuss,
> Johann

No problem at all.  I'm glad things are working for you.

Eric

indeed, I obviously just got entangled in my own debugging. I do manage 
to get it to do what I want now.

sorry for the fuss,
Johann

Eric Firing wrote:
> Cohen-Tanugi Johann wrote:
>> ok, maybe it is in scale.py :)
>> And what I see there confirms my initial fears : the log scale 
>> transform applies a log to the argument, which is incorrect for an 
>> error..... So first of all, another transform needs to be created so 
>> that erry is transformed into erry/y/log(base) where base was 10 in 
>> my example.
>
> Johann,
>
> I don't understand your objection here.  It seems to me that an 
> errorbar  should always be in the same units, and on the same scale, 
> as the point to which it applies.  Therefore when switching from 
> linear to log scales, one simply plots the same data and error ranges 
> on a log scale instead of a linear scale.  This is what mpl does.  If 
> what you want is for the error to be proportional to the value of the 
> point, then you need to specify the error bounds so that they have 
> that property.  For estimation of a power spectrum, for example, this 
> is often the case; the error bars are some fraction (depending on the 
> equivalent number of degrees of freedom) of the spectral level at each 
> frequency, so on a log plot they will have equal length.  It is not 
> the job of the errorbar function to figure that out, however.
>
> If I am misunderstanding, then please provide a very simple concrete 
> example that will make your point clear.
>
>>
>> past midnight here.... I will see tomorrow if I find time to try out 
>> a patch (not the easiest entry point for starting developer's 
>> activities in MPL I am afraid....)
>
> I have just committed a change (trunk r7023) that allows non-positive 
> numbers to be clipped to a small positive value.  To illustrate its 
> use with an errorbar, I added the example provided by Matthias to 
> examples/pylab_examples/log_demo.py, as a 4th subplot.
>
> Eric
>>
>> Johann