ok, so we have done double work... my [pix_*NEW] objects (video/movie) do (hopefully, not quite sure about movie right now) support something like "color rgba" and "color yuv" messages. they also have a "color grey" message (which i found very handy sometimes)
i forgot to say that my changes were to the old pix_filmDarwin way of loading films. the old method is in good enough shape to transfer to pix_filmNEW i suppose. is it your intention to have the pix_filmNEW included with the next release?
would it be possible to add grey-image support too ? (guess i hear a sigh from you)
i can check and see what the QT support for 8bit greyscale is. i guess there's no reason not to include it... the YUV to grey using pix_grey should be really efficient way to do this too. it may even be faster than the QT internal conversion.
don't know, but i guess the symbolic reference "rgba"/"yuv"/"grey" might be more intuitive then 0/1/?
i fully agree with this. how about 'colorspace rgb/yuv/grey'?
Some things are still on the list:
most of these could wait for the next release then (if we manage to release soon ;-))
sure. at this point, i would rather have the release come sooner without those features than later with them.
What does everyone else's TODO list look like right now?
stability of [pix_] objects ([pix_rtx] seems to be unstable sometimes, same for [pix_sig2pix~] and [pix_pix2sig~]) need beta-testers for [pix_video] ieee1394-support under linux.
i played around with the pix_rtx example last night and it did crash when resizing the video input every once and a while. the log always pointed to line 195, which is the pixels[chRed] = rp[chRed] in the RGBA inner loop. obviously a pointer going off into no-man's land.
Stability seems pretty good recently on the OSX side, how are the other platforms running?
Gem is sometimes quite peculiar when developing patches under linux. however, it runs rockstable in, say, installations.
are those usually pd crashes? i had a whole string of those for a while a month or two ago, but they seem to have stopped.
quite a few of these:
Thread 0 Crashed: #0 0x8fe01280 in halt #1 0x8fe106b4 in link_in_need_modules #2 0x8fe12230 in _dyld_link_module #3 0x90016ae8 in NSLinkModule #4 0x0003bfe4 in sys_load_lib #5 0x00038b28 in glob_initfromgui #6 0x0003281c in pd_typedmess #7 0x000357bc in binbuf_eval #8 0x0003a138 in socketreceiver_read #9 0x00039c84 in sys_domicrosleep #10 0x0003ac00 in sys_pollgui #11 0x000387f4 in m_scheduler #12 0x00038d70 in sys_main #13 0x000026b4 in _start #14 0x000024e4 in start
i never traced it back to anything specific.