After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 148930 - Optionally save undo history in the XCF
Optionally save undo history in the XCF
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.0.x
Other All
: Normal enhancement
: Future
Assigned To: GIMP Bugs
GIMP Bugs
: 459067 553059 (view as bug list)
Depends on:
Blocks: 695348 699427
 
 
Reported: 2004-07-31 15:14 UTC by k_b0000
Modified: 2018-05-24 11:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description k_b0000 2004-07-31 15:14:11 UTC
a feature i feel i lack in gimps xcf-files is the possibility to save the
editing history witin the file itself, thus saving it for later use (or later
control).

i know some operations would need a lot of space, but saving information on how
it was done should be rather space friendly.
for example: 
1. make hand-drawn selction with positions ............
2. apply sharpen 30
3. apply levels ...........
4. apply curves ...........
5. more things.

the normal history is incremental (takes the current image and does something to
it, not bothering about old changes), the saved history could work in the same way.

the save history option should be possible to turn on/off as you SAVE AS.
a file containing history should load it when opened.
Comment 1 Adam Pribyl 2005-09-01 20:13:20 UTC
I vote for this! GIMP is a pretty good program, this I miss in my often use. I
am not sure wherether any other program (proffesional) has this, so this could
really be advantage for GIMP.

Reason: 
1. working on complicated image for few day (well, yes I have to shutdown the 
machine), I want to start working where I end up yesterday, with all the history.
2. I often do not rememeber what I did to image that it looks as it looks. E.g.
I want to repeat some effects I did once to different image - there is no way
how to find what I did.
Comment 2 Michael Schumacher 2006-08-13 18:20:15 UTC
This is related to bug #51937 (macro recording). IMO not a duplicate, but it does illustrate a possible use case for implicit recording.
Comment 3 Michael Schumacher 2007-07-21 19:33:53 UTC
*** Bug 459067 has been marked as a duplicate of this bug. ***
Comment 4 Andrey 2008-07-03 07:11:05 UTC
I also vote for this feature.
Comment 5 Sven Neumann 2008-07-04 07:04:19 UTC
Please don't add such comments to Bugzilla. This is a bug-tracker, not a place where you can add your wishes or vote for changes.
Comment 6 Sven Neumann 2008-09-20 22:57:31 UTC
*** Bug 553059 has been marked as a duplicate of this bug. ***
Comment 7 Valerio Messina 2013-03-07 10:16:27 UTC
Photoshop has this major enhancement that is required for professional use.
Multi-day editing is normal, sure the session must be saved at end of day,
but sometime happen the next day, need undo something of the previous one.
I do not know if it is an xcf format limitation or simply a function not implemented, but should fill the gap
Comment 8 Michael Schumacher 2013-03-07 17:28:26 UTC
We want this for GIMP, too - but someone has to write the code for it. 
Right now, it is not as easy as "just save the undo history into the file" if you're not keen on having multi-gigabyte XCF files :)

If you plan to work on this feature, you could join the gimp-developer mailing list and our IRC channel.
Comment 9 Valerio Messina 2016-06-23 11:41:01 UTC
this bug block:
https://bugzilla.gnome.org/show_bug.cgi?id=695348
Comment 10 Valerio Messina 2016-07-21 13:38:55 UTC
I saw in roadmap:
http://wiki.gimp.org/wiki/Roadmap#GIMP_2.10
this feature is not foresee neither for 3.20
Is this a won't fix?
Comment 11 Jehan 2016-07-21 13:45:31 UTC
This is not a "won't fix". See Michael's comment 8 above which says it very well:

> We want this for GIMP, too - but someone has to write the code for it.
> Right now, it is not as easy as "just save the undo history into the file" if you're not keen on having multi-gigabyte XCF files :)
Comment 12 Valerio Messina 2016-07-21 14:40:41 UTC
who can add the feature in the roadmap?
Comment 13 Jo 2016-07-28 10:41:19 UTC
maybe an interesting feature.
But please add this feature as option, not standard. 
Because this would increase only file size and i deal already with big file sizes. Their size is usually 100MB and growing.
Comment 14 Jehan 2016-07-31 13:08:03 UTC
Valerio > I added the feature to "Future" list in roadmap, which does *not necessarily* mean it is for after the listed targets (2.10, 3.0 and 3.2), but rather that we don't know for sure yet.

Yet it's in the list, so that will put some visibility on it when we will decide to prioritize.
Comment 15 Valerio Messina 2016-07-31 17:36:38 UTC
thank you, well done
Comment 16 Public343434 2017-11-29 08:10:27 UTC
Maybe Virtualbox and its snapshot function can work until they make this happen (13 years and counting)? Store original and finished photos in the host OS and not the guest OS, since the image can get corrupted. This could work until the guest OS needs to reboot after an update, but if you only use it for image editing you could disconnect the network and ignore the security updates of the guest OS. The editing history will remain intact if you hibernate the guest OS.

I too can't believe the save editing history isn't yet implemented. Until it is, this software will be like a three legged chair: you can sit on it as long as you pay attention. The minute you forget you'll fall on your ass.

https://www.virtualbox.org/
Comment 17 max 2018-05-08 09:40:49 UTC
I was wondering if an easier path won't be to save the change history in a system of sessions rather than in the xcf itself.

Let me explain : from what I've red in the thread, the undo history is missing when one is editing a complex image and has to shut down the the PC, or, worse, if power goes down (or other Murphy' desaster).

In this case it would be nice to be able to reopen the whole session (imagine we have 20 complex files opened) with all the histories for each file.

Then, when saving a session, we could save the histories in the data of this session, not in the xcfs itselves, therefore the weight of the history won't be a concern anymore, and it won't be necessary to modify the structure of the xcf.

The timestamps of the files could be saved in the session, so if the timestamp of the existing file (the real one) is different from the one indexed in the session, history for this file is lost.

An option could be to offer to save the proper xcfs as well in the session, so we have in this case a real snapshot, which can always be reopen in the current state, or even passed from a PC to another, independently of the original xcfs files.

Of course, the session data will be of some weight, but as it is a temporary data, for editing purpose, it is not really a concern. In the meanwhile, the resultant xcf would be able to leave its own life, with no extra unnecessary data in it.
Comment 18 Audrey Toskin 2018-05-09 22:16:02 UTC
To me, part of the appeal of saving revision history would be for the ways that it can facilitate collaboration. Project teams can more visually discuss their thought processes and perhaps revert to an earlier stage of development if needed. This could be useful for people working on their own too, but it's perhaps more important in collaboration -- and for collaborating with revision history to work, the revision history needs to be stored in a file that can team members can share with each other.

So maybe history doesn't *need* to be saved in the XCF itself, but it needs to be stored somewhere convenient, and separate from other unrelated projects. The XCF file seems the most convenient to me, though. And as the original post proposed, this probably ought to be an optional feature anyway.
Comment 19 GNOME Infrastructure Team 2018-05-24 11:10:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/89.