You could look at whether or not you actually need 64-bit precision. Often times, 8-bit precision per color channel is justifiable, even in grayscale. My advice is to play with the dtype of your array or, as you mentioned, resample.
thanks, this helped me significantly, uint8 precision is enough.
Also, is it needed to keep all images? It sounds to me like your application will become very resource hungry if you’re going to be displaying several of these 2D images over each other (and if you don’t use transparency, you won’t get any benefit at all from plotting them together).
Yes, I need them all .
To avoid it I am thinking about merging them into one image and then plot it.
Stepan
···
=
I’ve been burned by this before as well. MPL stores some intermediate data products (for example, scaled RGB copies) at full resolution, even though the final rendered image is downsampled depending on screen resolution.
I’ve used some hacky tricks to get around this, which mostly involve downsampling the image on the fly based on screen resolution. One such effort is at https://github.com/ChrisBeaumont/mpl-modest-image.
If you are loading your arrays from disk, you can also use memory-mapped arrays – this prevents you from loading all the data into RAM, and further cuts down on the footprint.
cheers,
chris
···
On Tue, Aug 27, 2013 at 6:49 AM, Štěpán Turek <stepan.turek@…2526…> wrote:
You could look at whether or not you actually need 64-bit precision. Often times, 8-bit precision per color channel is justifiable, even in grayscale. My advice is to play with the dtype of your array or, as you mentioned, resample.
thanks, this helped me significantly, uint8 precision is enough.
Also, is it needed to keep all images? It sounds to me like your application will become very resource hungry if you’re going to be displaying several of these 2D images over each other (and if you don’t use transparency, you won’t get any benefit at all from plotting them together).
Yes, I need them all .
To avoid it I am thinking about merging them into one image and then plot it.
Stepan
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
It looks like this wouldn’t be too hard to include in matplotlib. I
don’t think we’d want to change the current behavior, because
sometimes its tradeoff curve makes sense, but in other cases, the
“modest image” approach also makes sense. It’s just a matter of
coming up with an API to switch between the two behaviors. Pull
request?
Cheers,
Mike
···
On 08/27/2013 09:49 AM, Chris Beaumont
wrote:
I've been burned by this before as well. MPL stores
some intermediate data products (for example, scaled RGB copies)
at full resolution, even though the final rendered image is
downsampled depending on screen resolution.
I've used some hacky tricks to get around this, which
mostly involve downsampling the image on the fly based on
screen resolution. One such effort is at https://github.com/ChrisBeaumont/mpl-modest-image.
If you are loading your arrays from disk, you can also use
memory-mapped arrays – this prevents you from loading all the
data into RAM, and further cuts down on the footprint.
cheers,
chris
On Tue, Aug 27, 2013 at 6:49 AM, Štěpán
Turek <stepan.turek@…2526…>
wrote:
You could look at whether or not you actually
need 64-bit precision. Often times, 8-bit
precision per color channel is justifiable, even
in grayscale. My advice is to play with the dtype
of your array or, as you mentioned, resample.
thanks, this helped me
significantly, uint8 precision is enough.
Also, is it needed to keep all images? It
sounds to me like your application will become
very resource hungry if you’re going to be
displaying several of these 2D images over each
other (and if you don’t use transparency, you
won’t get any benefit at all from plotting them
together).
Yes, I need them all .
To avoid it I am thinking
about merging them into one image and then plot it.
Stepan
Introducing Performance Central, a new site from SourceForge
and
AppDynamics. Performance Central is your source for news,
insights,
analysis and resources for efficient Application Performance
Management.
Visit us today!
[http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk](http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk)
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
[https://lists.sourceforge.net/lists/listinfo/matplotlib-users](https://lists.sourceforge.net/lists/listinfo/matplotlib-users)
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today!
_______________________________________________
Matplotlib-users mailing list
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrkMatplotlib-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-users