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 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
