GEM-dev August 2009

gem-dev@lists.iem.at

12 participants
29 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

Fwd: Gem on :0.1
by Miha Tomšič 31 Aug '09

31 Aug '09

Hello! I managed to get Gem window on :0.1. The problem is in hints.shared sharedList: when creating Gem window on :0.0 hints.shared is set and it stays the same when later I try to create Gem window on :0.1 which results in BadMatch. I can create Gem window on :0.1 if this is the first thing after loading Gem. I had to bypass hints.fullscreen & hints.display to get fullscreen on :0.1. I don't have the time at the moment to investigate deeper because I would first like to finish the project I am working on :) Thanks and take care, Miha ---------- Forwarded message ---------- From: Miha Tomšič <miha.tomsic(a)gmail.com> Date: Wed, Aug 26, 2009 at 7:47 AM Subject: Gem on :0.1 To: pd-list(a)iem.at Hello! I would like to open Gem window on second screen (:0.1). I am using nvidia proprietary on fedora 11 and it works fine on first screen (:0.0). When issuing [create :0.1( to [gemwin] Gem gives me the following error: GEM: creating gem-window on display :0.1 error: GEM: fullscreen not available on remote display error: GEM-Xwin: BadMatch (invalid parameter attributes) error: GEM: Could not create rendering context error: GEM-Xwin: GLXBadContext error: GEM: Unable to create window error: [gemwin]: no window made glxinfo for both screens says: ------------- display: :0 screen: 0 direct rendering: Yes ------------- display: :0 screen: 1 direct rendering: Yes ------------- There might be a problem with second screen because KDE 4.2 is not running any window manager on second screen in separate X display. Is that the problem? Does anybody know how to run manager on both screens? Thanks in advance, Miha

1 0

Playing HDV video with frame accurate seeking on Linux
by B. Bogart 26 Aug '09

26 Aug '09

Hey all, I'm doing a new version of "Step and Repeat" and want to do the video in HD. I'm already shot HDV footage, which plays very well in mplayer, but not so well in Gem. I need to do frame seeking, so I've taken my original HDV (m2t) video and converted into a large mpeg2 with 1 frame GOPs and loading the TOC. Everything plays fine, but the playback is extremely slow. What are the best options for HDV playback on linux? I could lower the resolution, and load all frames into a pix_buffer. I could lower the resolution and just play the file. Looks like there is no "RAM" message to load the whole file into RAM and playing from RAM on linux? The target machine is a AMD dualcore 4500+ (or something close). Any advice appreciated. Anyone know if you can do frame-accurate mpg seeking in mplayer? Thanks, B.

5 7

[ pd-gem-Feature Requests-2844090 ] get rid of upside down images
by SourceForge.net 25 Aug '09

25 Aug '09

Feature Requests item #2844090, was opened at 2009-08-25 09:59 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2844090&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: Open Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: get rid of upside down images Initial Comment: for performance reasons, Gem handles images with the origin in the lower-left corner (standard openGL image orientation) and images originating in the upper-left corner (standard for most(?) video codecs). this makes code unnecessarily complicated, as textuing has to take care of both types of images. since most video-decoding and -capturing APIs will naturally (for performance reasons) return images originiating in the upper-left corner, it would be good to make this the default orientation and get rid of standard-openGL-originating images alltogether. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-08-25 10:01 Message: the only problem i can see with getting rid of standard-openGL-orientation is when it comes to dealing with generated textures ([pix_snap], [pix_snap2tex], [gemframebuffer]) there must be some way to rotate these on the GPU... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2844090&group_…

1 0

[ pd-gem-Feature Requests-2844090 ] get rid of upside down images
by SourceForge.net 25 Aug '09

25 Aug '09

Feature Requests item #2844090, was opened at 2009-08-25 09:59 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2844090&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: Open Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: get rid of upside down images Initial Comment: for performance reasons, Gem handles images with the origin in the lower-left corner (standard openGL image orientation) and images originating in the upper-left corner (standard for most(?) video codecs). this makes code unnecessarily complicated, as textuing has to take care of both types of images. since most video-decoding and -capturing APIs will naturally (for performance reasons) return images originiating in the upper-left corner, it would be good to make this the default orientation and get rid of standard-openGL-originating images alltogether. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2844090&group_…

1 0

[ pd-gem-Bugs-2844089 ] model, texturing and flipped images
by SourceForge.net 25 Aug '09

25 Aug '09

Bugs item #2844089, was opened at 2009-08-25 09:53 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2844089&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: IOhannes m zmlnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: model, texturing and flipped images Initial Comment: the UV-texturing mode of [model] (which is the default) does not work with upsidedown images . instead the texture will appear as if it had only 1 dimension. this happens on OSX, with the example posted to the gem-dev mailing list http://lists.puredata.info/pipermail/gem-dev/attachments/20090126/9968a85d/… and was initially reported by marius workaround: insert [pix_flip] before [pix_texture] technical background: upsidedown images are images with the origin in the upper-left corner as opposed to openGL-pixes which origin in the lower-left corner; in Gem these might appear on various pix-sources (e.g. all sources on OS-X; most video codecs,...) where their orientation is not corrected for performance reasons; instead an upsidedown flag is passed along with the image, in order to make the final of the image work "correctly" (by flipping the image using GPU) unfortunately this doesn't work (yet?) with complex geos like models. what's more, [model] just uses the 3rd texcoord from the GemState, which is - for non-upside down images - (w/h) (or 1/1 on normalized coordinates), whereas for upside-down images it is (w/0) (the 2nd texcoord would be (w/h)); that's why one dimension seems to be missing. why does [pix_flip] help: [pix_flip] will get the orientation of animage right; if an image is reported to be upside-down, pix_flip will flip the image around it's horizontal axis and clear the upside-down flag. therefore the problem with upside-down images can be fixed by inserting [pix_flip] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2844089&group_…

1 0

[ pd-gem-Bugs-2824356 ] pix_flip doesn't behave like in the helpfile on os x
by SourceForge.net 25 Aug '09

25 Aug '09

Bugs item #2824356, was opened at 2009-07-20 16:14 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2824356&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: max (maxn) Assigned to: Nobody/Anonymous (nobody) Summary: pix_flip doesn't behave like in the helpfile on os x Initial Comment: pix_flip flips both directions by default and when sent the "none" message on os x. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-08-25 02: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: 2009-08-10 20:25 Message: ah, the helpfile uses [pix_draw] which behaves wrongly. should be fixed now (and [pix_draw] should go away entirely ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-07-22 19:32 Message: does this mean that "both" and "none" behave identical? do the other options work correctly? if it is behaving differently from the helpfile, does this mean that it works correctly in the helpfile? (just to make sure: you don't have rotated the image, do you?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2824356&group_…

1 0

[ pd-gem-Feature Requests-2808401 ] pix_buffer_filmopen should report # of frames and size
by SourceForge.net 25 Aug '09

25 Aug '09

Feature Requests item #2808401, was opened at 2009-06-18 14:02 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2808401&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 Priority: 5 Private: No Submitted By: max (maxn) Assigned to: Nobody/Anonymous (nobody) Summary: pix_buffer_filmopen should report # of frames and size Initial Comment: it would be very useful if pix_buffer_fimopen could report frame numbers and size of the loaded movie just like fpix_film does. and while at it: maybe also report with a bang when it's finished loading. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-08-25 02: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: 2009-08-10 19:41 Message: the patch (submitted on the list or so) has made it into svn ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-06-22 17:28 Message: since [pix_buffer_filmopen] is implemented as a pdpatch, i would welcome it if you could implement the wanted functionality and provide the patch here ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2808401&group_…

1 0

[ pd-gem-Bugs-2842959 ] [print( message to [gemwin] may crash
by SourceForge.net 23 Aug '09

23 Aug '09

Bugs item #2842959, was opened at 2009-08-23 10:06 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2842959&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: IOhannes m zmlnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: [print( message to [gemwin] may crash Initial Comment: sending a [print( message to [gemwin] will usually display a lot of information about the openGL system (like driver-version) however, if no openGL-context has been established yet (e.g. because no one [create(d a window yet), this might crash. the reason is that glGetString() crashes. the function pointer is NOT set to NULL. this happened with current svn on debian, while testing indirect rendering on my eee (using mesa on a i945GME) proposed fix: use a static variable that indicates whether the context has been initialized properly and don't call glGetString() unless this has happened... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2842959&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 August 2009