GEM-dev April 2011

gem-dev@lists.iem.at

9 participants
62 discussions

[ pd-gem-Patches-3134723 ] sphere-help
by SourceForge.net 07 Apr '11

07 Apr '11

Patches item #3134723, was opened at 2010-12-11 03:20 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3134723&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: Accepted Priority: 5 Private: No Submitted By: max (maxn) Assigned to: Nobody/Anonymous (nobody) Summary: sphere-help Initial Comment: added argument and defaults ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 14:13 Message: thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3134723&group_…

1 0

[ pd-gem-Feature Requests-2880325 ] reduce interclass dependencies
by SourceForge.net 07 Apr '11

07 Apr '11

Feature Requests item #2880325, was opened at 2009-10-16 09:01 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2880325&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: misc Group: None >Status: Pending Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: IOhannes m zmölnig (zmoelnig) Summary: reduce interclass dependencies Initial Comment: to get a more stable ABI, it would be nice if implementation details could be hidden from the public APIs of classes. - use pimpl (http://chadaustin.me/cppinterface.html) - use symbol-keyed dictionaries (e.g. for accessing data in GemState) - ... ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 14:10 Message: i think we are kind of there. for performance reasons, the GemState dictionary uses integer-keys though ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2880325&group_…

1 0

[ pd-gem-Feature Requests-3134537 ] arguments for pix_crop
by SourceForge.net 07 Apr '11

07 Apr '11

Feature Requests item #3134537, was opened at 2010-12-10 20:19 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3134537&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: Pending Priority: 5 Private: No Submitted By: max (maxn) >Assigned to: IOhannes m zmölnig (zmoelnig) Summary: arguments for pix_crop Initial Comment: please add arguments for pix_crop ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 14:08 Message: hmm, actually [pix_crop] has had arguments for a long time, though this was not documented in the help-patch. i've updated the help-patch (and clamped the defaults to 64x64+0+0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3134537&group_…

1 0

[ pd-gem-Bugs-3186166 ] pix_image assertion fail crashes pd
by SourceForge.net 07 Apr '11

07 Apr '11

Bugs item #3186166, was opened at 2011-02-18 22:07 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3186166&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: rendering (e.g. display) Group: linux Status: Open Resolution: None Priority: 5 Private: No Submitted By: Winfried Ritsch (ritsch) Assigned to: Nobody/Anonymous (nobody) Summary: pix_image assertion fail crashes pd Initial Comment: using pd0.43-test4 and Gem latest trunk of today pix_image crashes on loading an image using imagemagick-dev: #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb7d75751 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7d78b82 in *__GI_abort () at abort.c:92 #3 0xb7d6e8b8 in *__GI___assert_fail (assertion=0xb6e5f680 "semaphore_info != (SemaphoreInfo *) ((void *)0)", file=0xb6e5f66c "magick/semaphore.c", line=525, function=0xb6e5f751 "LockSemaphoreInfo") at assert.c:81 #4 0xb6d0be5c in LockSemaphoreInfo () from /usr/lib/libGraphicsMagick.so.3 #5 0xb6cd809e in GetMagickInfo () from /usr/lib/libGraphicsMagick.so.3 #6 0xb6cd3e1b in SetImageInfo () from /usr/lib/libGraphicsMagick.so.3 #7 0xb6c8cc5a in ReadImage () from /usr/lib/libGraphicsMagick.so.3 #8 0xb6f62ee6 in Magick::Image::read(std::string const&) () from /usr/lib/libGraphicsMagick++.so.3 #9 0xb71940b0 in magickImage2mem (filename=0xb474320c "/usr/local/lib/pd/extra/Gem/somefile.jpg") at GemPixImageLoad.cpp:738 #10 0xb71942ef in image2mem (filename=0x85c1db0 "/usr/local/lib/pd/extra/Gem/somefile.jpg") at GemPixImageLoad.cpp:128 #11 0xb7248a1d in pix_image::openThread (you=0x85c1820) at pix_image.cpp:165 #12 0xb7eb8955 in start_thread (arg=0xb4743b70) at pthread_create.c:300 #13 0xb7e16e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 OS: i386 squeeze stable Debian (just updated) Used pix_image-help patch. mfg winfried ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 13:58 Message: this is really weird, as i never experienced anything like this. i'm pretty sure that ImageMagick _is_ thread safe, and i'm using libmagick++-dev (8:6.6.0.4-3) all the time without problems (seems like the same version is in squeeze-wheezy-sid right now) does it help if you use [thread 0, open <myimage>( ? ---------------------------------------------------------------------- Comment By: Winfried Ritsch (ritsch) Date: 2011-02-18 22:26 Message: compiling Gem with --without-ImageMagick doesnt crash so it is definitily ImageMagick with cloned process. image.read( filename ); so library is not thread save. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3186166&group_…

1 0

[ pd-gem-Bugs-3279243 ] multimodel performance issue
by SourceForge.net 07 Apr '11

07 Apr '11

Bugs item #3279243, was opened at 2011-04-07 13:08 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3279243&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: linux >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Pierre M. (r33p) Assigned to: Nobody/Anonymous (nobody) Summary: multimodel performance issue Initial Comment: multimodel performs good with gem stable release 0.92.3 but multimodel is performing bad, i.e a very big cpu usage, with latest gem sources (0.93 svn, 06/04/2011) gem compiled with pd vanilla 0.43 latest sources (git) on ubuntu 10.10 64bits : 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux see this files for test patch and models (.obj) files : http://92.243.12.140/610___Pd_Patches/Gem_Multimodel_TestPatch.tar.gz ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 13:52 Message: thanks for the report and the example; it turns out that the entire displaylists were rebuilt each time a new model was selected, which ate all the performance... should be fixed with rev3907 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3279243&group_…

1 0

[ pd-gem-Bugs-3277839 ] pix_film, pix_movie, pix_video give only white frames
by SourceForge.net 07 Apr '11

07 Apr '11

Bugs item #3277839, was opened at 2011-04-06 22:00 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3277839&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: osx Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: pix_film, pix_movie, pix_video give only white frames Initial Comment: On Mac OS X 10.5.8/Intel on a MacBookPro3,1 with a GeForce 8600M GT, using a Pd-extended 0.43 nightly build from 2011-04-01, pix_film, pix_movie, and pix_video only give me white frames. With pix_video, it turns on the LED next to the camera like its opened the camera. With pix_film-help.pd, using anim-1.mov, pix_film reports [91 256 256( from its second outlet, but the [rectangle] is only white. This problem was initially discussed in this thread: http://lists.puredata.info/pipermail/gem-dev/2011-03/005026.html ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 13:22 Message: ignore my last comment, as i was using a wrong version of Gem. indeed, [pix_filmDarwin]/[pix_videoDarwin] currently does not output any images. the reason for the problem is, that GemState has changed significantly; rather than fixing [pix_*Darwin] i propose to use the new plugin system on OSX as well. i have updated the build scripts for PdX accordingly ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 09:02 Message: interesting, on 10.5.8/G4 i had no problems with the 2011-04-06 build, i will try the 2011-04-01 as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3277839&group_…

1 0

[ pd-gem-Bugs-3279243 ] multimodel performance issue
by SourceForge.net 07 Apr '11

07 Apr '11

Bugs item #3279243, was opened at 2011-04-07 13:08 Message generated for change (Tracker Item Submitted) made by r33p You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3279243&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: linux Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pierre M. (r33p) Assigned to: Nobody/Anonymous (nobody) Summary: multimodel performance issue Initial Comment: multimodel performs good with gem stable release 0.92.3 but multimodel is performing bad, i.e a very big cpu usage, with latest gem sources (0.93 svn, 06/04/2011) gem compiled with pd vanilla 0.43 latest sources (git) on ubuntu 10.10 64bits : 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux see this files for test patch and models (.obj) files : http://92.243.12.140/610___Pd_Patches/Gem_Multimodel_TestPatch.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3279243&group_…

1 0

[ pd-gem-Bugs-3222807 ] pix_image support for TIFF incomplete (linux)
by SourceForge.net 07 Apr '11

07 Apr '11

Bugs item #3222807, was opened at 2011-03-18 15:28 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&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: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_image support for TIFF incomplete (linux) Initial Comment: pix_image doesn't load certain images saved with Adobe Photoshop. The worst thing is that it doesn't print an error message and, sometimes (but not always), it even prints the success message: "threaded loaded image: xxx.tif" even if the image is not decoded. I attach a tiff file saved with Adobe Photoshop that triggers this issue. Maybe the source of the problem is the existence in the file of a private tiff tag "37724" (Image Source Data) which is used by Photoshop. All images I tried that have this tag suffer from this issue. Unfortunately if you open one such image with Photoshop and save it again, there seems not to be any way to get rid of this tag (nor to know about its existance). Note that a lot of people use Photoshop under Mac or Windows to edit or create image files. However I created other images from scratch with Photoshop myself and they didn't suffer from this problem (and they don't seem to have that tag). I don't know what determines whether Photoshop includes this tag or not in the saved image. Anyway, as far as I understand (which is not very far) the presence of an unknown tag shouldn't be a reason for not being able to decode an image. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 11:39 Message: i'm only saying that the fix is not as trivial as on linux. i totally agree that it ought to be fixed (hence the requst for another bug-report) ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-07 10:46 Message: Sorry, you're right, i had tested on Linux and Windows, NOT Mac OS. According to what you say there's almost no chance it is fixed in Windows now, anyway I'll test it and open a separate bug report ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 10:11 Message: well, i now tested on OSX with - an uptodate Gem from svn - a recent pd-extended buld (0.43-20110401) - an old 0.92.1 version i found on the harddisk - a recent build of 0.92.3 (_not_ the one included in Pd-extended) all version of Gem on OSC were able to load your image without further ado. this basically leaves only w32 (which i cannot test right now) if the problem indeed exists on w32, please submit another bug-report indicating the OS (this is good for the bugs-closed statistic :-)) ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 09:54 Message: i don't know either :-) in theory it is like that: Gem uses several backends for image reading, which one are available/used, depends on the platform. - OSX: Gem uses QuickTime to read the image. if QuickTime fails, Gem fails as well; otoh it is unlikely that QuickTime is unable to read such a "problematic" TIFF file. Gem _could_ use imagemagick on OSX as well, but afaik doesn't do so. - w32: Gem uses some rather old static code to decode image files (hence there is only a very limited number of supported formats); this code might not be able to read your TIFF file, and i have no real intent to fix this; rather, the w32 version should switch to a more common API (DirectSomething and/or QT) for reading images. - linux: Gem uses imagemagick OR libTIFF/libJPEG for reading images; the fix in rev3906 fixed the problem with imagemagick, the direct libTIFF reading did not seem to have a problem. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-06 21:32 Message: With 0.92.3 the issue does exist on all platform (well on Linux, Windows and Mac OS). I don't know if the fix you mention is supposed to fix it for Windows and Mac OS too. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-06 21:19 Message: i believe the problem is fixed for ImageMagick loading code (as used e.g. on linux) with rev3906 if you encounter the same problem on other platforms (esp. w32) please reopen this report ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&group_…

1 0

[ pd-gem-Bugs-3222807 ] pix_image support for TIFF incomplete (linux)
by SourceForge.net 07 Apr '11

07 Apr '11

Bugs item #3222807, was opened at 2011-03-18 15:28 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&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: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_image support for TIFF incomplete (linux) Initial Comment: pix_image doesn't load certain images saved with Adobe Photoshop. The worst thing is that it doesn't print an error message and, sometimes (but not always), it even prints the success message: "threaded loaded image: xxx.tif" even if the image is not decoded. I attach a tiff file saved with Adobe Photoshop that triggers this issue. Maybe the source of the problem is the existence in the file of a private tiff tag "37724" (Image Source Data) which is used by Photoshop. All images I tried that have this tag suffer from this issue. Unfortunately if you open one such image with Photoshop and save it again, there seems not to be any way to get rid of this tag (nor to know about its existance). Note that a lot of people use Photoshop under Mac or Windows to edit or create image files. However I created other images from scratch with Photoshop myself and they didn't suffer from this problem (and they don't seem to have that tag). I don't know what determines whether Photoshop includes this tag or not in the saved image. Anyway, as far as I understand (which is not very far) the presence of an unknown tag shouldn't be a reason for not being able to decode an image. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-07 10:46 Message: Sorry, you're right, i had tested on Linux and Windows, NOT Mac OS. According to what you say there's almost no chance it is fixed in Windows now, anyway I'll test it and open a separate bug report ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 10:11 Message: well, i now tested on OSX with - an uptodate Gem from svn - a recent pd-extended buld (0.43-20110401) - an old 0.92.1 version i found on the harddisk - a recent build of 0.92.3 (_not_ the one included in Pd-extended) all version of Gem on OSC were able to load your image without further ado. this basically leaves only w32 (which i cannot test right now) if the problem indeed exists on w32, please submit another bug-report indicating the OS (this is good for the bugs-closed statistic :-)) ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 09:54 Message: i don't know either :-) in theory it is like that: Gem uses several backends for image reading, which one are available/used, depends on the platform. - OSX: Gem uses QuickTime to read the image. if QuickTime fails, Gem fails as well; otoh it is unlikely that QuickTime is unable to read such a "problematic" TIFF file. Gem _could_ use imagemagick on OSX as well, but afaik doesn't do so. - w32: Gem uses some rather old static code to decode image files (hence there is only a very limited number of supported formats); this code might not be able to read your TIFF file, and i have no real intent to fix this; rather, the w32 version should switch to a more common API (DirectSomething and/or QT) for reading images. - linux: Gem uses imagemagick OR libTIFF/libJPEG for reading images; the fix in rev3906 fixed the problem with imagemagick, the direct libTIFF reading did not seem to have a problem. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-06 21:32 Message: With 0.92.3 the issue does exist on all platform (well on Linux, Windows and Mac OS). I don't know if the fix you mention is supposed to fix it for Windows and Mac OS too. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-06 21:19 Message: i believe the problem is fixed for ImageMagick loading code (as used e.g. on linux) with rev3906 if you encounter the same problem on other platforms (esp. w32) please reopen this report ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&group_…

1 0

[ pd-gem-Bugs-3222807 ] pix_image support for TIFF incomplete (linux)
by SourceForge.net 07 Apr '11

07 Apr '11

Bugs item #3222807, was opened at 2011-03-18 15:28 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&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: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) >Summary: pix_image support for TIFF incomplete (linux) Initial Comment: pix_image doesn't load certain images saved with Adobe Photoshop. The worst thing is that it doesn't print an error message and, sometimes (but not always), it even prints the success message: "threaded loaded image: xxx.tif" even if the image is not decoded. I attach a tiff file saved with Adobe Photoshop that triggers this issue. Maybe the source of the problem is the existence in the file of a private tiff tag "37724" (Image Source Data) which is used by Photoshop. All images I tried that have this tag suffer from this issue. Unfortunately if you open one such image with Photoshop and save it again, there seems not to be any way to get rid of this tag (nor to know about its existance). Note that a lot of people use Photoshop under Mac or Windows to edit or create image files. However I created other images from scratch with Photoshop myself and they didn't suffer from this problem (and they don't seem to have that tag). I don't know what determines whether Photoshop includes this tag or not in the saved image. Anyway, as far as I understand (which is not very far) the presence of an unknown tag shouldn't be a reason for not being able to decode an image. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 10:11 Message: well, i now tested on OSX with - an uptodate Gem from svn - a recent pd-extended buld (0.43-20110401) - an old 0.92.1 version i found on the harddisk - a recent build of 0.92.3 (_not_ the one included in Pd-extended) all version of Gem on OSC were able to load your image without further ado. this basically leaves only w32 (which i cannot test right now) if the problem indeed exists on w32, please submit another bug-report indicating the OS (this is good for the bugs-closed statistic :-)) ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-07 09:54 Message: i don't know either :-) in theory it is like that: Gem uses several backends for image reading, which one are available/used, depends on the platform. - OSX: Gem uses QuickTime to read the image. if QuickTime fails, Gem fails as well; otoh it is unlikely that QuickTime is unable to read such a "problematic" TIFF file. Gem _could_ use imagemagick on OSX as well, but afaik doesn't do so. - w32: Gem uses some rather old static code to decode image files (hence there is only a very limited number of supported formats); this code might not be able to read your TIFF file, and i have no real intent to fix this; rather, the w32 version should switch to a more common API (DirectSomething and/or QT) for reading images. - linux: Gem uses imagemagick OR libTIFF/libJPEG for reading images; the fix in rev3906 fixed the problem with imagemagick, the direct libTIFF reading did not seem to have a problem. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-06 21:32 Message: With 0.92.3 the issue does exist on all platform (well on Linux, Windows and Mac OS). I don't know if the fix you mention is supposed to fix it for Windows and Mac OS too. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-06 21:19 Message: i believe the problem is fixed for ImageMagick loading code (as used e.g. on linux) with rev3906 if you encounter the same problem on other platforms (esp. w32) please reopen this report ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&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 April 2011