GEM-dev April 2009

gem-dev@lists.iem.at

13 participants
23 discussions

TIFF files from pix_buffer (and others?) missing some "standard" tags?
by B. Bogart 06 Aug '10

06 Aug '10

Hey all, I've had trouble loading some TIFs generated in pd/Gem in PIL (python imaging). I asked on the list and it seems PIL expects some particular TIF tags being set in order to recognize the image. I think it can only be an improvement to add these tags so that tifs generated in pd/Gem can be loaded by as many applications as possible. The attachment contains the specific tags. Thanks, B. Bogart

3 10

model UV...
by sebastian pirch 07 Sep '09

07 Sep '09

hi IOhannes! in 1st place, THANKS for implementing this feature ;) you realy make me happy. i installed your experimental win build and it works great, when i add the gem directory to file/paths. only when i do so, pd crashes when i load a .mov using pix_film or pix_movie. when i remove the Gem path from file/paths again, pix_film and pix_movie work fine again, - but no more uv coordinates...is it a bug? or am i doing something wrong? im using pd extended 0.40.3 on winXP thanks for doing all this sebastian IOhannes m zmoelnig wrote: > hi. > > i have just added UV-texture support to [model]. > > now, UV-texcoords are automatically applied if present in the model > (with a fallback to the old-standard "linear" texmaps); you can manually > select UV-tex via [texture 2( (uÃ¤h) > > > > please test whether this change has broken something with the other > (linear/spheremap) texturing, esp. if you have additionally used > [pix_coordinates] > > fgmSDR > IOhannes -- www.3rd-eye.at Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

5 15

[ pd-gem-Bugs-2782461 ] circle looks weird with large line widths
by SourceForge.net 27 Apr '09

27 Apr '09

Bugs item #2782461, was opened at 2009-04-27 21:25 Message generated for change (Tracker Item Submitted) made by claudiusmaximus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2782461&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: circle looks weird with large line widths Initial Comment: Seems the line width is drawn either horizontally or vertically instead of normal to the circle. Not sure if this is to be expected from OpenGL, or if it's a Gem bug, or a driver bug. Tested with pd-0.41.4 gem-0.91.1 fglrx ati catalyst 9.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2782461&group_…

1 0

[ pd-gem-Feature Requests-2612731 ] glsl_geometry
by SourceForge.net 27 Apr '09

27 Apr '09

Feature Requests item #2612731, was opened at 2009-02-18 13:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2612731&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 Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: glsl_geometry Initial Comment: it would be great to add a glsl_geometry object to load geometry shader. It should be compatible with already existing glsl_vertex and glsl_fragment object... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2612731&group_…

7 35

[ pd-gem-Bugs-2782081 ] pix_write aborts pd when disk is full
by SourceForge.net 27 Apr '09

27 Apr '09

Bugs item #2782081, was opened at 2009-04-27 11:38 Message generated for change (Tracker Item Submitted) made by claudiusmaximus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2782081&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: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: pix_write aborts pd when disk is full Initial Comment: If you fill the disk with pix_write (quite easy when saving in TIFF format), pd aborts. error: ImageMagick: /mnt/wednesday/in/rec/img60413.tif: Write error at scanline 456. `TIFFAppendToStrip' pd: magick/exception.c:932: ThrowMagickExceptionList: Assertion `exception->signature == 0xabacadabUL' failed. (then pd aborts) A fix would ideally let the pd patch know something went wrong so it could turn off image saving or quit by itself or whatever it wants to do. Versions: Gem-0.91.1-2 and pd-0.41.4 from the pure:dyne repository. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2782081&group_…

1 0

[ pd-gem-Bugs-2780728 ] error: too many files open
by SourceForge.net 24 Apr '09

24 Apr '09

Bugs item #2780728, was opened at 2009-04-24 19:52 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2780728&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: error: too many files open Initial Comment: when opening files via the "open" patch on the fly in pd, it fills up the memory until it can't open any new files anymore, and even doesn't allow u to save the patch, due to no memory available anymore. experienced the problem with pix_multiimage and pix_film under the following working specs: os: winXP Service Pack 3 PD: pd-extended ver. 0.40.3 gem: gem 0.91-3-W32-i686 imagetype: .tiff with alpha video: .avi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2780728&group_…

1 0

problem: too many files loaded solved(kinda)
by johann scholz 24 Apr '09

24 Apr '09

hi there, finally fixed the problem with loads of help from one of my teachers(actually he fixed it)! now i am able to sort of preload the image sequences for the pix_multiimage object, i didn't quite figured it all out how it works, but i would gladly share the patch if someone is interested..... to be honest the "too many files problem" isn't really solved i can preload the sequences and so they won't be loaded again and again, but i bet there is a limit of files i can preload too, so i'll push it to the max, to see how deep the rabbit hole really goes :) greets johann

2 2

PD Mem leaks WAS crash (memory leak?) with zexy?
by B. Bogart 24 Apr '09

24 Apr '09

Hello all, After more digging it appears that zexy is not causing a leak, but was just the last process to request memory. After using valgrind for some time it appears there are leaks all over the place. The reason I'm having trouble narrowing things down is simply that there are leaks in many different places. I've attached the full valgrind log, but here are some high(low?)lights: I was worried about my own gphoto code (not very well tested) which seems to loose about 41,968 bytes. This makes the following numbers much more worrisome: ==24879== 262,140 bytes in 1 blocks are definitely lost in loss record 220 of 229 ==24879== at 0x47F2D6E: malloc (vg_replace_malloc.c:207) ==24879== by 0xADB5A06: (within /usr/lib/libGL.so.173.14.09) ==24879== 2,142,184 (2,134,057 direct, 8,127 indirect) bytes in 956 blocks are definitely lost in loss record 225 of 229 ==24879== at 0x47F0E22: calloc (vg_replace_malloc.c:397) ==24879== by 0x80AD86D: getbytes (m_memory.c:24) ==24879== by 0xA7D6FFF: gemwin::createMess(_symbol*) (gemwin.cpp:141) ==24879== by 0xA7D70A6: gemwin::createMessCallback(void*, _symbol*) (gemwin.cpp:702) ==24879== by 0x80AA352: pd_typedmess (m_class.c:730) ==24879== 12,288,190 bytes in 10 blocks are definitely lost in loss record 228 of 229 ==24879== at 0x47F2D6E: malloc (vg_replace_malloc.c:207) ==24879== by 0x4D2EAA1: flext_root_single::operator new(unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0x4D2F2DC: operator new[](unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0xA7CA4A0: imageStruct::allocate(unsigned) (GemPixUtil.cpp:129) ==24879== by 0xA7C6D24: jpegImage2mem(char const*) (GemPixImageLoad.cpp:560) ==24879== by 0xA7C7999: image2mem(char const*) (GemPixImageLoad.cpp:192) ==24879== by 0xA8343F0: pix_buffer::openMess(_symbol*, int) (pix_buffer.cpp:201) ==24879== by 0xA833D74: pix_buffer::openMessCallback(void*, _symbol*, float) (pix_buffer.cpp:345) ==24879== by 0x80AA352: pd_typedmess (m_class.c:730) ==24879== 2,286,470,533 bytes in 1,849 blocks are possibly lost in loss record 229 of 229 ==24879== at 0x47F2D6E: malloc (vg_replace_malloc.c:207) ==24879== by 0x4D2EAA1: flext_root_single::operator new(unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0x4D2F2DC: operator new[](unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0xA7CA4A0: imageStruct::allocate(unsigned) (GemPixUtil.cpp:129) ==24879== by 0xA7C6D24: jpegImage2mem(char const*) (GemPixImageLoad.cpp:560) ==24879== by 0xA7C7999: image2mem(char const*) (GemPixImageLoad.cpp:192) ==24879== by 0xA862149: pix_image::openThread(void*) (pix_image.cpp:167) ==24879== by 0x48464BF: start_thread (in /lib/i686/cmov/libpthread-2.7.so) ==24879== by 0x4C8C6DD: clone (in /lib/i686/cmov/libc-2.7.so) I'm cross-posting to gem-dev since a few of these big ticket leaks appear to be in Gem. I'm currently testing with pd-0.39-2 (as I was able to use this in a previous installation without any noticeable leakage). I also tried pd-0.40-3 and pd-0.42-4. I'm currently using r 2750 of Gem from SVN. I also tried the current version of Gem from SVN, but that did not appear to solve the issue. Any any of these definite, or possible leaks known and I'm just missing the fix? Any recommendations on how I can minimize the effect of these leaks? All this has made me think perhaps an installation version of PD+crucial externals would be useful, that is one that is tested for extremely long periods and does not change very often. Any advice appreciated. Thanks, B. Bogart

1 0

[ pd-gem-Bugs-2779564 ] pix_chroma_key uses RGB values from 0-255, not 0-1
by SourceForge.net 23 Apr '09

23 Apr '09

Bugs item #2779564, was opened at 2009-04-23 10:39 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2779564&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: pix_chroma_key uses RGB values from 0-255, not 0-1 Initial Comment: For whatever reason, [pix_chroma_key] uses RGB values between 0 and 255 rather than 0 and 1 like the rest of Gem. http://lists.puredata.info/pipermail/gem-dev/2009-04/003952.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2779564&group_…

1 0

pix_chroma_key RGB values
by Hans-Christoph Steiner 23 Apr '09

23 Apr '09

Hey, I am just figuring out pix_chroma_key right now, and it took me a while because the RGB values are 0-255, not the Gem standard 0-1. Any particular reason for this? Its not documented in the help patch, either the why or the fact that it is 0-255. It be very nice to have all of Gem use 0-1, especially since it does almost everywhere. .hc ---------------------------------------------------------------------------- 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf

2 1

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 2009