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

Improving the dirty flag

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.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

Improving the dirty flag Raphaël Quinet 19 Jan 14:55
  Improving the dirty flag Raphaël Quinet 19 Jan 15:16
Raphaël Quinet
2005-01-19 14:55:12 UTC (about 19 years ago)

Improving the dirty flag

Currently, each image has a "dirty" flag associated with it. In practice this is counter for the undo operations, but the users see it as a flag. Unfortunately, this is not very flexible because it cannot tell if the image data was modified or if only its metadata was modified. I think that it could be improved by splitting this dirty indicator in two (data and metadata) or maybe even three: - image data (tiles)
- image "structure" (layer visibility, stacking order, etc.) - other metadata (parasites such as EXIF, color profile, etc.)

This could be helpful in several cases. For example, a file save plug-in could detect that the metadata was updated (e.g., new description or copyright message) but the image data was not altered. In that case, it could try to re-use the data from the original file on disk if it is still available. This could be useful for lossy formats such as JPEG and this is somewhat related to bug #105623. This could also be nice for very large files if the metadata can be rewritten without touching the other parts of the file.

I'm not sure if what I called "image structure" above should be considered separately. This could be useful for those who liked the old (and rather incorrect) behaviour of gimp 1.2 that did not consider the layer visibility changes as affecting the image itself. This is just an idea... Maybe it is better to consider only "image data" and "metadata".

For additional fun, there could be another flag (e.g. "tainted" but not "dirty") used only when the image is loaded from disk and telling the GIMP if some minor operations have been applied to it, such as the automatic rotation based on the EXIF metadata or the conversion from some color profile to sRGB. This flag would reduce the need for the "trust-dirty-flag" setting: the image would not be marked as dirty so that the user would not be asked to save it when closing it (except if other operations have set the dirty flag). But if the image or its metadata is "tainted", then it would always be saved if the user wants to save it (even if trust-dirty-flag is TRUE).

I think that such a change could improve the usability of the GIMP and could lead to better results in some cases (avoiding recompression). But I would like to discuss it before submitting it to Bugzilla. Any comments?

-Raphaël

Raphaël Quinet
2005-01-19 15:16:30 UTC (about 19 years ago)

Improving the dirty flag

On Wed, 19 Jan 2005 14:55:12 +0100, Raphaël Quinet wrote:

Currently, each image has a "dirty" flag associated with it. In practice this is counter for the undo operations, but the users see it as a flag. Unfortunately, this is not very flexible because it cannot tell if the image data was modified or if only its metadata was modified. I think that it could be improved by splitting this dirty indicator in two (data and metadata) or maybe even three: [...]

Replying to my own message...

Before someone tells me that it should be a job for the GimpDirtyMask, I should add that the main goal here is that the difference between "dirty image" and "dirty metadata" should be visible outside the undo code and outside the core in general. For example, the plug-ins should be able to test these flags. Same for the proposed "tainted" flag (or whatever it would be called in the end). Otherwise, most of the usefulness of these flags would be lost, so the current GimpDirtyMask is not suitable for this task.

-Raphaël