Saving history in a graphic editor?


Warning: count(): Parameter must be an array or an object that implements Countable in /home/styllloz/public_html/qa-theme/donut-theme/qa-donut-layer.php on line 274
0 like 0 dislike
4 views
Hello. That question is asked — how to correctly save the history in a graphic editor (like GIMP) for use in UNDO/REDO. He can see three options:

1. Keep a list of actions.

For example, draw a line a certain color in such coordinates, applied the filter "blur", turned image. In the case of using the UNDO pass all the action from the first to the necessary.
Advantage: Takes up very little space in memory. When you save the project, you can easily restore the entire story. If you want you can even store the entire tree (for example, made the action A, B, C, D, E, back to C, made F, G. the Resulting path ABCFG happened, but in the version control system to store and branch DE)
Drawback: When using Undo or loading a previously saved image goes all the way, and this can be a significant time and if the usual simple editing such a passage may take some 100-200 MS, which is not critical, as when using heavy filters may slow to tens of seconds.

2. Save a full dump of the project to bitmap

Every action whole picture we store in memory as a finished drawing.
Advantage: Very fast. Made undo/redo and just showed out of memory the picture that we had (already rendered). Even the heavy filter anything.
Disadvantage: Takes up a lot of space in memory. Suppose we have a drawing the size of 1k*1k. In each pixel we store 32 bits of information (8 bits per r,g,b, and 8 bits for the alpha channel), that is 4 bytes, that is, a bitmap, we will have to take ideally 4 meters, and the story of the 64 action — 64*4 = 256 MB of memory. And assuming that we have graphics editor supports layers and let them be at least five... Likewise, projects with a story to keep hard.

Gimp

In Ghimpu on circumstantial evidence, I operedelit that uses the second approach. The symptoms are:

1. The history is limited

2. Heavy filters, undo, redo, return the status quo very quickly.

3. A combined approach

Of course, there is an alternative. Keep a record of the first method, and the latter, for example, 8 actions stored by the second method, because it is rarely used so far undo. Save on the screw can be only the actions for which the project many changes will be a long time to open, but is allowed to weigh. Or even add the latest map date.
The advantages of both approaches
The disadvantage of a much heavier application logic. Actually — it is necessary to implement two mechanisms of history.

Topic for discussion

What do you say? Maybe there is another approach. If not, which approach would you prefer (in an ideal case and in the case of very tight deadlines)? Why?
by | 4 views

4 Answers

0 like 0 dislike
My third method would be logical to Supplement some key frames (similar with a video), essentially a bitmap, which would remain after heavy filters and stored would not be operative, and the screw (in the temporary folder). Ie, as You describe several actions in the field in the form of a bitmap. The back story in the form of list of actions from the key frames (heavy filters). And these keyframes would be logical to store not raw, but at least in the same png. This will not significantly slow down when you roll back to the distant history and to save space on the screw due to the compression of png.
\r
In General, the idea of keyframes would be possible to apply full instead of the third option. Ie small actions to keep it as action, while heavier, like keyframes in a bitmap in RAM. If more severe action is relegated to the past, then packing it into png and reset the screw.
\r
And... about the layers... we have the same undo usually applies to a particular action on a particular layer rather than all layers simultaneously. Of course there is live filters, but that is another story. I mean, the number of layers does not increase the number of bitmap proportionally.
by
0 like 0 dislike
I wonder what kind of store a few the latest iterations, and on the other to make patches type diff in the background.
by
0 like 0 dislike
But it is impossible in some instances to build a sequence reverse to the first?
\r
I mean, there are reversible changes and are irreversible. It is logical to store the key frame after irreversible, and from the ground state to be completed to the nearest reversible in the reverse order, using the history on the existing frame, walking the path from end, not start.
by
0 like 0 dislike
And if you use geometricheskaya distribution? To save key frames as a whole, but only images of the region changes, and then superimpose them on each other?
\r
That is, each stroke of the brush is the preservation of the bitmap needs within those grid cells where he was held, not the whole picture.
by

Related questions

0 like 0 dislike
1 answer
0 like 0 dislike
1 answer
0 like 0 dislike
2 answers
asked May 12, 2019 by Alpha_Antares
0 like 0 dislike
3 answers
0 like 0 dislike
7 answers
asked Apr 1, 2019 by YuriyPrudnikov
110,608 questions
257,186 answers
0 comments
27,386 users