GEM-dev June 2010

gem-dev@lists.iem.at

5 participants
45 discussions

[ pd-gem-Bugs-3007370 ] pix_dump does not properly after an image has been resized
by SourceForge.net 10 Jun '10

10 Jun '10

Bugs item #3007370, was opened at 2010-05-26 13:53 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&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: 5 Private: No Submitted By: Thomas O Fredericks (mrtof) Assigned to: Nobody/Anonymous (nobody) Summary: pix_dump does not properly after an image has been resized Initial Comment: pix_dump does not dump the pixel data properly of a greyscale video feed that has been resized to 25x25 pixels: 1) The number of pixels returned is 624 instead of 625! 2) If the dumped data is fed back to a pix_set the resulting image is garbage Note: I want to resize the video to such a low resolution to send the pixel data by serial to a Peggy 2. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-06-10 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-05-26 16:07 Message: [pix_dump] in greyscale mode currently needs the number of pixels be dividible by 4. so if you can live with a 24*24 or a 26*26 image, you will be on the save side. anyhow, the issue only skips the remaining pixels, so adding dummy-pixels manually could help... i committed a fix to svn/trunk with revision #3357 i committed a fix to svn/branches/0.92 with revision #3359 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&group_…

1 0

[ pd-gem-Bugs-3007373 ] pix_resize crashes PD if a dimension is set before rendering
by SourceForge.net 10 Jun '10

10 Jun '10

Bugs item #3007373, was opened at 2010-05-26 13:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007373&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: 5 Private: No Submitted By: Thomas O Fredericks (mrtof) Assigned to: Nobody/Anonymous (nobody) Summary: pix_resize crashes PD if a dimension is set before rendering Initial Comment: pix_resize crashes PD once the gemwin is created if a "dimen 25 25" was sent to the object before the gemwin was created. This also happens if the dimensions are set as arguments. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-06-10 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-05-26 16:11 Message: ah, i finally managed to reproduce. the problem seems to happen only with greyscale images. i suspect that the internally used gluScaleImage() needs a bit more memory allocated than just the target image. a simple workaround is, to do the first resize to a bigger image (e.g. only downsize once the rendering has started); the image will not free the allocated space if the new size fits into the old memory, thus giving you enough headroom. i committed a fix to svn/trunk with revision #3358 i committed a fix to svn/branches/0.92 with revision #3360 this "fix" assumes that 4 bytes per pixel are enough.(which is an assumption on my side) ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-26 15:00 Message: unable to reproduce i tried with both Gem-0.92 (svn/branches/0.92) and svn/trunk an there ar no crashes. please provide detailed information about your system (versions!) and a simple example patch that triggers the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007373&group_…

1 0

[ pd-gem-Bugs-3013128 ] pix_color bad colors
by SourceForge.net 08 Jun '10

08 Jun '10

Bugs item #3013128, was opened at 2010-06-08 11:06 Message generated for change (Tracker Item Submitted) made by paresys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3013128&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: paresys (paresys) Assigned to: Nobody/Anonymous (nobody) Summary: pix_color bad colors Initial Comment: The color at the output of pix_color is not correct by example: Message 0.23 0.23 0.23 display color black Problem with colorspace yuv, Pd-0.42.5-extended-rc1 (GEM: ver: 0.92.3), MacOSX.4, Intel or PPC. No problem with colorspace rgba No problem with Pd-0.41.4-extended I have not tested under Linux. I have not tested under Windows Gerard. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3013128&group_…

1 0

asynchronous pixel buffer objects for recording etc
by Claude Heiland-Allen 07 Jun '10

07 Jun '10

Hi list, Is there any way in current Gem to use asynchronous readback of pixel buffer objects to speed up recording (or other GPU<->CPU transfer)? In one of my projects in plain C/OpenGL I used this technique successfully: 1) naive (blocking) glReadPixels direct to CPU ram and piped via stdout to ppmtoy4m|y4mscaler|mpeg2enc -> about 5fps 2) async glReadPixels to pixel buffer object mapped into the CPU with one frame latency and piped via stdout to same encoder -> about 20fps 3) async glReadPixels to PBO to CPU piped via stdout to /dev/null -> about 25fps (laptop with 4GB ram, intel core2 dual core cpu, nvidia g105m gpu, tested with 32bit gnu/linux/ubuntu/karmic generic-pae kernel) Thanks for any tips, Claude -- http://claudiusmaximus.goto10.org

3 4

[ pd-gem-Feature Requests-2998083 ] raw camera
by SourceForge.net 02 Jun '10

02 Jun '10

Feature Requests item #2998083, was opened at 2010-05-07 09:35 Message generated for change (Settings changed) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2998083&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: image processing Group: None >Status: Closed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: raw camera Initial Comment: guppy camera and lot's of good quality FW cam output raw data. (by example : http://www.stemmer-imaging.fr/fr/pages/products/line.php?item=AVT.Guppy.CCD…) Most sotftware (processing , jitter, ..) can use this cam , but not Gem. it would be really usefull to be able to use this kind of hardware ---------------------------------------------------------------------- >Comment By: Cyrille Henry (nusmuk) Date: 2010-06-02 13:03 Message: yes, it now work with DC1394. thanks a lot ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-27 07:15 Message: i guess with "raw" you mean cameras adhering to the "IIDC" standard. in current trunk there is support for this kind of cameras ("videoDC1394" plugin) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2010-05-07 10:40 Message: i try coriender, and it segfault... indeed, direct suport would be nice. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-07 10:11 Message: i guess you could use coriander to make a loopback device readabke by Gem. of course it would be nicer to have direct support (so i leave this FR open) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2998083&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 June 2010