GEM-dev November 2011

gem-dev@lists.iem.at

16 participants
88 discussions

pix_write relative path - osx
by Nicolas Montgermont 01 Dec '11

01 Dec '11

Hello list, I was wondering if the problem of the relative path of [pix_write] under osx may be fixed soon. For reminder the actual behavior (gem compiled this morning, used with pd-extended 0.42.5, osx.6.8) is: - if you send no filename, you have in the terminal: error: ERROR: -43 in GraphicsExportSetOutputFile() error: GEM: Unable to save image to 'gem00000.tif' - if you send a relative filename, eg. [file toto(, you have the same error: error: ERROR: -43 in GraphicsExportSetOutputFile() error: GEM: Unable to save image to 'toto00000.tif' - if you send a filename including the "~" home variable, it gives the same error. It only works if you set pix_write to an absolute filename inside an existing directory, eg. [file /Users/nix/snap_pd/test (. From what i've seen in workshop, this is a major difficulty for learners. They are not specially used to explicit a directory from root, and they must not have spaces in any directory name used. It makes also a patch containing pix_write on an osx computer non directly usable on any another ... Is there any possibility to have relative path in pix_write under osx, or can we imagine some workaround? it will be of great help thanks, n -- http://nim.on.free.fr

6 18

[ pd-gem-Bugs-3445361 ] pix_write quality not working - osx
by SourceForge.net 30 Nov '11

30 Nov '11

Bugs item #3445361, was opened at 2011-11-29 09:32 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nicolas Montgermont (nimon) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write quality not working - osx Initial Comment: pix_write create exactly the same jpg file when specifying type = 1 or type = 99 see attached captured file (from pix_image help file) for the two quality. GEM: ver: 0.93.git 2687102 OSX 10.6.8 Image saving support: QT ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-11-30 07:49 Message: time to build the gmerlin, etc. plugins for Mac OS X? ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 05:59 Message: right... a pity! ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 05:54 Message: i checked again, and using an apple app like "Preview", and it behaves the same. go thank apple that their strive for happy customers does not allow you to save a jpeg (using QuickTime) with "unacceptable" quality. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 03:52 Message: what is the expected behaviour? [pix_write] will request the backend to write between lossless (quality=100) and "lowest possible quality" (0). the operating system defines what "lowest" quality means. on OSX this would be "codecMinQuality" (whatever that means). [pix_write] currently does not really allow to set a quality=0 for jpeg images (since "0" automatically means: lossless TIFF), so quality=1 should be a "bit" better than "codecMinQuality". ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 00:45 Message: I can now see a difference between type=1 and type=99 but it is still very low. The image with quality = 1 is still very clean and has a certain weight. Writing the output of example/04.pix/01.image, it gives : type = 1 : 6771 bytes type = 99 : 12 928 bytes The new result of pix_write for type = 1 is attached. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-29 10:39 Message: thanks. should be fixed in git with rev.981527f2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…

1 0

[ pd-gem-Bugs-3445962 ] pix_writer write rgba images - osx
by SourceForge.net 30 Nov '11

30 Nov '11

Bugs item #3445962, was opened at 2011-11-30 03:15 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&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: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Nicolas Montgermont (nimon) Assigned to: Nobody/Anonymous (nobody) Summary: pix_writer write rgba images - osx Initial Comment: I must insert a [pix_rgba] before [pix_writer] to have the good image written. It seems [pix_writer] writes rgb images even if it receives yuv data. osx.6.8 gem from current git ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 06:52 Message: should be fixed in git.736f0982 ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 04:51 Message: right sorry, pix_snap converts to rgb, so forget about the last line of my last comment. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-11-30 04:07 Message: i think the expected behavior for pix_write is to convert yuv image to rgb befor recording it to the disk. ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 03:55 Message: Maybe I was not clear enough. If I use [pix_writer] just after [pix_video] I get a totally distorted image. Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv] and then [pix_writer]. It looks like [pix_writer] is not testing the format of the texture and assume it's rgb even if it's not the case. The expected behavior is to have the same result with [pix_snap]+[pix_writer] and [pix_write] ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 03:46 Message: what is the expected behaviour? i don't think you can natively write YUV-images in TIF; JPEG uses their own colorspace anyhow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…

1 0

[ pd-gem-Bugs-3445962 ] pix_writer write rgba images - osx
by SourceForge.net 30 Nov '11

30 Nov '11

Bugs item #3445962, was opened at 2011-11-30 03:15 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&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: Nicolas Montgermont (nimon) Assigned to: Nobody/Anonymous (nobody) Summary: pix_writer write rgba images - osx Initial Comment: I must insert a [pix_rgba] before [pix_writer] to have the good image written. It seems [pix_writer] writes rgb images even if it receives yuv data. osx.6.8 gem from current git ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 06:52 Message: should be fixed in git.736f0982 ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 04:51 Message: right sorry, pix_snap converts to rgb, so forget about the last line of my last comment. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-11-30 04:07 Message: i think the expected behavior for pix_write is to convert yuv image to rgb befor recording it to the disk. ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 03:55 Message: Maybe I was not clear enough. If I use [pix_writer] just after [pix_video] I get a totally distorted image. Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv] and then [pix_writer]. It looks like [pix_writer] is not testing the format of the texture and assume it's rgb even if it's not the case. The expected behavior is to have the same result with [pix_snap]+[pix_writer] and [pix_write] ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 03:46 Message: what is the expected behaviour? i don't think you can natively write YUV-images in TIF; JPEG uses their own colorspace anyhow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…

1 0

[ pd-gem-Patches-3445617 ] updated .gitgnore to ignore all build products
by SourceForge.net 30 Nov '11

30 Nov '11

Patches item #3445617, was opened at 2011-11-29 15:30 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&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: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: updated .gitgnore to ignore all build products Initial Comment: Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 06:23 Message: config.h.in is generated; but build/autoconf/Makefile is not, and that get's caught by the "Makefile" clause ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-11-30 06:12 Message: which of the files that are in their are not generated? config.h.in is perhaps the only one I can think of, but the build modifies that file, which is strange ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 06:03 Message: unfortunately it also ignores some files that are not generated ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…

1 0

[ pd-gem-Patches-3445617 ] updated .gitgnore to ignore all build products
by SourceForge.net 30 Nov '11

30 Nov '11

Patches item #3445617, was opened at 2011-11-29 15:30 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: updated .gitgnore to ignore all build products Initial Comment: Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 06:23 Message: config.h.in is generated; but build/autoconf/Makefile is not, and that get's caught by the "Makefile" clause ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-11-30 06:12 Message: which of the files that are in their are not generated? config.h.in is perhaps the only one I can think of, but the build modifies that file, which is strange ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 06:03 Message: unfortunately it also ignores some files that are not generated ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…

1 0

[ pd-gem-Patches-3445617 ] updated .gitgnore to ignore all build products
by SourceForge.net 30 Nov '11

30 Nov '11

Patches item #3445617, was opened at 2011-11-29 15:30 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: updated .gitgnore to ignore all build products Initial Comment: Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-11-30 06:12 Message: which of the files that are in their are not generated? config.h.in is perhaps the only one I can think of, but the build modifies that file, which is strange ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 06:03 Message: unfortunately it also ignores some files that are not generated ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…

1 0

[ pd-gem-Patches-3445617 ] updated .gitgnore to ignore all build products
by SourceForge.net 30 Nov '11

30 Nov '11

1 0

[ pd-gem-Bugs-3445361 ] pix_write quality not working - osx
by SourceForge.net 30 Nov '11

30 Nov '11

Bugs item #3445361, was opened at 2011-11-29 09:32 Message generated for change (Comment added) made by nimon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nicolas Montgermont (nimon) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write quality not working - osx Initial Comment: pix_write create exactly the same jpg file when specifying type = 1 or type = 99 see attached captured file (from pix_image help file) for the two quality. GEM: ver: 0.93.git 2687102 OSX 10.6.8 Image saving support: QT ---------------------------------------------------------------------- >Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 05:59 Message: right... a pity! ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 05:54 Message: i checked again, and using an apple app like "Preview", and it behaves the same. go thank apple that their strive for happy customers does not allow you to save a jpeg (using QuickTime) with "unacceptable" quality. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 03:52 Message: what is the expected behaviour? [pix_write] will request the backend to write between lossless (quality=100) and "lowest possible quality" (0). the operating system defines what "lowest" quality means. on OSX this would be "codecMinQuality" (whatever that means). [pix_write] currently does not really allow to set a quality=0 for jpeg images (since "0" automatically means: lossless TIFF), so quality=1 should be a "bit" better than "codecMinQuality". ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 00:45 Message: I can now see a difference between type=1 and type=99 but it is still very low. The image with quality = 1 is still very clean and has a certain weight. Writing the output of example/04.pix/01.image, it gives : type = 1 : 6771 bytes type = 99 : 12 928 bytes The new result of pix_write for type = 1 is attached. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-29 10:39 Message: thanks. should be fixed in git with rev.981527f2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…

1 0

[ pd-gem-Bugs-3445361 ] pix_write quality not working - osx
by SourceForge.net 30 Nov '11

30 Nov '11

Bugs item #3445361, was opened at 2011-11-29 09:32 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&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: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Nicolas Montgermont (nimon) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write quality not working - osx Initial Comment: pix_write create exactly the same jpg file when specifying type = 1 or type = 99 see attached captured file (from pix_image help file) for the two quality. GEM: ver: 0.93.git 2687102 OSX 10.6.8 Image saving support: QT ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 05:54 Message: i checked again, and using an apple app like "Preview", and it behaves the same. go thank apple that their strive for happy customers does not allow you to save a jpeg (using QuickTime) with "unacceptable" quality. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-30 03:52 Message: what is the expected behaviour? [pix_write] will request the backend to write between lossless (quality=100) and "lowest possible quality" (0). the operating system defines what "lowest" quality means. on OSX this would be "codecMinQuality" (whatever that means). [pix_write] currently does not really allow to set a quality=0 for jpeg images (since "0" automatically means: lossless TIFF), so quality=1 should be a "bit" better than "codecMinQuality". ---------------------------------------------------------------------- Comment By: Nicolas Montgermont (nimon) Date: 2011-11-30 00:45 Message: I can now see a difference between type=1 and type=99 but it is still very low. The image with quality = 1 is still very clean and has a certain weight. Writing the output of example/04.pix/01.image, it gives : type = 1 : 6771 bytes type = 99 : 12 928 bytes The new result of pix_write for type = 1 is attached. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-29 10:39 Message: thanks. should be fixed in git with rev.981527f2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&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 November 2011