[Matplotlib-users] imshow size limitations?
Hi! I'm trying to display a 10800 x 8100 pixel image w/ imshow using the
following code (adapted from a response to a previous post of mine):
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
fig = Figure(figsize=(36,27),
dpi=300,
frameon=False)
canvas = FigureCanvas(fig)
ax = fig.add_subplot(111, xticks=[], yticks=[])
cmap = MPL.cm.get_cmap('prism_r')
ax.imshow(result, cmap=cmap)
canvas.print_figure('HiResHex')
I get the following error report:
Traceback (most recent call last):
File "Hex.py", line 208, in
canvas.print_figure('HiResHex')
File "C:\python25\lib\site-packages\matplotlib\backend_bases.py", line 1201, i
n print_figure
self.figure.canvas.draw()
File "C:\python25\lib\site-packages\matplotlib\backends\backend_agg.py", line
358, in draw
self.figure.draw(self.renderer)
File "C:\python25\lib\site-packages\matplotlib\figure.py", line 624, in draw
for a in self.axes: a.draw(renderer)
File "C:\python25\lib\site-packages\matplotlib\axes.py", line 1305, in draw
for im in self.images if im.get_visible()]
File "C:\python25\lib\site-packages\matplotlib\image.py", line 131, in make_im
age
x = self.to_rgba(self._A, self._alpha)
File "C:\python25\lib\site-packages\matplotlib\cm.py", line 75, in to_rgba
x = self.norm(x)
File "C:\python25\lib\site-packages\matplotlib\colors.py", line 593, in __call
__
val = ma.asarray(value).astype(npy.float)
File "C:\python25\lib\site-packages\numpy\core\ma.py", line 1151, in astype
d = self._data.astype(tc)
MemoryError
Is there some maximum number of pixels imshow can handle? Any other
suggestions?
Platform Details: MPL 0.91.2 (sorry, I didn't realize I was running such an old
version, maybe I just need to upgrade?), Python 2.5.2, Windows XP 2002 SP3,
504MB physical RAM, 1294MB VM Page size (1000MB init., 5000MB max)
Thanks!
DG
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] imshow size limitations?
Oh, forgot to mention: same code works fine on a smaller (fewer pixels) image.
DG
--- On Sat, 9/6/08, David Goldsmith <[EMAIL PROTECTED]> wrote:
> From: David Goldsmith <[EMAIL PROTECTED]>
> Subject: [Matplotlib-users] imshow size limitations?
> To: matplotlib-users@lists.sourceforge.net
> Date: Saturday, September 6, 2008, 10:46 AM
> Hi! I'm trying to display a 10800 x 8100 pixel image w/
> imshow using the following code (adapted from a response to
> a previous post of mine):
>
> from matplotlib.backends.backend_agg import FigureCanvasAgg
> as FigureCanvas
> from matplotlib.figure import Figure
>
> fig = Figure(figsize=(36,27),
> dpi=300,
> frameon=False)
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(111, xticks=[], yticks=[])
> cmap = MPL.cm.get_cmap('prism_r')
> ax.imshow(result, cmap=cmap)
> canvas.print_figure('HiResHex')
>
> I get the following error report:
>
> Traceback (most recent call last):
> File "Hex.py", line 208, in
> canvas.print_figure('HiResHex')
> File
> "C:\python25\lib\site-packages\matplotlib\backend_bases.py",
> line 1201, i
> n print_figure
> self.figure.canvas.draw()
> File
> "C:\python25\lib\site-packages\matplotlib\backends\backend_agg.py",
> line
> 358, in draw
> self.figure.draw(self.renderer)
> File
> "C:\python25\lib\site-packages\matplotlib\figure.py",
> line 624, in draw
> for a in self.axes: a.draw(renderer)
> File
> "C:\python25\lib\site-packages\matplotlib\axes.py",
> line 1305, in draw
> for im in self.images if im.get_visible()]
> File
> "C:\python25\lib\site-packages\matplotlib\image.py",
> line 131, in make_im
> age
> x = self.to_rgba(self._A, self._alpha)
> File
> "C:\python25\lib\site-packages\matplotlib\cm.py",
> line 75, in to_rgba
> x = self.norm(x)
> File
> "C:\python25\lib\site-packages\matplotlib\colors.py",
> line 593, in __call
> __
> val = ma.asarray(value).astype(npy.float)
> File
> "C:\python25\lib\site-packages\numpy\core\ma.py",
> line 1151, in astype
> d = self._data.astype(tc)
> MemoryError
>
> Is there some maximum number of pixels imshow can handle?
> Any other suggestions?
>
> Platform Details: MPL 0.91.2 (sorry, I didn't realize I
> was running such an old version, maybe I just need to
> upgrade?), Python 2.5.2, Windows XP 2002 SP3, 504MB physical
> RAM, 1294MB VM Page size (1000MB init., 5000MB max)
>
> Thanks!
>
> DG
>
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] imshow size limitations?
David Goldsmith wrote:
> Hi! I'm trying to display a 10800 x 8100 pixel image w/ imshow using the
> following code (adapted from a response to a previous post of mine):
>
> from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
> from matplotlib.figure import Figure
>
> fig = Figure(figsize=(36,27),
> dpi=300,
> frameon=False)
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(111, xticks=[], yticks=[])
> cmap = MPL.cm.get_cmap('prism_r')
> ax.imshow(result, cmap=cmap)
> canvas.print_figure('HiResHex')
>
> I get the following error report:
>
> Traceback (most recent call last):
> File "Hex.py", line 208, in
> canvas.print_figure('HiResHex')
> File "C:\python25\lib\site-packages\matplotlib\backend_bases.py", line
> 1201, i
> n print_figure
> self.figure.canvas.draw()
> File "C:\python25\lib\site-packages\matplotlib\backends\backend_agg.py",
> line
> 358, in draw
> self.figure.draw(self.renderer)
> File "C:\python25\lib\site-packages\matplotlib\figure.py", line 624, in draw
> for a in self.axes: a.draw(renderer)
> File "C:\python25\lib\site-packages\matplotlib\axes.py", line 1305, in draw
> for im in self.images if im.get_visible()]
> File "C:\python25\lib\site-packages\matplotlib\image.py", line 131, in
> make_im
> age
> x = self.to_rgba(self._A, self._alpha)
> File "C:\python25\lib\site-packages\matplotlib\cm.py", line 75, in to_rgba
> x = self.norm(x)
> File "C:\python25\lib\site-packages\matplotlib\colors.py", line 593, in
> __call
> __
> val = ma.asarray(value).astype(npy.float)
> File "C:\python25\lib\site-packages\numpy\core\ma.py", line 1151, in astype
> d = self._data.astype(tc)
> MemoryError
>
> Is there some maximum number of pixels imshow can handle? Any other
> suggestions?
David,
It looks to me like you simply ran out of memory--this is not an imshow
problem as such. Your array is about 1e8 elements, and as floats that
would be close to a GB--just for that array alone. Do you really need
all that resolution? If you do, you will probably have to get a much
more capable machine. Otherwise, you need to knock down the size of
that array before trying to plot or otherwise manipulate it.
With respect to imshow, probably you can get it to handle larger images
if you feed them in as NxMx4 numpy.uint8 RGBA arrays--but I doubt this
is going to be enough, or the right approach, for your present situation.
Eric
>
> Platform Details: MPL 0.91.2 (sorry, I didn't realize I was running such an
> old version, maybe I just need to upgrade?), Python 2.5.2, Windows XP 2002
> SP3, 504MB physical RAM, 1294MB VM Page size (1000MB init., 5000MB max)
>
> Thanks!
>
> DG
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] imshow size limitations?
Thanks, Eric!
--- On Sat, 9/6/08, Eric Firing <[EMAIL PROTECTED]> wrote:
-- snip OP --
> It looks to me like you simply ran out of memory--this is
> not an imshow
> problem as such. Your array is about 1e8 elements, and as
> floats that
> would be close to a GB--just for that array alone. Do you
Well, I anticipated that, so I do initialize the storage for the numpy array as
numpy.uint8 and have confirmed that the data in the array returned by the
function which creates it remains numpy.uint8, so it should "only" be ~100MB
(indeed, the .na file into which I tofile it is 85,430 KB, just as it should be
for a 10800 x 8100 array of uint8 elements). And the ax.imshow statement
doesn't (directly) cause the crash (but I don't know that it isn't making
either a float copy or an in-place conversion of the array). So, AFAIK, right
up until the statement:
canvas.print_figure('HiResHex')
the data being imaged are all numpy.uint8 type.
> really need
> all that resolution?
Well, there's the rub: I fancy myself a fractal "artist" and I have access to
an HP DesignJet 500ps plotter with a maximum resolution of 1200 x 600 dpi. For
the size images I'm trying to make (I'm hoping to go even bigger than 36" x
27", but I figured that as a good starting point) even I regard _that_
resolution as too much - I was thinking of 300 x 300 dpi (which is its "normal"
resolution) as certainly worthy of giving a try. :-)
> If you do, you will probably have to
> get a much
> more capable machine.
Possible, but I was hoping to generate at least one "proof" first to determine
how hard I'd need to try.
> Otherwise, you need to knock down
> the size of
> that array before trying to plot or otherwise manipulate
> it.
Forgive me, but I'd like a more detailed explanation as to why: I have ample
(~35 GB, just on my built-in disc, much more than that on external discs)
harddisc space - isn't there some way to leverage that?
> With respect to imshow, probably you can get it to handle
> larger images
Again, imshow doesn't appear to be the culprit (contrary to my original subject
line), rather it would appear to be canvas.print_figure. (While I'm on the
subject of canvas.print_figure, isn't there some way for MPL to "splash" the
image directly to the screen, without first having to write to a file? I
didn't ask this before because I did eventually want to write the image to a
file, but I would prefer to do so only after I've had a look at it.)
> if you feed them in as NxMx4 numpy.uint8 RGBA arrays--but I
> doubt this
> is going to be enough, or the right approach, for your
> present situation.
Right: I don't see how that would be better than having a single 8 bit datum at
each point w/ color being determined from a color map (which is how I'd prefer
to do it anyway).
Thanks again,
DG
>
> Eric
>
> >
> > Platform Details: MPL 0.91.2 (sorry, I didn't
> realize I was running such an old version, maybe I just need
> to upgrade?), Python 2.5.2, Windows XP 2002 SP3, 504MB
> physical RAM, 1294MB VM Page size (1000MB init., 5000MB max)
> >
> > Thanks!
> >
> > DG
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plot star instead of pentagram
dmitrey wrote: > hi all, > matplotlib says it's similar to MATLAB's plot tool, however, using > plot(..., 'p') plots pentagram instead of star. It makes my (Python > scikits.openopt) graphic output of numerical convergence look uglier > than MATLAB version. > > So is plotting a star intended to be ever implemented? Dmitrey, It was easy, so I added a 5-point star to the set of available markers in svn. Use plot(..., '*'). 'p' was already taken, and '*' seems more mnemonic--I would never think of 'p' as indicating a star. Eric > Thank you in advance, Dmitrey - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] imshow size limitations?
David Goldsmith wrote:
> Thanks, Eric!
>
> --- On Sat, 9/6/08, Eric Firing <[EMAIL PROTECTED]> wrote:
>
> -- snip OP --
>
>> It looks to me like you simply ran out of memory--this is
>> not an imshow
>> problem as such. Your array is about 1e8 elements, and as
>> floats that
>> would be close to a GB--just for that array alone. Do you
>
> Well, I anticipated that, so I do initialize the storage for the numpy array
> as numpy.uint8 and have confirmed that the data in the array returned by the
> function which creates it remains numpy.uint8, so it should "only" be ~100MB
> (indeed, the .na file into which I tofile it is 85,430 KB, just as it should
> be for a 10800 x 8100 array of uint8 elements). And the ax.imshow statement
> doesn't (directly) cause the crash (but I don't know that it isn't making
> either a float copy or an in-place conversion of the array). So, AFAIK,
> right up until the statement:
>
> canvas.print_figure('HiResHex')
>
> the data being imaged are all numpy.uint8 type.
Yes, but it looks to me like they are still getting color-mapped, and
this requires conversion to numpy.float. This may be a bad aspect of
the mpl design, but it is quite deeply embedded. I suspect the best we
could do would be to use float32 instead of float64; certainly for color
mapping one does not need 64 bits.
Using numpy.uint8 helps only if you are specifying RGBA directly,
bypassing the colormapping.
>
>> really need
>> all that resolution?
>
> Well, there's the rub: I fancy myself a fractal "artist" and I have
> access to an HP DesignJet 500ps plotter with a maximum resolution of
> 1200 x 600 dpi. For the size images I'm trying to make (I'm hoping to go
> even bigger than 36" x 27", but I figured that as a good starting point)
> even I regard _that_ resolution as too much - I was thinking of 300 x
> 300 dpi (which is its "normal" resolution) as certainly worthy of giving
> a try. :-)
>> If you do, you will probably have to
>> get a much
>> more capable machine.
>
> Possible, but I was hoping to generate at least one "proof" first to
> determine how hard I'd need to try.
>
>> Otherwise, you need to knock down
>> the size of
>> that array before trying to plot or otherwise manipulate
>> it.
>
> Forgive me, but I'd like a more detailed explanation as to why: I
> have
> ample (~35 GB, just on my built-in disc, much more than that on external
> discs) harddisc space - isn't there some way to leverage that?
I don't know enough about virtual memory implementations--especially on
Win or Mac--to say. In practice, I suspect you would find that as soon
as you are doing major swapping during a calculation, you will thrash
the disk until you run out of patience.
>> With respect to imshow, probably you can get it to handle
>> larger images
>
> Again, imshow doesn't appear to be the culprit (contrary to my
> original subject line), rather it would appear to be
> canvas.print_figure. (While I'm on the subject of canvas.print_figure,
> isn't there some way for MPL to "splash" the image directly to the
> screen, without first having to write to a file? I didn't ask this
> before because I did eventually want to write the image to a file, but I
> would prefer to do so only after I've had a look at it.)
It is imshow in the sense that most of the action in mpl doesn't happen
when you call imshow or plot or whatever--they just set things up. The
real work is done in the backend when you display with show() or write
to a file.
>> if you feed them in as NxMx4 numpy.uint8 RGBA arrays--but I
>> doubt this
>> is going to be enough, or the right approach, for your
>> present situation.
>
> Right: I don't see how that would be better than having a single 8
> bit
> datum at each point w/ color being determined from a color map (which is
> how I'd prefer to do it anyway).
The way it is better is that it avoids a major operation, including the
generation of the double-precision array. The rgba array can go
straight to agg.
Eric
> Thanks again,
>
> DG
>> Eric
>>
>>> Platform Details: MPL 0.91.2 (sorry, I didn't
>> realize I was running such an old version, maybe I just need
>> to upgrade?), Python 2.5.2, Windows XP 2002 SP3, 504MB
>> physical RAM, 1294MB VM Page size (1000MB init., 5000MB max)
>>> Thanks!
>>>
>>> DG
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] imshow size limitations?
Ah, Ich verstehe now. I'll try RGBA-ing it; in the meantime, let me know if
the colormapping conversion gets changed to 32 bit. Thanks again!
DG
--- On Sat, 9/6/08, Eric Firing <[EMAIL PROTECTED]> wrote:
> From: Eric Firing <[EMAIL PROTECTED]>
> Subject: Re: [Matplotlib-users] imshow size limitations?
> To: [EMAIL PROTECTED]
> Cc: matplotlib-users@lists.sourceforge.net
> Date: Saturday, September 6, 2008, 3:13 PM
> David Goldsmith wrote:
> > Thanks, Eric!
> >
> > --- On Sat, 9/6/08, Eric Firing
> <[EMAIL PROTECTED]> wrote:
> >
> > -- snip OP --
> >
> >> It looks to me like you simply ran out of
> memory--this is
> >> not an imshow
> >> problem as such. Your array is about 1e8
> elements, and as
> >> floats that
> >> would be close to a GB--just for that array alone.
> Do you
> >
> > Well, I anticipated that, so I do initialize the
> storage for the numpy array as numpy.uint8 and have
> confirmed that the data in the array returned by the
> function which creates it remains numpy.uint8, so it should
> "only" be ~100MB (indeed, the .na file into which
> I tofile it is 85,430 KB, just as it should be for a 10800 x
> 8100 array of uint8 elements). And the ax.imshow statement
> doesn't (directly) cause the crash (but I don't know
> that it isn't making either a float copy or an in-place
> conversion of the array). So, AFAIK, right up until the
> statement:
> >
> > canvas.print_figure('HiResHex')
> >
> > the data being imaged are all numpy.uint8 type.
>
> Yes, but it looks to me like they are still getting
> color-mapped, and
> this requires conversion to numpy.float. This may be a bad
> aspect of
> the mpl design, but it is quite deeply embedded. I suspect
> the best we
> could do would be to use float32 instead of float64;
> certainly for color
> mapping one does not need 64 bits.
>
> Using numpy.uint8 helps only if you are specifying RGBA
> directly,
> bypassing the colormapping.
>
> >
> >> really need
> >> all that resolution?
> >
> > Well, there's the rub: I fancy myself a fractal
> "artist" and I have
> > access to an HP DesignJet 500ps plotter with a maximum
> resolution of
> > 1200 x 600 dpi. For the size images I'm trying to
> make (I'm hoping to go
> > even bigger than 36" x 27", but I figured
> that as a good starting point)
> > even I regard _that_ resolution as too much - I was
> thinking of 300 x
> > 300 dpi (which is its "normal" resolution)
> as certainly worthy of giving
> > a try. :-)
>
> >> If you do, you will probably have to
> >> get a much
> >> more capable machine.
> >
> > Possible, but I was hoping to generate at least one
> "proof" first to determine how hard I'd need
> to try.
> >
> >> Otherwise, you need to knock down
> >> the size of
> >> that array before trying to plot or otherwise
> manipulate
> >> it.
> >
> > Forgive me, but I'd like a more detailed
> explanation as to why: I
> > have
> > ample (~35 GB, just on my built-in disc, much more
> than that on external
> > discs) harddisc space - isn't there some way to
> leverage that?
>
> I don't know enough about virtual memory
> implementations--especially on
> Win or Mac--to say. In practice, I suspect you would find
> that as soon
> as you are doing major swapping during a calculation, you
> will thrash
> the disk until you run out of patience.
>
>
> >> With respect to imshow, probably you can get it to
> handle
> >> larger images
> >
> > Again, imshow doesn't appear to be the culprit
> (contrary to my
> > original subject line), rather it would appear to be
> > canvas.print_figure. (While I'm on the subject of
> canvas.print_figure,
> > isn't there some way for MPL to "splash"
> the image directly to the
> > screen, without first having to write to a file? I
> didn't ask this
> > before because I did eventually want to write the
> image to a file, but I
> > would prefer to do so only after I've had a look
> at it.)
>
> It is imshow in the sense that most of the action in mpl
> doesn't happen
> when you call imshow or plot or whatever--they just set
> things up. The
> real work is done in the backend when you display with
> show() or write
> to a file.
>
>
> >> if you feed them in as NxMx4 numpy.uint8 RGBA
> arrays--but I
> >> doubt this
> >> is going to be enough, or the right approach, for
> your
> >> present situation.
> >
> > Right: I don't see how that would be better than
> having a single 8
> > bit
> > datum at each point w/ color being determined from a
> color map (which is
> > how I'd prefer to do it anyway).
>
> The way it is better is that it avoids a major operation,
> including the
> generation of the double-precision array. The rgba array
> can go
> straight to agg.
>
> Eric
>
>
> > Thanks again,
> >
> > DG
> >> Eric
> >>
> >>> Platform Details: MPL 0.91.2 (sorry, I
> didn't
> >> realize I was running such an old version, maybe I
> just need
> >> to upgrade?), Python 2.5.2, Windows XP 2002 SP3,
> 504MB
> >> physical RAM, 1294MB VM Page size (1000MB in
