RSS/Atom feed Twitter
Site is read-only, email is disabled

jpeg-exif continued

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

14 of 14 messages available
Toggle history

Please log in to manage your subscriptions.

jpeg-exif continued William Skaggs 13 Jan 21:29
  jpeg-exif continued Robert L Krawitz 14 Jan 03:11
   jpeg-exif continued Sven Neumann 15 Jan 15:30
  jpeg-exif continued Sven Neumann 14 Jan 20:15
  jpeg-exif continued Sven Neumann 14 Jan 21:36
jpeg-exif continued William Skaggs 14 Jan 20:58
  jpeg-exif continued Sven Neumann 14 Jan 21:31
   jpeg-exif continued Raphaël Quinet 19 Jan 17:04
jpeg-exif continued William Skaggs 14 Jan 22:21
  jpeg-exif continued Sven Neumann 15 Jan 11:59
jpeg-exif continued William Skaggs 15 Jan 18:03
  jpeg-exif continued Sven Neumann 15 Jan 21:53
jpeg-exif continued William Skaggs 16 Jan 19:18
jpeg-exif continued William Skaggs 19 Jan 18:37
William Skaggs
2005-01-13 21:29:15 UTC (about 19 years ago)

jpeg-exif continued

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. Raphael's plan is to turn everything into XMP and store it all in a single parasite. 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.)

I rewrote the jpeg plugin to use those two interfaces. As I now have it written, here is what it does:

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.

On saving an exif-jpeg file, it (1) calls gimp_metadata_generate_exif(), and (2) sets the correct values for fields that according to the exif specs should be modified when an image is saved, including the thumbnail, image dimensions, orientation, etc.

It won't be possible to fully implement the two interface functions, gimp_metadata_store_exif() and gimp_metadata_generate_exif(), until Raphael's XMP parsing/formatting code is in CVS -- and even then it will be a lot of work. In the meantime, I created temporary implementations that do the following:

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.

That is, the two functions combine to handle the exif data in the same way that it has been handled in the past. I put the code for the two functions (and a few small utility functions) into a new file called gimpexif.c in the jpeg directory. This should eventually go into a new metadata library, but it can live in the jpeg directory for a while.

So, to sum up, I believe that my code makes the jpeg plug-in handle exif data correctly, and interface correctly with Raphael's system. It no longer creates any parasites except "exif-data" -- which means that there is no way to edit the exif data until Raphael's editor is available, but so be it. Future development consists of implementing the two interface functions so that they actually translate to and from XMP, and implementing the metadata editor.

I've tried to put this together in a way that meets all concerns, but I'm perfectly happy to make further changes if there would be better ways of doing things.

Best,
-- Bill


______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

Robert L Krawitz
2005-01-14 03:11:09 UTC (about 19 years ago)

jpeg-exif continued

Date: Thu, 13 Jan 2005 12:29:15 -0800 From: "William Skaggs"

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.

Sven Neumann
2005-01-14 20:15:00 UTC (about 19 years ago)

jpeg-exif continued

Hi,

"William Skaggs" 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

William Skaggs
2005-01-14 20:58:15 UTC (about 19 years ago)

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

Sven Neumann
2005-01-14 21:31:15 UTC (about 19 years ago)

jpeg-exif continued

Hi,

"William Skaggs" 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

Sven Neumann
2005-01-14 21:36:35 UTC (about 19 years ago)

jpeg-exif continued

Hi,

"William Skaggs" 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

William Skaggs
2005-01-14 22:21:46 UTC (about 19 years ago)

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

Sven Neumann
2005-01-15 11:59:49 UTC (about 19 years ago)

jpeg-exif continued

Hi,

"William Skaggs" 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

Sven Neumann
2005-01-15 15:30:30 UTC (about 19 years ago)

jpeg-exif continued

Hi,

Robert L Krawitz 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

William Skaggs
2005-01-15 18:03:00 UTC (about 19 years ago)

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

Sven Neumann
2005-01-15 21:53:22 UTC (about 19 years ago)

jpeg-exif continued

Hi,

"William Skaggs" 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

William Skaggs
2005-01-16 19:18:41 UTC (about 19 years ago)

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

Raphaël Quinet
2005-01-19 17:04:18 UTC (about 19 years ago)

jpeg-exif continued

On Fri, 14 Jan 2005 21:31:15 +0100, Sven Neumann wrote:

"William Skaggs" 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

William Skaggs
2005-01-19 18:37:41 UTC (about 19 years ago)

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