GEM-dev November 2009

gem-dev@lists.iem.at

13 participants
20 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

Way to get gemframebuffer back onto main memory for pix_ operations?
by ben＠ekran.org 29 Nov '09

29 Nov '09

Hey all, I'm rendering data into a framebuffer, but want to be able to pix_add that texture with a live video input. How can I get a gemframebuffer image from texture space into pix_ space??? Thanks, B. Bogart

6 9

(GEM) color invasion
by Matteo Sisti Sette 29 Nov '09

29 Nov '09

Hi, Consider the following patch, where the [gemhead] is connected to all [separator]s (I'm not so good with ascii-art): [gemhead] ... [separator] [separator] [separator] | | | [color 1 0 0] | | | | | [translateXYZ...] [translateXYZ...] | | | | [square 2] [square 2] [square 2] (with suitable values in translations so that all squares are visible) The 'issue' is that all squares are red. Is it normal/expected??? I would expect only the square in the left chain to be red. Is it that [separator] only separates certain things and does not separate others? If so, where can I find a list (or a rule) that tells me what it separates and what not? You may suggest that I can create separate [gemhead]s, but if I want the resulting scene( to be rendered into a texture all chains must be "children" of a single [gemframebuffer] and so of a single [gemhead] and I can only "separate" them with [separator]s. So up to now my only solution is to put a [color 1 1 1] on every object that I don't want to be coloured, but that's a bit unhandy.... -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

2 4

Blending mode directly on objects, not pixes?
by Matteo Sisti Sette 29 Nov '09

29 Nov '09

Hi, Now, I don't know if this is possible at all. Suppose I have a [rectangle] (or whatever primitive indeed) with a texture, and something behind the rectangle. Is it possible to have the rectangle "blend" with the background with some blending mode (such as add, multiply, etc)? (without having to render all the rest of the scene except the rectangle into a texture via gemframebuffer, and then blending the two textures with pix_add and friends)??? Isn't it a matter of shaders? I guess it could be achieved using openGL functions... but is there a "simple" way? Thanks m. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

4 23

[ pd-gem-Bugs-2905446 ] [DOCUMENTATION] pix_mask documentation error
by SourceForge.net 29 Nov '09

29 Nov '09

Bugs item #2905446, was opened at 2009-11-28 21:26 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2905446&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: Accepted Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: [DOCUMENTATION] pix_mask documentation error Initial Comment: The help-patch for pix_mask contraddicts itself: statement 1: "Where ever the mask has a colored pixel, the alpha component of the other image will be set to 0 (transparent)." statement 2: "Basically, the luminance-value of the right pix will become the alpha-value of the left pix." These sentences obviously contraddict each other. According to statement 1, non-zero luminance would produce zero alpha, while according to statement 2 the opposite is true. Also, according to statement 1 at most 2 values of alpha would be possible (zero and non-zero, presumably 1), while according to statement 2, intermediate values in the range 0..1 seem to be possible. I think the correct one is (2). ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-11-29 00:06 Message: fixed with revision 3015 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2905446&group_…

1 0

error: invalid conversion from 'GLint*' to 'long int*'
by Hans-Christoph Steiner 29 Nov '09

29 Nov '09

This 10.4 build issue seems to be fixed in trunk (pd-devel builds include Gem from trunk) but not for the 0.92 branch (pd-extended builds use the 0.92 branch). .hc Begin forwarded message: > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 28 Nov 2009 04:07:17 -0500 (EST) > From: pd(a)macosx104-i386.idmi.poly.edu (Pd Build User) > Subject: [PD-cvs] autobuild: pd-extended macosx104-i386 2009-11-28 > 03.15.44 > To: pd-cvs(a)iem.at > Message-ID: <20091128090717.899E2394278(a)macosx104-i386.localhost> > > last 20 errors ---------------------------------------- > GemPBuffer.cpp:270: error: invalid conversion from 'GLint*' to 'long > int*' > GemPBuffer.cpp:270: error: initializing argument 2 of 'CGLError > CGLGetVirtualScreen(_CGLContextObject*, long int*)' > GemPBuffer.cpp:272: error: invalid conversion from 'GLint*' to 'long > int*' > GemPBuffer.cpp:272: error: initializing argument 3 of 'CGLError > CGLChoosePixelFormat(const CGLPixelFormatAttribute*, > _CGLPixelFormatObject**, long int*)' > GemPBuffer.cpp:283: error: invalid conversion from 'GLint*' to 'long > int*' > GemPBuffer.cpp:283: error: initializing argument 2 of 'CGLError > CGLGetVirtualScreen(_CGLContextObject*, long int*)' > GemPBuffer.cpp:307: error: invalid conversion from 'GLint*' to 'long > int*' > GemPBuffer.cpp:307: error: initializing argument 2 of 'CGLError > CGLGetVirtualScreen(_CGLContextObject*, long int*)' > ERROR: module is write only > rsync error: syntax or usage error (code 1) at main.c(710) > [sender=3.0.3] > rsync error: error in rsync protocol data stream (code 12) at / > SourceCache/rsync/rsync-35.2/rsync/io.c(452) [receiver=2.6.9] > last 5 lines ---------------------------------------- > Uploading > ERROR: module is write only > rsync error: syntax or usage error (code 1) at main.c(710) > [sender=3.0.3] > rsync: connection unexpectedly closed (4 bytes received so far) > [receiver] > rsync error: error in rsync protocol data stream (code 12) at / > SourceCache/rsync/rsync-35.2/rsync/io.c(452) [receiver=2.6.9] > > the full logfile - if it has been succesfully uploaded - can be > viewed at: > http://autobuild.puredata.info/auto-build/2009-11-28/logs/2009-11-28_03.15.… > > > > ------------------------------ > > _______________________________________________ > Pd-cvs mailing list > Pd-cvs(a)iem.at > http://lists.puredata.info/listinfo/pd-cvs > > > End of Pd-cvs Digest, Vol 57, Issue 21 > ************************************** ---------------------------------------------------------------------------- If you are not part of the solution, you are part of the problem.

2 1

[ pd-gem-Bugs-2905446 ] [DOCUMENTATION] pix_mask documentation error
by SourceForge.net 28 Nov '09

28 Nov '09

Bugs item #2905446, was opened at 2009-11-28 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=2905446&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: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: [DOCUMENTATION] pix_mask documentation error Initial Comment: The help-patch for pix_mask contraddicts itself: statement 1: "Where ever the mask has a colored pixel, the alpha component of the other image will be set to 0 (transparent)." statement 2: "Basically, the luminance-value of the right pix will become the alpha-value of the left pix." These sentences obviously contraddict each other. According to statement 1, non-zero luminance would produce zero alpha, while according to statement 2 the opposite is true. Also, according to statement 1 at most 2 values of alpha would be possible (zero and non-zero, presumably 1), while according to statement 2, intermediate values in the range 0..1 seem to be possible. I think the correct one is (2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2905446&group_…

1 0

[ pd-gem-Bugs-2887417 ] missing QTCF.DLL
by SourceForge.net 28 Nov '09

28 Nov '09

Bugs item #2887417, was opened at 2009-10-27 20:46 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2887417&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: Works For Me Priority: 5 Private: No Submitted By: megalegoland (megalegoland) Assigned to: Nobody/Anonymous (nobody) Summary: missing QTCF.DLL Initial Comment: Hello, I had to put QTCF.dll in pd/bin for using Gem in last release of pd-extended, and then it gives this pretty message on the console: GEM: Graphics Environment for Multimedia GEM: ver: 0.91.3 'tigital' GEM: compiled: Jan 22 2009 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: James Tittle GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage http://gem.iem.at/ GEM: bug-tracker http://sourceforge.net/projects/pd-gem/ GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for SIMD architecture: SSE2 MMX GEM: using SSE2 optimization Gem Man: QT init OK instead of an orwellian error message automatically sent to bigswifty ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-11-28 17:05 Message: during a workshop i had some participant who had no QuickTime installed on their vista machines. (using PdX but the latest Gem release) everything worked as expected (just used the plain installer from http://gem.iem.at; QT could obviously be not used, but the rest worked) i suspect this to be a problem with the Gem that comes with PdX. please consider upgrading. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-10-27 21:49 Message: oh, and which version of windows are you using? did/do you have quicktime installed? if so, which version? ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-10-27 21:48 Message: what happened without the QTCF.dll? did Gem refuse to load (which it shouldn't) or did it only complain about no-quicktime-support (which it should) does the same pproblem persist if you use the gem-0.92 release found at http://gem.iem.at (or here at the sourceforge in the download section) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2887417&group_…

1 0

pix_snap CPU consumption question
by Matteo Sisti Sette 27 Nov '09

27 Nov '09

Hi, I have a [pix_snap 0 0 2400 2400] 'under' a [gemframebuffer] of the same size. I think it would make no difference if there wasn't the [gemframebuffer] and the [gemwin] had the same size (namely 2400 by 2400). I attach the patch I'm using, though a much simpler test patch could be used to illustrate the question. Now, I am observing the following: - despite the large size of the framebuffer, even when pix_snap is continuously receiving the gemlist, CPU consumption is low, not significantly higher than the same patch with a smaller window size - When I send one bang to pix_snap (by enabling the spigot above it which immediately disables itself), so that it takes a snapshot, then CPU consumption increases, and then it stays high forever!!! I'm not surprised by the sudden CPU consumption increase: I'm surprised by the fact that then it doesn't immediately go back to its previous level: cpu consumption stays high, as if, starting from the moment the firse snaphot is taken, pix_snapshot had to continuously process the picture or something. Is it normal??? I don't really understand why there should be a difference between the cpu consumption before and after the moment the snapshot is taken. I could understand a temporary increase _during_ the moment the snapshot is taken. If I disconnect the left inlet of pix_snapshot so it does not receive the gemlist anymore, then CPU consumption drops again. That wouldn't be that much surprising if it wasn't that after disconnecting the inlet of pix_snap, the image is still displayed. So, it means pix_snap does not need to "output" the image continuously (no surprise here either), but then, what is it continuously doing when receiving the gemlist and NOT capturing, that makes it consume CPU?? It seems that, whatever it is, it is useless. Is it a bug? Or is there an explanation? (well the two things are not mutually exclusive) -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com #N canvas 9 18 1246 745 12; #X obj 788 659 gemwin; #X msg 740 558 dimen 800 600 \, create \, 1; #X msg 796 608 destroy; #X obj 100 194 gemframebuffer; #X obj 166 114 loadbang; #X obj 99 292 t a a a a; #X obj 99 251 translateXYZ 0 0 -4; #X obj 661 540 separator; #X obj 596 680 pix_texture; #X obj 596 716 square 4 4; #X obj 351 458 separator; #X obj 349 503 t a b; #X obj 386 539 spigot; #X obj 383 572 t b b; #X obj 432 510 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 472 547 0; #X obj 344 693 pix_texture; #X obj 408 391 s mainchain; #X obj 140 366 separator; #X obj 160 448 spigot; #X obj 210 425 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 250 462 0; #X obj 126 548 t a b; #X obj 126 621 t b a; #X obj 45 491 loadbang; #X msg 19 519 file aaa 95; #X obj 42 18 gemhead 50; #X obj 1092 507 gemhead 52; #X obj 1101 667 pix_texture; #X obj 1095 707 square 4 4; #X obj 1044 137 r mainchain; #X obj 1043 206 pix_video; #X obj 1040 236 pix_info ----------; #X obj 1079 293 -; #X obj 1078 324 / 2; #X obj 1038 359 pix_crop; #X obj 1044 170 separator; #X obj 1036 386 pix_texture; #X obj 1121 423 s videotexture; #X obj 378 13 r mainchain; #X obj 381 66 separator; #X obj 379 93 pix_texture; #X obj 460 60 r videotexture; #X obj 607 8 r mainchain; #X obj 617 71 separator; #X obj 618 101 pix_texture; #X obj 699 68 r videotexture; #X obj 354 193 r mainchain; #X obj 354 252 separator; #X obj 355 273 pix_texture; #X obj 436 240 r videotexture; #X obj 593 201 r mainchain; #X obj 592 255 separator; #X obj 594 281 pix_texture; #X obj 675 248 r videotexture; #X obj 337 350 square 2 2; #X obj 361 140 translateXYZ -2 -2 0; #X obj 600 148 translateXYZ 2 -2 0; #X obj 337 320 translateXYZ -2 2 0; #X obj 576 328 translateXYZ 2 2 0; #X obj 360 167 square 2 2; #X obj 601 177 square 2 2; #X obj 576 356 square 2 2; #X obj 349 43 spigot; #X obj 326 5 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1 ; #X obj 616 43 spigot; #X obj 718 1 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1 ; #X obj 358 224 spigot; #X obj 460 188 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 608 232 spigot; #X obj 710 196 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 161 487 t a b; #X obj 41 45 t a a; #X obj 101 91 spigot; #X obj 13 172 spigot; #X obj 153 15 r recmode; #X obj 35 123 * -1; #X obj 34 147 + 1; #X obj 1090 588 spigot; #X obj 1112 557 r recmode; #X obj 970 435 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 970 455 s recmode; #X msg 166 143 dimen 2400 2400; #X obj 126 589 pix_snap 0 0 2400 2400; #X obj 128 649 pix_write 0 0 2400 2400; #X obj 918 371 loadbang; #X msg 920 404 1; #X obj 346 663 pix_snap 0 0 2400 2400; #X obj 544 420 r recmode; #X obj 545 447 select 1 0; #X msg 511 484 2400 2400; #X msg 478 487 0 0; #X msg 563 536 600 600; #X msg 508 537 100 0; #X text 944 558 <- 1)HERE; #X text 742 -2 <- 2) any of these 4 \, or all; #X text 457 504 <- 3) TAKE THE PICTURE: observe cpu increase; #X text 740 13 <- 4) (opt) turn them off if you want to see the snapshot ; #X text 352 608 <- 5) if you disconnect this \, CPU consumption drops ; #X text 393 625 but the image is still displayed; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 6 0; #X connect 3 1 28 1; #X connect 4 0 82 0; #X connect 5 0 18 0; #X connect 5 1 10 0; #X connect 5 2 17 0; #X connect 5 3 7 0; #X connect 6 0 5 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 10 0 11 0; #X connect 11 0 87 0; #X connect 11 1 12 0; #X connect 12 0 13 0; #X connect 13 0 87 0; #X connect 13 1 15 0; #X connect 14 0 12 1; #X connect 15 0 14 0; #X connect 16 1 8 1; #X connect 18 0 19 0; #X connect 19 0 71 0; #X connect 20 0 19 1; #X connect 21 0 20 0; #X connect 22 0 83 0; #X connect 22 1 83 0; #X connect 23 0 84 0; #X connect 23 1 84 0; #X connect 24 0 25 0; #X connect 25 0 84 0; #X connect 26 0 72 0; #X connect 27 0 78 0; #X connect 28 0 29 0; #X connect 30 0 36 0; #X connect 31 0 32 0; #X connect 32 0 35 0; #X connect 32 1 33 0; #X connect 32 2 33 1; #X connect 32 2 35 1; #X connect 32 2 35 2; #X connect 33 0 34 0; #X connect 34 0 35 3; #X connect 35 0 37 0; #X connect 36 0 31 0; #X connect 37 1 38 0; #X connect 39 0 63 0; #X connect 40 0 41 0; #X connect 41 0 56 0; #X connect 42 0 41 1; #X connect 43 0 65 0; #X connect 44 0 45 0; #X connect 45 0 57 0; #X connect 46 0 45 1; #X connect 47 0 67 0; #X connect 48 0 49 0; #X connect 49 0 58 0; #X connect 50 0 49 1; #X connect 51 0 69 0; #X connect 52 0 53 0; #X connect 53 0 59 0; #X connect 54 0 53 1; #X connect 56 0 60 0; #X connect 57 0 61 0; #X connect 58 0 55 0; #X connect 59 0 62 0; #X connect 63 0 40 0; #X connect 64 0 63 1; #X connect 65 0 44 0; #X connect 66 0 65 1; #X connect 67 0 48 0; #X connect 68 0 67 1; #X connect 69 0 52 0; #X connect 70 0 69 1; #X connect 71 0 22 0; #X connect 71 1 21 0; #X connect 72 0 74 0; #X connect 72 1 73 0; #X connect 73 0 3 0; #X connect 74 0 5 0; #X connect 75 0 73 1; #X connect 75 0 76 0; #X connect 76 0 77 0; #X connect 77 0 74 1; #X connect 78 0 28 0; #X connect 79 0 78 1; #X connect 80 0 81 0; #X connect 82 0 3 0; #X connect 83 0 23 0; #X connect 85 0 86 0; #X connect 86 0 80 0; #X connect 87 0 16 0; #X connect 88 0 89 0; #X connect 89 0 90 0; #X connect 89 0 91 0; #X connect 89 1 92 0; #X connect 89 1 93 0; #X connect 90 0 87 2; #X connect 91 0 87 1; #X connect 92 0 87 2; #X connect 93 0 87 1;

1 0

Strange errors in the console
by Jack 27 Nov '09

27 Nov '09

I got these errors in the console when i send the message [open ~/capture.png( to [pix_image] : error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage error: GEM: Someone sent a bogus pointer to refreshImage [pix_image]: thread loaded image: /home/jack/capture.png What does it mean ? Thx. ++ Jack

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 2009