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

jpeg-exif development summary

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.

15 of 15 messages available
Toggle history

Please log in to manage your subscriptions.

jpeg-exif development summary William Skaggs 19 Jan 18:32
  jpeg-exif development summary Robert L Krawitz 20 Jan 01:45
   jpeg-exif development summary Alastair M. Robinson 20 Jan 02:32
    jpeg-exif development summary Robert L Krawitz 20 Jan 02:57
jpeg-exif development summary shaneyfelt@juno.com 20 Jan 06:21
  jpeg-exif development summary Raphaël Quinet 20 Jan 13:34
   GimpConfig [was: jpeg-exif development summary] Sven Neumann 21 Jan 00:29
    GimpConfig [was: jpeg-exif development summary] Raphaël Quinet 21 Jan 13:51
     GimpConfig Sven Neumann 22 Jan 14:00
      GimpConfig Raphaël Quinet 24 Jan 14:29
       GimpConfig Sven Neumann 24 Jan 21:08
   jpeg-exif development summary Jay Cox 25 Jan 09:18
    jpeg-exif development summary David Neary 25 Jan 10:32
     jpeg-exif development summary Michael Schumacher 25 Jan 19:55
jpeg-exif development summary William Skaggs 25 Jan 20:35
William Skaggs
2005-01-19 18:32:15 UTC (about 19 years ago)

jpeg-exif development summary

Hi Raphael, glad to hear from you.

Although I am a bit late to the party, here are my 2 cents: I think that the jpeg plug-in should automatically rotate the image when opening it without marking it as "dirty". The default setting should be to do that automatically without asking, both for interactive and non-interactive mode. Let me try to explain why...

In an ideal world I agree that this would be the right answer. What concerns me is that in this less-than-ideal world, many people are likely to have images with incorrect exif data, including anybody who edited a rotated exif jpeg in GIMP 2.0 or 2.2 and then resaved it as jpeg. It's hard to get a fix on how large a population this is, but I bet if we impose a solution on them that rotates their images without giving them any way to prevent it, we'll be subjecting ourselves to some angry bug reports.

Best,
-- Bill


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

Robert L Krawitz
2005-01-20 01:45:26 UTC (about 19 years ago)

jpeg-exif development summary

Date: Wed, 19 Jan 2005 09:32:15 -0800 From: "William Skaggs"

Hi Raphael, glad to hear from you.

> Although I am a bit late to the party, here are my 2 cents: I > think that the jpeg plug-in should automatically rotate the image > when opening it without marking it as "dirty". The default > setting should be to do that automatically without asking, both > for interactive and non-interactive mode. Let me try to explain > why...

In an ideal world I agree that this would be the right answer. What concerns me is that in this less-than-ideal world, many people are likely to have images with incorrect exif data, including anybody who edited a rotated exif jpeg in GIMP 2.0 or 2.2 and then resaved it as jpeg. It's hard to get a fix on how large a population this is, but I bet if we impose a solution on them that rotates their images without giving them any way to prevent it, we'll be subjecting ourselves to some angry bug reports.

Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor?

Raphael's proposal sounds right on the money to me.

Alastair M. Robinson
2005-01-20 02:32:44 UTC (about 19 years ago)

jpeg-exif development summary

Hi Robert,

Robert L Krawitz wrote:

Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor?

I doubt anyone who's encountered this issue opening files in other programs will have twigged that GIMP caused it :)

Raphael's proposal sounds right on the money to me.

It comes down to a question of what's most annoying: (1) having to rotate manually an unknown, but possibly quite small number of existing images, on a one-off basis, or (2) having to dismiss (or find a way of permanently disabling) an extra dialog for every existing and future image that has the relevant EXIF flag set.

I'd opt for (1) every time. I could live with (2), if and only if there's a bug-me-not option to get rid of it.

All the best, --
Alastair M. Robinson

Robert L Krawitz
2005-01-20 02:57:23 UTC (about 19 years ago)

jpeg-exif development summary

Date: Thu, 20 Jan 2005 01:32:44 +0000 From: "Alastair M. Robinson"

Hi Robert,

Robert L Krawitz wrote:

> Won't they have (already be having) exactly the same problem with any > other EXIF-aware viewer or editor?

I doubt anyone who's encountered this issue opening files in other programs will have twigged that GIMP caused it :)

Probably not, but with correct EXIF behavior it should behave the same as any other EXIF-aware apps.

shaneyfelt@juno.com
2005-01-20 06:21:37 UTC (about 19 years ago)

jpeg-exif development summary

]> Raphael's proposal sounds right on the money to me. ]
]It comes down to a question of what's most annoying: ](1) having to rotate manually an unknown, but possibly quite small ]number of existing images, on a one-off basis, or ](2) having to dismiss (or find a way of permanently disabling) an extra ]dialog for every existing and future image that has the relevant EXIF ]flag set.
(3) somebody write a command-line tool that will just strip the flag from all the images in a directory (for those who have been using bad versions to fix all their images), along with option (1) above, keeping the kludge out of gimp, while providing the service.

_-T

____________________

Raphaël Quinet
2005-01-20 13:34:00 UTC (about 19 years ago)

jpeg-exif development summary

On Thu, 20 Jan 2005 05:21:37 GMT, "shaneyfelt@juno.com" wrote: [re-formatted to include proper quoting]

Alastair M. Robinson wrote:

Robert L Krawitz wrote:

Raphael's proposal sounds right on the money to me.

It comes down to a question of what's most annoying: (1) having to rotate manually an unknown, but possibly quite small number of existing images, on a one-off basis, or (2) having to dismiss (or find a way of permanently disabling) an extra dialog for every existing and future image that has the relevant EXIF flag set.

(3) somebody write a command-line tool that will just strip the flag from all the images in a directory (for those who have been using bad versions to fix all their images), along with option (1) above, keeping the kludge out of gimp, while providing the service.

Fortunately, there are already several command-line tools available for that, as well as several GUI tools that have some kind of batch mode.

One example of such a command-line tool is Jhead. You can either use the option "jhead -autorot" to rotate the image and clear the EXIF Orientation tag, or use the option "jhead -norot" to clear the EXIF Orientation tag without rotating the image, assuming that some broken program has already rotated the image without updating the EXIF info.

I have also seen some shell scripts that use the command-line "exif" program to change the value of the Orientation tag directly. So there are already many ways to fix the JPEG files with EXIF info that have been incorrectly handled by some programs (such as GIMP 2.2, but hopefully not 2.4).

Although I think that option (1) above should be the default instead of (2), I think that (2) can still be useful in some cases. Some of the EXIF-aware image editors that I looked at are also offering an option to ignore the EXIF Orientation tag (this is never the default, though). Bill has already written the code for asking the user, so let's not throw that away. So the default should be to open the images with the correct orientation without asking, and there should be an option in the preferences (gimprc) that allows the user to ignore the EXIF Orientation tag or to be asked every time. The threshold for adding new options to the gimprc should be high, but I think that this one deserves it.

-Raphaël

Sven Neumann
2005-01-21 00:29:00 UTC (about 19 years ago)

GimpConfig [was: jpeg-exif development summary]

Hi,

Raphaël Quinet writes:

So the default should be to open the images with the correct orientation without asking, and there should be an option in the preferences (gimprc) that allows the user to ignore the EXIF Orientation tag or to be asked every time. The threshold for adding new options to the gimprc should be high, but I think that this one deserves it.

Sure, that has never been questioned. The best thing would probably be to add a "[ ] Don't ask me again" toggle to the dialog. But I would suggest that this is delayed until we have established a framework for plug-ins to deal with such preferences. It would be wrong to depend on a modifications to the core here. All plug-ins should have an easy way to store configuration and presets. The current gimprc API in the PDB is not really sufficient for this.

If we want to improve the image export functionality, and I think we want to do that for 2.4, we will also need such functionality. I want to suggest that we implement this by moving most of the GimpConfig functionality from the core to libgimpbase or, alternatively, to a new library, maybe called libgimpconfig. We should try to get this done early in 2.3 since it will allow us to solve quite a bit of useability issues that people have with plug-ins.

In the core we already make heavy use of the GimpConfig interface. It basically adds serialization capabilites to any GObject that implements it. There's a default implementation that takes care of serializing and deserializing all object properties that have a certain flag set in their GParamSpec.

GimpConfig was originally developed to solve the problem that it used to be a PITA to add a new configuration value to gimprc. Nowadays this is as simple as adding a new property to one of the classes that form the GimpRc object. Adding a property to a GObject involves registering a param-spec, a description of the property that defines the type of the value and includes a default value, a description and more.

This information can then be used to serialize the value (generate a string representation) and to deserialize it (load the serialized values back in). No extra code needs to be written for this.

The addition of the object properties also pays out when a user interfaces is needed to control the properties. We have a couple of convenience constructors in the core. The more generic ones could also be moved to libgimpwidgets. We use these functions to create the widgets in the tool-options dialogs and also the preference dialog. For example in order to create a check-button with a label next to it, we call

gimp_prop_check_button_new (config, property_name, label_text);

The returned button is a view on the property value. It is synced with the object config. Any change to the button is applied to the object and the button will also change it's state if the value changes by other means. Having this functionality available for all plug-ins and modules will certainly improve things. Plug-in user interface often mainly consist of a couple of widgets to control a number of configurations. If the plug-in implements an object that represents this configuration, the GUI code reduces to a few lines. Implementing a Reset button boils down to calling gimp_config_reset(). This will reset all object properties to their default values. Saving the current values as new default values would also become trivial. Even maintaining a couple of configurations like we do for the tool-options is easy. We can probably implement that as convenience functions in GimpDialog.

The next step would of course be to move the PDB to using object properties as well. The work invested in porting plug-ins to GimpConfig will pay out again then.

There are a few things that we will need to decide upon, like in which library this should live, what namespace it should use (is GimpConfig a good name?), and how much of the core GimpConfig we actually want to expose to plug-ins and modules. There are a couple of features like the ability to nest objects that would perhaps better be kept for the core only as they add quite a bit of complexity.

Sven

Raphaël Quinet
2005-01-21 13:51:35 UTC (about 19 years ago)

GimpConfig [was: jpeg-exif development summary]

On Fri, 21 Jan 2005 00:29:00 +0100, Sven Neumann wrote:

Raphaël Quinet writes:

So the default should be to open the images with the correct orientation without asking, and there should be an option in the preferences (gimprc) that allows the user to ignore the EXIF Orientation tag or to be asked every time. The threshold for adding new options to the gimprc should be high, but I think that this one deserves it.

Sure, that has never been questioned. The best thing would probably be to add a "[ ] Don't ask me again" toggle to the dialog.

Well, the main point was that most users should not even see that dialog once, unless they explicitely change the default option in the preferences. This is in line with what other programs are doing and it is IMHO better because most users should not have to care about the details of the file format.

But I would
suggest that this is delayed until we have established a framework for plug-ins to deal with such preferences. It would be wrong to depend on a modifications to the core here. All plug-ins should have an easy way to store configuration and presets. The current gimprc API in the PDB is not really sufficient for this.

Even though the current gimprc API in the PDB is rather simple (both the query and set operations are limited to simple strings), it is not too bad. It is of course a good idea to improve it, but it should not be discarded too early. Using strings, there is the problem of marshalling/unmarshalling the data, but having to use the PDB for this is a good feature from my point of view: it automatically avoids some concurrency problems that could occur if the plug-ins were accessing files directly. It also provides a single point from which some additional policies could be applied.

If we want to improve the image export functionality, and I think we want to do that for 2.4, we will also need such functionality. I want to suggest that we implement this by moving most of the GimpConfig functionality from the core to libgimpbase or, alternatively, to a new library, maybe called libgimpconfig. We should try to get this done early in 2.3 since it will allow us to solve quite a bit of useability issues that people have with plug-ins.

[...]

This is again a good idea, but does this mean that the plug-ins converted to use GimpConfig would then start accessing the config files directly? I would prefer to make sure that all set/get operations for the configuration options are going through the PDB and handled by the core (this could of course be done transparently by the GimpConfig implementation). If not, then it will be necessary to implement some kind of locking mechanism for the files, in order to avoid problems in case the core and a plug-in are trying to update the same file. I am worried about the configuration parameters that could be used by more than one plug-in.

There are a few things that we will need to decide upon, like in which library this should live, what namespace it should use (is GimpConfig a good name?), and how much of the core GimpConfig we actually want to expose to plug-ins and modules. There are a couple of features like the ability to nest objects that would perhaps better be kept for the core only as they add quite a bit of complexity.

For the namespace, GimpConfig is fine. GimpProperty (or GimpPlugInProperty) could be better for those who are familiar with Java and persistent properties, but could also introduce some confusion with the existing usage of properties that can be set on objects. Regarding the features, I agree that nested objects would be a bit overkill: being able to store simple data types (and edit them with the appropriate widgets) would probably be sufficient.

-Raphaël

Sven Neumann
2005-01-22 14:00:42 UTC (about 19 years ago)

GimpConfig

Hi,

Raphaël Quinet writes:

This is again a good idea, but does this mean that the plug-ins converted to use GimpConfig would then start accessing the config files directly? I would prefer to make sure that all set/get operations for the configuration options are going through the PDB and handled by the core (this could of course be done transparently by the GimpConfig implementation). If not, then it will be necessary to implement some kind of locking mechanism for the files, in order to avoid problems in case the core and a plug-in are trying to update the same file. I am worried about the configuration parameters that could be used by more than one plug-in.

Of course plug-ins must not access gimprc directly. gimprc is the core rc file and must only be read and written by the core. I was rather thinking of letting each plug-in use it's own config file, located in the ~/.gimp-2.x directory.

Regarding concurrent writes, I should probably note that GimpConfigWriter writes to a temporary file and moves it to the final destination when done.

Sven

Raphaël Quinet
2005-01-24 14:29:54 UTC (about 19 years ago)

GimpConfig

On Sat, 22 Jan 2005 14:00:42 +0100, Sven Neumann wrote:

Raphaël Quinet writes:

[...] I am worried about the configuration parameters that could be used by more than one plug-in.

Of course plug-ins must not access gimprc directly. gimprc is the core rc file and must only be read and written by the core. I was rather thinking of letting each plug-in use it's own config file, located in the ~/.gimp-2.x directory.

I expected this suggestion, which is why I wrote that I was worried about the parameters the could be used by more than one plug-in. If each plug-in uses its own config file, then it will become tricky for two plug-ins to share some config settings. This could happen if the load and save plug-ins for some file format want to share some settings, or for parameters that could be shared by many plug-ins, such as some metadata (default author, default copyright/license, etc.) or color profile information, whether some conversions should be done automatically, ... Some of these things could be handled by the GIMP and stored into global parasites as we already have the default comment but that would only solve a part of the problem. Besides, I would prefer to get rid of the default-comment parasite and move that to a proper GimpConfig object instead of having to add several new global parasites for the configurable defaults of some other parts of the metadata (author, copyright, etc.).

So we still have a problem for the settings that are used by more than one plug-in. If two plug-ins (or a plug-in and the core) want to save some settings into the same file (gimprc or some other shared file) and do it at the same time, then you don't know if you will only get the settings from one, from both, or if you will get garbage.

Although the race conditions would not occur too often and we could decide to ignore them, there are some situations that make them more likely. For example, when you have several images open and you save them all before quitting the GIMP.

Regarding concurrent writes, I should probably note that GimpConfigWriter writes to a temporary file and moves it to the final destination when done.

This is a good thing and that prevents the "garbage" case from happening. But there is still a problem if two plug-ins want to update some config settings stored in the same file: you will only get the updates from one plug-in (or from the core), but you don't know which one. Of course, if both plug-ins want to update the same settings, then the user will only get what he deserves. But if they want to update different settings (no conflict) then one of them will be lost. This could be avoided if all GimpConfig updates were serialized through the PDB.

-Raphaël

Sven Neumann
2005-01-24 21:08:42 UTC (about 19 years ago)

GimpConfig

Hi,

Raphaël Quinet writes:

I expected this suggestion, which is why I wrote that I was worried about the parameters the could be used by more than one plug-in. If each plug-in uses its own config file, then it will become tricky for two plug-ins to share some config settings.

I don't think two plug-ins should share a configuration file and access it directly. If there are settings that need to be shared between plug-ins, then these settinges should be handled in the core and should be passed to the plug-ins using the PDB (probably by means of some yet-to-be-added generic methods to pass GimpConfig settings between core and plug-ins).

Sven

Jay Cox
2005-01-25 09:18:37 UTC (about 19 years ago)

jpeg-exif development summary

We should be able to automaticaly detect when a file has been rotated without updating the exif data most of the time. Exif stores the image width and height a couple of times. Cant we just check if the width/height in the exif match the widht/height of the actual image? The only cases this wont catch is bottom-right orientation (should be very rare) and cameras with square sensors(are there any?).

If the width/height tags are getting molested by the gimp, then we could fall back to comparing against the aspect ratio of the embedded preview when there is one.

On a more practical note, gimp seems to completely throw away any exif data when saving as a jpg(tested in 1.3,24, and 2.2.2). Perhaps this is less of a problem than it has been made out to be (or perhaps I have weird cvs versions of gimp installed).

Jay Cox jaycox@gimp.org

O

David Neary
2005-01-25 10:32:57 UTC (about 19 years ago)

jpeg-exif development summary

Hi Jay,

Jay Cox wrote:

On a more practical note, gimp seems to completely throw away any exif data when saving as a jpg(tested in 1.3,24, and 2.2.2). Perhaps this is less of a problem than it has been made out to be (or perhaps I have weird cvs versions of gimp installed).

You need libexif installed before exif data will be saved. Perhaps this dependency will go away with Bill's new stuff, but I think he uses it too.

Cheers,
Dave.

Michael Schumacher
2005-01-25 19:55:09 UTC (about 19 years ago)

jpeg-exif development summary

David Neary wrote:

You need libexif installed before exif data will be saved. Perhaps this dependency will go away with Bill's new stuff, but I think he uses it too.

Reimplementing libexif in gimp wouldn't be too wise, would it?

Michael

William Skaggs
2005-01-25 20:35:18 UTC (about 19 years ago)

jpeg-exif development summary

Michael Schumacher wrote:

Reimplementing libexif in gimp wouldn't be too wise, would it?

Libexif is a lot cruftier than it needs to be but I don't have any ambition to reimplement it.

-- Bill

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