[PD-dev] [GEM] cvs update *.*

IOhannes zmoelnig zmoelnig at iem.kug.ac.at
Mon Mar 10 09:17:56 CET 2003


chris clepper wrote:
>> 3. [separator]
>> hopefully i have fixed the bug that kept it crashing when it was used 
>> with images.
> 
> as you note in the source, there is now a memory leak in the separator 
> object.  i have yet to figure out what the problem is, but calling free 
me too...
> on that pointer should cause a warning not a crash (it doesn't segfault 
> on OSX).  maybe a linux bug??

i'd hate to admit this.
but anyhow, it crashed on windows too, so maybe it's a win/lin-bug.
the memory leak should of course not be considered final.

>> 5. [pix_crop]
>> i thought i had checked this in long ago (but obviously had not, and 
>> now i have found the original code again)
>> it takes sub-images of images (withan offset x/y pair and a dimen w/h 
>> pair)
> 
> 
> i was thinking of making an object that combined both of these functions 
> so one could 'cut up' and image and process each part differently.  
> maybe it would be called [pix_split] or [pix_cut(up)] or [pix_slice]?  


well, [pix_crop] (i took the name someone suggested on the list), does 
buffering of the subimage anyhow. So you already have the functionality 
you need.


> basically the user would send messages selecting the area to output and 
> a for loop would move the pixels around.  it would be nice to have N 
> number of outlets for this object, but i'm not sure how possible that it 
> with GEM.

this is possible, but you have to duplicate chunks of the GemBase-class.

> 
> i have also written a mode of processing called processSubImage() that 
> only processes a user specified area of the image.  it's probably not 
> practical to add this to each and every object so maybe [pix_split] is a 
> better way to go....
when applying more than one effect to subimages, processSubImage() might 
not even be faster. but of course, you could do beautiful things.
Even more beautiful things could be done if we had a separate "selection 
channel" (i disused the alpha-channel for this purpose in [pix_a_2grey])
But of course, this is going to be very slow.

Anyhow, now we have a secondary colour model that does not support 
alpha, we probably should change the iamgeStruct to support such 
selection channel.

>> 6. what else ?
>> a minor configure-script update
>> + "cannot remember"
> 
> there were some updates to GemBase with the ultra-informative log entry 
> of '???'.  what happened there?
well, i guess,  '???' means: "cannot remember"
now that i have looked at GemBase.* again, i'm quite sure that i just 
had a look at the code, accidentally hit a key, saved the file and 
commited it as "modified".


mfg.a.sdr
IOhannes





More information about the Pd-dev mailing list