GEM-dev March 2010

gem-dev@lists.iem.at

12 participants
33 discussions

Prosilica in OSX
by Jordi Puig 21 Mar '10

21 Mar '10

Hi all, I just got the Prosilica GE680 and I wanted to try it in PD. It has a well documented SDK running in windows, Linux and OSX. It might not be too hard to implement an object to get the data and configure the camera too. I don't have any experience in developing objects for PD but, I could make it work in OpenFrameworks with this addon: http://file.stefanix.net/ofxVideoGrabberProsilica.zip I saw also the request from IOhannes to add this feature to GEM here: http://lists.puredata.info/pipermail/gem-dev/2010-01/004392.html So I was wondering if it is already possible to run it under OSX. I would like to help in the development, or testing if needed. Thanks for any code, tip or trick! Jordi Puig

1 0

[ pd-gem-Bugs-2963094 ] gem crash with pix_video and pix_diff
by SourceForge.net 20 Mar '10

20 Mar '10

Bugs item #2963094, was opened at 2010-03-04 03:54 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2963094&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None >Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: gem crash with pix_video and pix_diff Initial Comment: Using Pd-0.42.5-extended-20100224which included Gem 0.92.2 on Mac OS X/Intel 10.5.8 with a , I had a crash. In the attached patch, I disconnected the pix_film, then connected a [pix_video] and got a crash. I attached the Mac OS X crash dump too. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-03-20 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-03-05 19:14 Message: i think i fixed it with rev3151 ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-03-05 18:33 Message: ay: it does crash when i manage to make the camera respond immediately (if i create a new camera object the initialization of the cam will take some frames, giving me a grace period that prohibits the crash) ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-03-05 18:31 Message: according to the log it is [pix_diff] that crashes. could you provide detailed information about the colourspaces and dimensions (e.g. as reported by [pix_info] your sources (film/video) provide when the crash appears. furthermore: does it happen if you send a [simd 0( message to [pix_diff] before you do anything? (btw, here (debian eee) i could replace [pix_film] (with a movie 720x576/RGBA, switching to 640x480/YUV camera) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2963094&group_…

1 0

pix_crop y coordinates
by Matteo Sisti Sette 18 Mar '10

18 Mar '10

Hi, I'm realising that pix_crop x/y coordinates work as follows: - x grows from left to right - y grows from bottom to top Isn't it a bit weird (the y part)? I know coordinate systems are always arbitrary but, aren't digital images rows almost universally counted from top to bottom? Isn't that even how they are stored in image files and memory? You may argue that this is for uniformity with Gem's coordinate system that has the Y axis pointing upward, but then pixels are not gem units.... Is there a clear advantage in using this convention against the almost universal one? Or am I plain wrong about the latter being an almost universal convention? thanks m. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

3 11

[ pd-gem-Bugs-2972644 ] rectangular textures default is platform-dependent
by SourceForge.net 18 Mar '10

18 Mar '10

Bugs item #2972644, was opened at 2010-03-18 16:28 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972644&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: rectangular textures default is platform-dependent Initial Comment: [pix_texture] has rectangle mode ON by default on Mac, and OFF by default on Windows. I don't know on Linux. The default should obviously be the same on all platforms, no matter which one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972644&group_…

1 0

[ pd-gem-Bugs-2972166 ] pix_crop, pix_resize don't "refresh" when they should
by SourceForge.net 17 Mar '10

17 Mar '10

Bugs item #2972166, was opened at 2010-03-17 21:12 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_crop, pix_resize don't "refresh" when they should Initial Comment: If you use a pix_crop on a pix_film: [pix_film] | [pix_crop] when [pix_film] has auto off, if you send floats into any of [pix_crop]'s inlets, the texture won't change accordingly until you move to another frame in [pix_film] (i.e. send a number to its right inlet or enable auto mode) I don't know whether this is an issue with pix_film or pix_crop. This does not happen with [pix_image] in conjunction with pix_crop, so it's probably pix_film. Then [pix_resize] has a similar issue: if you have: [pix_film] | [pix_resize] OR [pix_image] | [pix_resize] when you send a [dimen( message to pix_resize to change the target size, it won't change until the input pix changes. In the case of pix_film it won't change until the frame changes; in the case of pix_image it won't change until you load another image!!!!!!! This seems somewhat similar to what happens with [pix_crop], however in this case it does apply to [pix_image] too, so it would suggest an issue in [pix_resize] rather than [pix_film] or [pix_image]. I haven't done intensive testing, so it may apply to more pix objects. I don't even know if the problem may be in [pix_texture]. I attach a simple test patch for convenience. You'll need a myimage.jpg image file and a myvideo.mov movie file. And now a nastier thing, possibly related: 1) Open the attached patch, create the gemwin and click on the open messages to [pix_film]s You see the four images, twice the image and twice the video 2) Disconnect the upper [pix_image] and [pix_film] objects both from their input and output 3) move the [pix_film] on the right to the render chain on the left and connect it You would expect the video to appear but no: the jpeg image reappears, though the [pix_image] is even disconnected!!!! This is probably the same bug described above. Try all the viceversa's ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2010-03-17 23:18 Message: With pix_film, if you have to change a crop or resize of the image while not changing the frame, even sending the same frame number again won't work: the cropped or resized image won't be refreshed until pix_film actually goes to a different frame. So it is not "workaroundable" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_…

1 0

[ pd-gem-Bugs-2972246 ] pix_crop, pix_resize don't "refresh" when they should
by SourceForge.net 17 Mar '10

17 Mar '10

Bugs item #2972246, was opened at 2010-03-17 22:45 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972246&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_crop, pix_resize don't "refresh" when they should Initial Comment: If you use a pix_crop on a pix_film: [pix_film] | [pix_crop] when [pix_film] has auto off, if you send floats into any of [pix_crop]'s inlets, the texture won't change accordingly until you move to another frame in [pix_film] (i.e. send a number to its right inlet or enable auto mode) I don't know whether this is an issue with pix_film or pix_crop. This does not happen with [pix_image] in conjunction with pix_crop, so it's probably pix_film. Then [pix_resize] has a similar issue: if you have: [pix_film] | [pix_resize] OR [pix_image] | [pix_resize] when you send a [dimen( message to pix_resize to change the target size, it won't change until the input pix changes. In the case of pix_film it won't change until the frame changes; in the case of pix_image it won't change until you load another image!!!!!!! This seems somewhat similar to what happens with [pix_crop], however in this case it does apply to [pix_image] too, so it would suggest an issue in [pix_resize] rather than [pix_film] or [pix_image]. I haven't done intensive testing, so it may apply to more pix objects. I don't even know if the problem may be in [pix_texture]. I attach a simple test patch for convenience. You'll need a myimage.jpg image file and a myvideo.mov movie file. And now a nastier thing, possibly related: 1) Open the attached patch, create the gemwin and click on the open messages to [pix_film]s You see the four images, twice the image and twice the video 2) Disconnect the upper [pix_image] and [pix_film] objects both from their input and output 3) move the [pix_film] on the right to the render chain on the left and connect it You would expect the video to appear but no: the jpeg image reappears, though the [pix_image] is even disconnected!!!! This is probably the same bug described above. Try all the viceversa's ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2010-03-17 22:49 Message: Duplicated by accident because navigating with the "back" button of the browser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972246&group_…

1 0

[ pd-gem-Bugs-2972246 ] pix_crop, pix_resize don't "refresh" when they should
by SourceForge.net 17 Mar '10

17 Mar '10

Bugs item #2972246, was opened at 2010-03-17 22:45 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972246&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_crop, pix_resize don't "refresh" when they should Initial Comment: If you use a pix_crop on a pix_film: [pix_film] | [pix_crop] when [pix_film] has auto off, if you send floats into any of [pix_crop]'s inlets, the texture won't change accordingly until you move to another frame in [pix_film] (i.e. send a number to its right inlet or enable auto mode) I don't know whether this is an issue with pix_film or pix_crop. This does not happen with [pix_image] in conjunction with pix_crop, so it's probably pix_film. Then [pix_resize] has a similar issue: if you have: [pix_film] | [pix_resize] OR [pix_image] | [pix_resize] when you send a [dimen( message to pix_resize to change the target size, it won't change until the input pix changes. In the case of pix_film it won't change until the frame changes; in the case of pix_image it won't change until you load another image!!!!!!! This seems somewhat similar to what happens with [pix_crop], however in this case it does apply to [pix_image] too, so it would suggest an issue in [pix_resize] rather than [pix_film] or [pix_image]. I haven't done intensive testing, so it may apply to more pix objects. I don't even know if the problem may be in [pix_texture]. I attach a simple test patch for convenience. You'll need a myimage.jpg image file and a myvideo.mov movie file. And now a nastier thing, possibly related: 1) Open the attached patch, create the gemwin and click on the open messages to [pix_film]s You see the four images, twice the image and twice the video 2) Disconnect the upper [pix_image] and [pix_film] objects both from their input and output 3) move the [pix_film] on the right to the render chain on the left and connect it You would expect the video to appear but no: the jpeg image reappears, though the [pix_image] is even disconnected!!!! This is probably the same bug described above. Try all the viceversa's ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972246&group_…

1 0

[ pd-gem-Bugs-2972166 ] pix_crop, pix_resize don't "refresh" when they should
by SourceForge.net 17 Mar '10

17 Mar '10

Bugs item #2972166, was opened at 2010-03-17 21:12 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_crop, pix_resize don't "refresh" when they should Initial Comment: If you use a pix_crop on a pix_film: [pix_film] | [pix_crop] when [pix_film] has auto off, if you send floats into any of [pix_crop]'s inlets, the texture won't change accordingly until you move to another frame in [pix_film] (i.e. send a number to its right inlet or enable auto mode) I don't know whether this is an issue with pix_film or pix_crop. This does not happen with [pix_image] in conjunction with pix_crop, so it's probably pix_film. Then [pix_resize] has a similar issue: if you have: [pix_film] | [pix_resize] OR [pix_image] | [pix_resize] when you send a [dimen( message to pix_resize to change the target size, it won't change until the input pix changes. In the case of pix_film it won't change until the frame changes; in the case of pix_image it won't change until you load another image!!!!!!! This seems somewhat similar to what happens with [pix_crop], however in this case it does apply to [pix_image] too, so it would suggest an issue in [pix_resize] rather than [pix_film] or [pix_image]. I haven't done intensive testing, so it may apply to more pix objects. I don't even know if the problem may be in [pix_texture]. I attach a simple test patch for convenience. You'll need a myimage.jpg image file and a myvideo.mov movie file. And now a nastier thing, possibly related: 1) Open the attached patch, create the gemwin and click on the open messages to [pix_film]s You see the four images, twice the image and twice the video 2) Disconnect the upper [pix_image] and [pix_film] objects both from their input and output 3) move the [pix_film] on the right to the render chain on the left and connect it You would expect the video to appear but no: the jpeg image reappears, though the [pix_image] is even disconnected!!!! This is probably the same bug described above. Try all the viceversa's ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_…

1 0

[ pd-gem-Bugs-2969978 ] pix_multiblob mem leak
by SourceForge.net 15 Mar '10

15 Mar '10

Bugs item #2969978, was opened at 2010-03-13 21:15 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2969978&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: win32 >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pix_multiblob mem leak Initial Comment: pix_multiblob leaks memory on windows XP sp2, Gem 0.92.2. Using videostream directly from pix_video and Logitech USB webcam. About 4kB/s/blob. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-03-15 15:09 Message: should be fixed with revision 3155 (and upcoming 0.92.3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2969978&group_…

1 0

[ pd-gem-Bugs-2970522 ] crash when loadbangloading movies with gmerlin
by SourceForge.net 15 Mar '10

15 Mar '10

Bugs item #2970522, was opened at 2010-03-15 09:42 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2970522&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: linux >Status: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: crash when loadbangloading movies with gmerlin Initial Comment: when i load the clock.avi (that comes with Pd-extended) with loadbang, Gem crashes. patch: [loadbang] | [open clock.avi( | [pix_film] Gem (0.93.csv (today)) prints: pix_film:: gmerlin support pix_film:: quicktime support [pix_film]: opening /tmp/clock/clock.avi with format 1908 [pix_film]: ... [pix_film:video_realdll] Cannot find file /usr/lib/codecs/drvc.so, disabling Real Video 3.0/4.0 DLL decoder verbose( 1):[pix_film:demuxer] Detected AVI format pd_gui: pd process exited Segmentation fault gdb says: #0 0xb755f2c8 in bgav_superindex_set_durations () from /usr/lib/libgmerlin_avdec.so.1 #1 0xb74e1bc2 in bgav_demuxer_start () from /usr/lib/libgmerlin_avdec.so.1 #2 0xb74de7d7 in bgav_init () from /usr/lib/libgmerlin_avdec.so.1 #3 0xb74de92d in bgav_open () from /usr/lib/libgmerlin_avdec.so.1 #4 0xb7b9daf5 in filmGMERLIN::open (this=0x81a4c48, filename=0xbfffe444 "/tmp/clock/clock.avi", format=6408) at filmGMERLIN.cpp:158 libgavl 1.1.1-2 libgmerlin-avdec: 1.0.1-0.1 ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-03-15 10:01 Message: btw, the problem does not happen when the movie is loaded "later". anyhow, i found out that gmerlin/avdec also crashes on this file, so i will push the bug-report upstream and close it here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2970522&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev March 2010