GEM-dev April 2011

gem-dev@lists.iem.at

9 participants
62 discussions

[ pd-gem-Bugs-3222807 ] pix_image support for TIFF incomplete
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: any operating system 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 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 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

videoKINECT plugin for pix_video
by Matthias Kronlachner 07 Apr '11

07 Apr '11

hello, i am working on a videoKINECT plugin for pix_video. it depends on libfreenect. the current result can be found here: http://home.eduhi.at/just4fun/matzisoft/homepage/downloads/videoKINECT.tar.… maybe somebody with experience in coding c++ will have a look at it and improve it? it's currently NOT possible to open 2 pix_video with the kinect plugin. you can choose between rgb or depth image. have a look at provided videoKINECT-help.pd matthias

8 54

[ 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 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-3277839 ] pix_film, pix_movie, pix_video give only white frames
by SourceForge.net 06 Apr '11

06 Apr '11

Bugs item #3277839, was opened at 2011-04-06 16:00 Message generated for change (Tracker Item Submitted) made by eighthave 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3277839&group_…

1 0

[ pd-gem-Bugs-3222807 ] pix_image support for TIFF incomplete
by SourceForge.net 06 Apr '11

06 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: any operating system 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 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-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
by SourceForge.net 06 Apr '11

06 Apr '11

1 0

[ pd-gem-Bugs-3037829 ] [pix_film] has inconsitent arguments across platforms
by SourceForge.net 06 Apr '11

06 Apr '11

Bugs item #3037829, was opened at 2010-08-01 14:48 Message generated for change (Comment added) made by zmoelnig 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: Pending >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: IOhannes m zmölnig (zmoelnig) Date: 2011-04-06 18: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 06 Apr '11

06 Apr '11

Bugs item #3224807, was opened at 2011-03-19 05:18 Message generated for change (Settings changed) made by zmoelnig 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: Pending >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: Hans-Christoph Steiner (eighthave) Date: 2011-03-23 19: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 05: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

pix_artoolikit is finally working on linux.
by cyrille henry 05 Apr '11

05 Apr '11

hello, after lot's of times to understand the problem, Antoine and me finally realise that artoolkit use RGB image on linux, but pix_opencv provide RGBA image. He made a working prototype using the code on the svn, and openCV conversion routine. is there a Gem way to convert RGBA to RGB? (in order to remove openCV dependency) (this look to be mandatory only on linux) Here is the code that we are now using... (makefile should be manually adjusted since we don't know how to deal with autoconf). cheers Cyrille

2 3

[ pd-gem-Bugs-3191771 ] pix_movement treats a duplicate frame as black in Mac OS
by SourceForge.net 05 Apr '11

05 Apr '11

Bugs item #3191771, was opened at 2011-02-25 01:32 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3191771&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: 6 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_movement treats a duplicate frame as black in Mac OS Initial Comment: Consider: [pix_video] | [pix_movement] Expected behavior: When pix_video produces a duplicate frame (i.e. doesn't grab a new frame), one may expect any of these two: A - (best) pix_movement won't generate a new image B - (acceptable) pix_movement will generate a black image since it's comparing two identical frames (actually the same frame) Observed behavior in Linux: - I'm almost sure it's A Observed behavior in Mac OS: - pix_movement treats the duplicate frame as if it was a black frame; so it will compare the current frame with a completely black frame, outputting an image with a lot of "false movement". Not sure about Windows, I seem to remember it works fine just like in Linux; or it may be behavior B; surely not like Mac OS. This has been known for a long time but I couldn't find it in the bug tracker and it is not fixed, so I thought I would report it. Note that it is not just a matter of failing to detect that the new frame hasn't been grabbed. That would explain behavior B described above, flickering to black. What's happening is much wronger: duplicate frames are treated as black frames which causes the output to flicker to almost-white. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-05 13:51 Message: I'm raising priority as this renders pix_movement almost useless in Mac OS, and it is a pretty basic object. Hope this is ok ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3191771&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