[Gimp-developer] "partition decay" anyone?
I came across this nice example of "decay" on a sign a few days ago (http://pages.quicksilver.net.nz/pepe/no.jpg), and thought it would be nice if a plugin would be able to generate such random patterns automatically. Does anyone knows about such a plugin, or anything close? Can someone suggest the theory behind such a random process ? -Thanks, Joseph ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Me: >> (Raphael's plan has them implemented as plug-ins, but I think that's too >> awkward.) Sven: > What is akward about it? Passing, say, an ExifData struct to a plug-in is awkward. Calling a function and giving it a pointer is simpler, and much faster too. And then there's all the extra baggage of registering a plug-in etc. Sven: > The JPEG plug-in would have to change the orientation tag if it's > rotating the image on load, wouldn't it? It would have to do that > before calling gimp_metadata_store_exif(). It can do that if it wants to, but there is no requirement. The orientation needs to be set to "top-left" when an image is saved, but it doesn't really matter whether the change is made upon loading or upon saving. If nothing else, doing it on saving prevents the user from setting things incorrectly in the metadata editor. Me: > gimp_metadata_store_exif() serializes the exif data and attaches it to > the image as an "exif-data" parasite. > > gimp_metadata_generate_exif() extracts the contents of the "exif-data" > parasite and deserializes them. Sven: > Excuse my ignorance, but why do you need to serialize the data? What > does serializing mean here anyway? What I was trying to say, rather awkwardly, is that the two functions are implemented to do exactly what the current code does. By "serializing" I meant calling the libexif function exif_data_set_data to turn an ExifData struct into a string of bytes that can be stored in a parasite in a machine-independent way, and by "deserializing", turning the bytes back into an ExifData struct. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > The interface between the jpeg plug-in and the metadata system, so > far as exif is concerned, would consist of two functions, > gimp_metadata_store_exif() -- which translates the exif into XMP and > adds it to the metadata parasite -- and > gimp_metadata_generate_exif(), which constructs an ExifData struct > using the information from the metadata. (Raphael's plan has them > implemented as plug-ins, but I think that's too awkward.) What is akward about it? > On loading an exif-jpeg file, it (1) calls > gimp_metadata_store_exif(), and (2) extracts the orientation from > the exif and, if it is not top-left, queries the user whether to > rotate the image. The JPEG plug-in would have to change the orientation tag if it's rotating the image on load, wouldn't it? It would have to do that before calling gimp_metadata_store_exif(). > gimp_metadata_store_exif() serializes the exif data and attaches it to > the image as an "exif-data" parasite. > > gimp_metadata_generate_exif() extracts the contents of the "exif-data" > parasite and deserializes them. Excuse my ignorance, but why do you need to serialize the data? What does serializing mean here anyway? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > The code is available from Raphael's web page, but it isn't in CVS, > and it's up to Raphael when to put it there. AFAIK the code available there is somewhat outdated and the API might have changed. > And yes, it makes sense to continue discussing this w/o Raphael, > although it would make a lot more sense to continue discussing it > with him. I'm sure he will contribute to the discussion when he's > ready to. OK then. I will have another look at your other mail then. But I think that you and Raphael should be deciding this, not me. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Sven wrote: > Sorry, but before I continue reading, why is Raphaels' metadata code > not available? You certainly wrote him a mail asking for it, didn't > you? So why is he holding the code back? Does it even make sense to > continue discussing this w/o Raphael? The code is available from Raphael's web page, but it isn't in CVS, and it's up to Raphael when to put it there. And yes, it makes sense to continue discussing this w/o Raphael, although it would make a lot more sense to continue discussing it with him. I'm sure he will contribute to the discussion when he's ready to. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > Okay, following up on earlier discussion: I think I have a > reasonable way of dealing with the jpeg-exif stuff until Raphael's > metadata code arrives. Sorry, but before I continue reading, why is Raphaels' metadata code not available? You certainly wrote him a mail asking for it, didn't you? So why is he holding the code back? Does it even make sense to continue discussing this w/o Raphael? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
