Bugs item #3000166, was opened at 2010-05-11 22:48
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3000166&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: marius schebella (mariusschebella)
Assigned to: Nobody/Anonymous (nobody)
Summary: lighting with cone and cylinder
Initial Comment:
hi, even if this is very unlikely, but is it possible that when turning on lighting with cone and cylinder the lighting vector is pointing to the wrong direction? at least it looks as if the light source is coming from the opposite side (compared to other geos like cube or sphere). I am using GEM: ver: 0.92.3, compiled: Mar 15 2010 on mac OSX
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-06-15 11:47
Message:
i think you are right.
the question is: should we just change it to be correct (e.g. will it
break anything)?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3000166&group_…
Bugs item #3013128, was opened at 2010-06-08 11:06
Message generated for change (Comment added) made by zmoelnig
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: Pending
>Resolution: Fixed
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.
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-06-15 11:40
Message:
thanks for reporting this bug.
it should be fixed with this commit
http://pd-gem.svn.sourceforge.net/pd-gem/?rev=3365&view=rev
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3013128&group_…
Feature Requests item #2520000, was opened at 2009-01-19 15:03
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2520000&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: Closed
Priority: 2
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing build/autoconf section
Initial Comment:
most build systems have been moved into Gem/build (e.g. Gem/build/win-vs2003)
however, the autoconf buildsystem is still in Gem/src/
it should be moved to Gem/build/autoconf as well
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2010-06-11 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-27 07:39
Message:
there is a minimalistic but working build/autoconf/ section which
recursively calls the autotools in src/
i guess this will do for a while
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2009-01-19 15:04
Message:
what about all the Makefiles? should they go into Gem/build/autoconf as
well?
((i guess so))
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2520000&group_…
Feature Requests item #2940283, was opened at 2010-01-26 15:10
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2940283&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: OS:: Linux
Group: Next Release (example)
>Status: Closed
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: support for new ieee1394 stack on linux
Initial Comment:
the ieee1394 stack on linux has been replaced in recent kernels (2.6.30 or so) by a new implementation called "juju".
unfortunately this means, that Gem cannot use and dv-cams on linux any more.
here's almost no information: http://article.gmane.org/gmane.linux.kernel.firewire.devel/10358
basically it means to change the code to use the new libraw1394 and libdc1394
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2010-06-11 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-27 07:17
Message:
in current trunk there is support for both the traditional DV1394 interface
and the new juju stack ("videoDV4L"
plugin)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2940283&group_…
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_…
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_…
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_…
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
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_…