hi list,
another probably stupid beginner question: as far as i understood the help patches i should use pix_imageInPlace instead of pix_image because of better performance. i do not get the usage of pix_imageInPlace it does not really work for me, where is the problem? I also get these "is not the power of two" errors all the time, although the pictures are all 400 x 400 pixels, what's the reason? it says quite often in the help files that one should use only .tiff files, but .jpg seems to work as well, what about that? i was comparing the performance of LZW compressed tiffs and uncompressed ones, and had the impression that without compression it runs a bit better. do you agree?
so many questions, one patch:
thanks, max
I also get these "is not the power of two" errors all the time, although the pictures are all 400 x 400 pixels, what's the reason?
Try 512*512 (or 256*256) pictures instead, at a guess. I haven't used the object myself, or looked at your patch, maybe this will fix any other problems you have, or maybe I've got the wrong end of the stick completely.
Good luck, any way.
as far as i understood the help patches i should use pix_imageInPlace instead of pix_image because of better performance. i do not get the usage of pix_imageInPlace it does not really work for me, where is the problem?
OK, it looks like [pix_multiimage] works a bit more like [pix_image], only without the need to load them from disk each time, as they are all loaded into RAM.
[pix_imageInPlace], on the other hand, loads the images to texture RAM (and as such is not used with the [pix_texture] object, as this is already done). As such, these images cannot be processed with subsequent [pix_*] objects
i was comparing the performance of LZW compressed tiffs and uncompressed ones, and had the impression that without compression it runs a bit better. do you agree?
At a guess, when you load the compressed images to memory (of whichever sort), the computer decompresses them (so that the image in memory is uncompressed). If you are using [pix_image], it would need to do this often, whereas with the other objects it would only happen once when you load them. So, when you get things working with objects other than [pix_image], by this logic, it would no longer make any difference wether the images were compressed. I think.
I've not actually directly used these objects significantly, though, so this is a bit speculative.
Cheers,
Peter
hi peter/list,
okay, i am trying to use pix_multiimage now instead. it seems that i still do something wrong, although the console does not tell me anything about it.
max
Am 11.10.2004 um 15:12 schrieb Peter Todd:
as far as i understood the help patches i should use pix_imageInPlace instead of pix_image because of better performance. i do not get the usage of pix_imageInPlace it does not really work for me, where is the problem?
OK, it looks like [pix_multiimage] works a bit more like [pix_image], only without the need to load them from disk each time, as they are all loaded into RAM.
[pix_imageInPlace], on the other hand, loads the images to texture RAM (and as such is not used with the [pix_texture] object, as this is already done). As such, these images cannot be processed with subsequent [pix_*] objects
i was comparing the performance of LZW compressed tiffs and uncompressed ones, and had the impression that without compression it runs a bit better. do you agree?
At a guess, when you load the compressed images to memory (of whichever sort), the computer decompresses them (so that the image in memory is uncompressed). If you are using [pix_image], it would need to do this often, whereas with the other objects it would only happen once when you load them. So, when you get things working with objects other than [pix_image], by this logic, it would no longer make any difference wether the images were compressed. I think.
I've not actually directly used these objects significantly, though, so this is a bit speculative.
On Oct 11, 2004, at 11:39 AM, Max Neupert wrote:
hi peter/list,
okay, i am trying to use pix_multiimage now instead. it seems that i still do something wrong, although the console does not tell me anything about it.
...first off, you should save patches with their location in the top left corner of your main screen: On my setup, they all opened offscreen, which required me to hand edit the patch and reload...
...other than that it looks ok (I don't have midi hooked up atm), but you don't refer to the image numbers by [0.1<, [0.2<, etc...if you want the first image use [0<, second image [1<, third image [2<, etc...this is explicitly stated in the gem helpfile for [pix_multiimage]...
hth, james
oops.
cool - it works now. thank you james and peter.
sorry for sending weired files. but i guess one could call this a gui bug - if you can't open files someone else saved on a second screen... same problem occurs if you have pd open, you move a window to the connected screen or projector - and later you disconnect the second screen (normal situation for presentations..) other programs seem to check first where a window can be...
max
Am 11.10.2004 um 17:58 schrieb James Tittle II:
On Oct 11, 2004, at 11:39 AM, Max Neupert wrote:
hi peter/list,
okay, i am trying to use pix_multiimage now instead. it seems that i still do something wrong, although the console does not tell me anything about it.
...first off, you should save patches with their location in the top left corner of your main screen: On my setup, they all opened offscreen, which required me to hand edit the patch and reload...
...other than that it looks ok (I don't have midi hooked up atm), but you don't refer to the image numbers by [0.1<, [0.2<, etc...if you want the first image use [0<, second image [1<, third image [2<, etc...this is explicitly stated in the gem helpfile for [pix_multiimage]...
hth, james
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
oops.
cool - it works now. thank you james and peter.
Good stuff, glad to be able to help.
sorry for sending weired files. but i guess one could call this a gui bug - if you can't open files someone else saved on a second screen...
In windows, you can right click on the item in the taskbar, click 'move', then press a cursor key, and it brings the deranged window back (I often need to do this when I make a fullscreen GEM while editing a patch on the second screen). I don't think it's really a bug, but it can certainly be irritating. Not nearly as irritating as having to edit the file manually would be, though... or, for that matter, if the position of windows was not saved. I guess there could be something in the GUI to force windows onto the screen when loaded, but it doesn't seem worth the devs bothering about too much, IMHO.
hi peter/list,
okay, i am trying to use pix_multiimage now instead. it seems that i still do something wrong, although the console does not tell me anything about it.
max
You need to use an integer to select the appropriate image, so you want to get rid of that [/ 100] for a start. The console only reports an error if you input a negative, or too large, number.
-
James Tittle II -
Max Neupert -
Peter Todd