GEM-dev April 2011

gem-dev@lists.iem.at

9 participants
62 discussions

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

20 Apr '11

Bugs item #3222807, was opened at 2011-03-18 14:28 Message generated for change (Comment added) made by sf-robot 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: Closed 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: SourceForge Robot (sf-robot) Date: 2011-04-20 19: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: 2011-04-07 09: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 08: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 zmlnig (zmoelnig) Date: 2011-04-07 08: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 zmlnig (zmoelnig) Date: 2011-04-07 07: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 19: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 zmlnig (zmoelnig) Date: 2011-04-06 19: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-3037829 ] [pix_film] has inconsitent arguments across platforms
by SourceForge.net 20 Apr '11

20 Apr '11

Bugs item #3037829, was opened at 2010-08-01 12:48 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3037829&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 Resolution: Fixed Priority: 5 Private: No Submitted By: jack (jackovic) Assigned to: Nobody/Anonymous (nobody) Summary: [pix_film] has inconsitent arguments across platforms Initial Comment: Putting the filename as argument in [pix_film] doesn't work, it doesn't load the movie on Ubuntu 10.04 and Pd 0.42.5 and GEM 0.92.3. On MacOSX.4.11 and Pd-extended 0.41.4 and GEM 0.91.3 'tigital' it works fine. ++ Jack ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-04-20 16: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: 2011-04-06 16:03 Message: thanks; this is fixed in Gem-0.93 with the new plugin architecture ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3037829&group_…

1 0

[ pd-gem-Bugs-3224807 ] Gem tries to print Str63 and/or Str255 as if they were ordin
by SourceForge.net 20 Apr '11

20 Apr '11

Bugs item #3224807, was opened at 2011-03-19 04:18 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3224807&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Gem tries to print Str63 and/or Str255 as if they were ordin Initial Comment: pix film will not take $1 variable or %s variable to open mov file ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-04-20 16: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: Hans-Christoph Steiner (eighthave) Date: 2011-03-23 18:50 Message: I think I fixed this in this commit: http://pd-gem.svn.sourceforge.net/viewvc/pd-gem?view=revision&revision=3890 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-19 04:23 Message: I first thought that there might be a bug with printing the error message, because I found that Gem has one or more similar bugs. Inside of the source code of [pix_filmDarwin] the error message above is printed by this command: error("unable to find file: %#s", theFSSpec.name); But when looking at the programming manual of MacOSX 10.4 for what %#s means, it says that %#s has no meaning ("#" would mean nothing when used together with "s"). So, I don't know what %#s is supposed to be doing there, and whether it means that theFSSpec.name is printed in the console in the wrong way or what. I know that in some places, Gem does (or used to do): error("blahblah: %s", name); instead of: error("blahblah: %*s", *name, name+1); and that it caused weird stuff to appear in the console when I got those errors, but it's normally a lot less garbled than what you've got: I could really see the filename, prefixed by one unwanted character, and suffixed by possibly a bunch of unwanted characters. However, when I look at what theFSSpec.name is supposed to be in the error message, it looks like it's part of the same problem. copied from matju's mail on pd-list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3224807&group_…

1 0

[ pd-gem-Feature Requests-2827107 ] improve pix_data
by SourceForge.net 18 Apr '11

18 Apr '11

Feature Requests item #2827107, was opened at 2009-07-25 21:13 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2827107&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: Cyrille Henry (nusmuk) >Assigned to: IOhannes m zmölnig (zmoelnig) Summary: improve pix_data Initial Comment: pix_data is very usefull, but could be improved : - a quality 1 message could be add in order to set bilinear interpolation - a 32 bit mode could be add in order to read data from a 32 bit framebuffer. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-18 16:47 Message: i've added bilinear interpolation to [pix_data], though i'd rather had [pix_data] be replaced by something like [pix_buffer_peek] (or a "peek" message to [pix_buffer]) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2009-08-18 16:38 Message: ok, interpolation can be made in the patch, but it would be lot's easier to use it it is in pix_data. It also would be faster. so i think to have a "quality 1" message to pix_data would still be nice. You are right for the framebufer, i'll do another feature request. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2009-08-10 21:40 Message: bilinear (or whatever) interpolation could be easily done in the patch. as for the other request: [pix_data] does not know anything about framebuffers, but works on pixes, which currently are only 8bit per channel. however, it would be interesting to be able to query pixels of a render-buffer with high-resolution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2827107&group_…

1 0

[ pd-gem-Bugs-3284754 ] pix_blobtracker help: route 1... should be route 0
by SourceForge.net 13 Apr '11

13 Apr '11

Bugs item #3284754, was opened at 2011-04-11 21:26 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284754&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: documentation Group: any operating system >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_blobtracker help: route 1... should be route 0 Initial Comment: The help patch for pix_blobtracker shows a [route 1 2 3 4 5 6] for routing info about 6 blobs, but pix_blobtracker actually numbers the blob starting from 0, not 1. so it should be [route 0 1 2 3 4 5] ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-13 19:49 Message: thanks, should be fixed with rev3919 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284754&group_…

1 0

trying to access idc1394 camera parameter
by cyrille henry 13 Apr '11

13 Apr '11

Hello, Antoine and I are trying to modify the videoDC1394.cpp file in order to be able to control camera "feature" like gain/shutter etc. the code is a bit complex and we failed to understand how to correctly implement all set / get and enum property. So, Iohannes : have you planed to implement this very soon? ;-) if not, could you explain us a bit how should we proceed? more specifically, how dc1394 and pix_video communicate? how does gem::properties works? thanks a lot Cyrille

2 1

[ pd-gem-Bugs-3284037 ] pix_blobtracker has dependencies not satisfied in Pd Extendd
by SourceForge.net 13 Apr '11

13 Apr '11

Bugs item #3284037, was opened at 2011-04-11 03:19 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&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: Works For Me Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_blobtracker has dependencies not satisfied in Pd Extendd Initial Comment: The abstraction pix_blobtracker contains objects from iemmatrix, e.g. mtx_resize, but they are created as [mtx_resize] instead of [iemmatrix/mtx_resize]. The folder iemmatrix is not libdir'ed by default in Pd Extended (I don't know if it should), so those objects won't create and the abstraction is rendered useless unless you manually libdir iemmatrix. Also note that the abstraction itself is not available as [pix_blobtracker], you have to write [Gem/pix_blobtracker], because Gem's directory is not added either, but I think it's fixed in the svn (read something about it in the pd-list or gem-dev) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-04-13 11:23 Message: oh, I guess I can't attach a file because its Pending? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-04-13 11:22 Message: Adding [declare -lib iemmatrix] and changing [mtx_*] to [mtx_mul] will work on all permutations, I just tested it. I attached the patch. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-13 11:01 Message: thanks for your report. well, several things: - [pix_blobtracker] depends on an 3rd party Pd-library, iemmatrix, where the actual persistent labeling is implemented. i thought about, whether it is a good idea to depend on 3rd party libraries for objects, but in the end i thought that it is better to do that than to duplicate code in Gem for such special purposes - [pix_blobtracker] depends on iemmatrix as it is intended and distributed by upstream. if you cannot create [mtx_*] then you installation of iemmatrix is broken. this is a Pd-extended bug - it might be that pix_blobtracker] lacks an [import -lib iemmatrix] line (i'll check that) - for [mtx_*] you might have to load the "hexloader". ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-11 15:24 Message: I'm changing the subject. Maybe this is more a bug of Pd Extended as a "distribution" than of Gem. pix_blobtrack simply depends on both Gem and iemmatrix. The issue in Pd Extended is that it includes things that depend on other things which are not included or are included in a way that does not work properly (i.e. iemmatrix) ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-11 03:22 Message: there is also a mtx_* object that also doesn't create but apparently is not part of iemmatrix (replacing it with [iemmatrix/mtx_x] doen't fix it) and I don't know which library it belongs to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&group_…

1 0

[ pd-gem-Bugs-3284037 ] pix_blobtracker has dependencies not satisfied in Pd Extendd
by SourceForge.net 13 Apr '11

13 Apr '11

Bugs item #3284037, was opened at 2011-04-11 03:19 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&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: Works For Me Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_blobtracker has dependencies not satisfied in Pd Extendd Initial Comment: The abstraction pix_blobtracker contains objects from iemmatrix, e.g. mtx_resize, but they are created as [mtx_resize] instead of [iemmatrix/mtx_resize]. The folder iemmatrix is not libdir'ed by default in Pd Extended (I don't know if it should), so those objects won't create and the abstraction is rendered useless unless you manually libdir iemmatrix. Also note that the abstraction itself is not available as [pix_blobtracker], you have to write [Gem/pix_blobtracker], because Gem's directory is not added either, but I think it's fixed in the svn (read something about it in the pd-list or gem-dev) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-04-13 11:22 Message: Adding [declare -lib iemmatrix] and changing [mtx_*] to [mtx_mul] will work on all permutations, I just tested it. I attached the patch. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-13 11:01 Message: thanks for your report. well, several things: - [pix_blobtracker] depends on an 3rd party Pd-library, iemmatrix, where the actual persistent labeling is implemented. i thought about, whether it is a good idea to depend on 3rd party libraries for objects, but in the end i thought that it is better to do that than to duplicate code in Gem for such special purposes - [pix_blobtracker] depends on iemmatrix as it is intended and distributed by upstream. if you cannot create [mtx_*] then you installation of iemmatrix is broken. this is a Pd-extended bug - it might be that pix_blobtracker] lacks an [import -lib iemmatrix] line (i'll check that) - for [mtx_*] you might have to load the "hexloader". ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-11 15:24 Message: I'm changing the subject. Maybe this is more a bug of Pd Extended as a "distribution" than of Gem. pix_blobtrack simply depends on both Gem and iemmatrix. The issue in Pd Extended is that it includes things that depend on other things which are not included or are included in a way that does not work properly (i.e. iemmatrix) ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-11 03:22 Message: there is also a mtx_* object that also doesn't create but apparently is not part of iemmatrix (replacing it with [iemmatrix/mtx_x] doen't fix it) and I don't know which library it belongs to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&group_…

1 0

[ pd-gem-Bugs-3284037 ] pix_blobtracker has dependencies not satisfied in Pd Extendd
by SourceForge.net 13 Apr '11

13 Apr '11

Bugs item #3284037, was opened at 2011-04-11 09:19 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&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: Works For Me Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_blobtracker has dependencies not satisfied in Pd Extendd Initial Comment: The abstraction pix_blobtracker contains objects from iemmatrix, e.g. mtx_resize, but they are created as [mtx_resize] instead of [iemmatrix/mtx_resize]. The folder iemmatrix is not libdir'ed by default in Pd Extended (I don't know if it should), so those objects won't create and the abstraction is rendered useless unless you manually libdir iemmatrix. Also note that the abstraction itself is not available as [pix_blobtracker], you have to write [Gem/pix_blobtracker], because Gem's directory is not added either, but I think it's fixed in the svn (read something about it in the pd-list or gem-dev) ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-13 17:01 Message: thanks for your report. well, several things: - [pix_blobtracker] depends on an 3rd party Pd-library, iemmatrix, where the actual persistent labeling is implemented. i thought about, whether it is a good idea to depend on 3rd party libraries for objects, but in the end i thought that it is better to do that than to duplicate code in Gem for such special purposes - [pix_blobtracker] depends on iemmatrix as it is intended and distributed by upstream. if you cannot create [mtx_*] then you installation of iemmatrix is broken. this is a Pd-extended bug - it might be that pix_blobtracker] lacks an [import -lib iemmatrix] line (i'll check that) - for [mtx_*] you might have to load the "hexloader". ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-11 21:24 Message: I'm changing the subject. Maybe this is more a bug of Pd Extended as a "distribution" than of Gem. pix_blobtrack simply depends on both Gem and iemmatrix. The issue in Pd Extended is that it includes things that depend on other things which are not included or are included in a way that does not work properly (i.e. iemmatrix) ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-11 09:22 Message: there is also a mtx_* object that also doesn't create but apparently is not part of iemmatrix (replacing it with [iemmatrix/mtx_x] doen't fix it) and I don't know which library it belongs to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&group_…

1 0

[ pd-gem-Bugs-3284754 ] pix_blobtracker help: route 1... should be route 0
by SourceForge.net 11 Apr '11

11 Apr '11

Bugs item #3284754, was opened at 2011-04-11 21:26 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284754&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: documentation Group: any operating system Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_blobtracker help: route 1... should be route 0 Initial Comment: The help patch for pix_blobtracker shows a [route 1 2 3 4 5 6] for routing info about 6 blobs, but pix_blobtracker actually numbers the blob starting from 0, not 1. so it should be [route 0 1 2 3 4 5] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284754&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