[PD] Gridflow [open largefile.png, bang(-->[@in] crashes Pd

[Mathieu Bouchard]

On Wed, 21 Jul 2004, ClaudiusMaximus wrote:

> I tried to open a 4800x3600 24bit PNG file, but it made Pd
> crash/suddenly quit.
> I click the [bng], select my 4800x3600 24bit PNG file and...
> ...no more Pd.
> A nicer error message would be, well, nice, and not aborting instantly
> would be even nicer.

On Out-of-memory errors GridFlow doesn't do anything nice. On other kinds
of errors it's supposed to behave better. I think the crash is because C++
doesn't like to allocate a single 197M memory region. However it can
allocate many smaller (eg 66M) regions.

I presume that whenever I integrate C++'s exceptions with Ruby exceptions
you'll get nicer error messages for that case.

> I guess this is because...
> 4800 * 3600 * 3 (channels) * 4 (grids are int32 by default) ~=~ 200MB 
> ...and I only have 256MB RAM.
> Is there any way to load the image directly into a (H,W,3)(uint8) grid?
> And would [@store] store it like that?

Send a "cast uint8" to [@in] before banging it.

[open largefile.png, cast uint8, bang(
 |
[@in]

The [@store] object stores it exactly as that number type. Any conversions
are explicit. The big problem with non-int32 number types is that you have
to write the number type in a lot of places _because_ all conversions are
explicit.

(I have yet to figure out a satisfying way of making conversions implicit)

[@out] accepts uint8's directly (well, most output handlers do...). If you
want to make smaller images you can use [@downscale_by] or the pixel
selection features of [@store] (together with [@for])

> Anyone wanna donate me some memory modules - it was my birthday on
> Monday, call it a late present! ;-)

I think it won't help because I have enough RAM (512M plus an even bigger
swap) and still GLIBC (or LIBC++) doesn't want to allocate 197M in one
shot.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju