I tried to open a 4800x3600 24bit PNG file, but it made Pd crash/suddenly quit.
$ cat /home/claude/.pdrc -verbose -jack -noadc -audiobuf 2 -blocksize 64 -sleepgrain 10 -midiindev 1 -midioutdev 1 -path /home/claude/claudiusmaximus -lib /home/claude/public/development/pure-data-devel/pd/externals/gridflow-lib/gridflow -path /home/claude/public/development/pure-data-devel/pd/externals/gridflow-abstractions -lib /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iemlib1 -lib /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iemlib2 -lib /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iem_mp3 -lib /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iem_t3_lib -path /home/claude/public/development/pure-data-devel/pd/externals/iem-abstractions
$ /home/claude/public/development/pure-data-devel/pd/bin/pd reading startup file: /home/claude/.pdrc sys_audioapi 5 Pd version 0.37.1 devel compiled 19:56:47 Jul 10 2004 port 5400 Waiting for connection request... TCL_LIBRARY="/home/claude/public/development/pure-data-devel/pd/tcl/library" TK_LIBRARY="/home/claude/public/development/pure-data-devel/pd/tk/library" "/home/claude/public/development/pure-data-devel/pd/bin/pd-gui" 5400 ... connected pd_startgui : updater thread 16386 launched global soundfiler thread launched, priority: 0 Soundfiler sleeping device 1: tried /dev/midi READ/WRITE; returned -1 device 0: tried /dev/midi00 READ/WRITE; returned 7 opened 1 MIDI input device(s) and 1 MIDI output device(s). input channels = 0, output channels = 2 tried /home/claude/public/development/pure-data-devel/pd/externals/gridflow-lib/gridflow.pd_linux and succeeded setting up Ruby-for-PureData... (done) [gf] This is GridFlow 0.7.6 within Ruby version 1.8.1 [gf] base/main.c was compiled on Jul 10 2004, 22:03:57 [gf] startup_cpu: using MMX optimisations tried /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iemlib1.pd_linux and succeeded iemlib1 (R-1.15) library loaded! tried /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iemlib2.pd_linux and succeeded iemlib2 (R-1.15) library loaded! tried /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iem_mp3.pd_linux and succeeded iem_mp3 (R-1.15) library loaded! tried /home/claude/public/development/pure-data-devel/pd/externals/iem-lib/iem_t3_lib.pd_linux and succeeded iem_t3_lib (R-1.15) library loaded!
here I load my patch, the relevant connections are:
[bng]
|
[openpanel]
|
[open $1, bang(
|
[@store]
Pd: signal 6 socket receive error: Connection reset by peer (104)
...no more Pd.
A nicer error message would be, well, nice, and not aborting instantly would be even nicer.
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?
Simple solution for now - resize source image to something that fits in memory.
Ideal solution - lots and lots of RAM.
Anyone wanna donate me some memory modules - it was my birthday on Monday, call it a late present! ;-)
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