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

Reply via email to