Re: [Gimp-developer] jpeg-exif continued
Raphael wrote: > Yes to both, although the basic stuff hasn't changed much. I never > managed to finish the code that generates the EXIF block from XMP, > though, so that's still work-in-progress. The most important thing is the XMP parsing/formatting code. Once that is in place, I can help with the EXIF-XMP translation code. Best, -- 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
On Fri, 14 Jan 2005 21:31:15 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > "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. Yes to both, although the basic stuff hasn't changed much. I never managed to finish the code that generates the EXIF block from XMP, though, so that's still work-in-progress. But as I have been unable to access my account and update my web pages on wilber.gimp.org since last month, I would like to have this fixed before syncing the files and eventually committing the metadata stuff to CVS. > > 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. As I have a bad track record of disappearing when people need some input from me (due to business trips, vacation or other bad excuses), I am glad that you discussed this while I was away. -Raphaël ___ 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: > It's just an argument, not a requirement. Simply something that might > be worth keeping in mind. Is this really only relevant to file > plug-ins? A metadata editor would need to use these functions as well, > wouldn't it? Raphael's plan, which makes sense to me, is that the metadata editor and metadata accessor functions will work exclusively with XMP, and that file plug-ins will translate between XMP and other metadata formats (IPTC, EXIF, DICOM, etc) on loading or saving, using interface functions supplied by the metadata system. So the interface functions xxx_metadata_store_exif() and xxx_metadata_generate_exif() only come into play when loading or saving a file with exif data. Fortunately the Adobe XMP specification completely defines the translation between EXIF data and XMP data, so the EXIF->XMP->EXIF round trip can be done without losing any information. > Hmm, so if I open an image, do some color corrections, but do not > rotate it, the orientation tag is supposed to change? I can hardly > believe that. But if you say that's what the spec says... It *is* what the spec says, and it seems to me that the only reasonable assumption is that if the user looks at the image before saving it, what the user sees is what the user wants. I admit that for non-interactive use this might not always be the most desireable thing, and perhaps it is worth thinking about whether that should (or could) be handled differently. -- 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: >> I agree that for a C plug-in a library is easier to use but we will >> also have to care about plug-ins written in other languages. Making >> the functionality available in the PDB solves this nicely. What we >> usually do is to provide wrappers that let the procedure call appear >> as a simple function call. > > This is only relevant to file plug-ins. It didn't occur to me that > they would ever be written in anything except C, but if that is a > reasonable possibility, then I accept the argument. It's just an argument, not a requirement. Simply something that might be worth keeping in mind. Is this really only relevant to file plug-ins? A metadata editor would need to use these functions as well, wouldn't it? > The orientation is *always* supposed to be set to "top-left" when an > image is saved, on the principle that after the user has edited > the image in GIMP, the orientation is the way the user wants it. > Only a camera should ever set it to anything other than "top-left". Hmm, so if I open an image, do some color corrections, but do not rotate it, the orientation tag is supposed to change? I can hardly believe that. But if you say that's what the spec says... 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: > I agree that for a C plug-in a library is easier to use but we will > also have to care about plug-ins written in other languages. Making > the functionality available in the PDB solves this nicely. What we > usually do is to provide wrappers that let the procedure call appear > as a simple function call. This is only relevant to file plug-ins. It didn't occur to me that they would ever be written in anything except C, but if that is a reasonable possibility, then I accept the argument. Sven: > Well, how is the save plug-in supposed to know that it needs to change > the orientation field upon saving? Only when the image is rotated, > during load, is this information available. Or am I missing something > here? The orientation is *always* supposed to be set to "top-left" when an image is saved, on the principle that after the user has edited the image in GIMP, the orientation is the way the user wants it. Only a camera should ever set it to anything other than "top-left". -- 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, Robert L Krawitz <[EMAIL PROTECTED]> writes: > I know I've been making a nuisance of myself about this, but PLEASE > at least provide a way to turn this query off. Robert, we are at the very beginning of the development cycle and are discussing the basics. The query is off-topic right now. 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: > 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. I agree that for a C plug-in a library is easier to use but we will also have to care about plug-ins written in other languages. Making the functionality available in the PDB solves this nicely. What we usually do is to provide wrappers that let the procedure call appear as a simple function call. > 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. Well, how is the save plug-in supposed to know that it needs to change the orientation field upon saving? Only when the image is rotated, during load, is this information available. Or am I missing something here? 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
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
Re: [Gimp-developer] jpeg-exif continued
Date: Thu, 13 Jan 2005 12:29:15 -0800 From: "William Skaggs" <[EMAIL PROTECTED]> 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. I know I've been making a nuisance of myself about this, but PLEASE at least provide a way to turn this query off. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
