enable a GEGL graph evolution log
This discussion is connected to the gegl-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.
| enable a GEGL graph evolution log | Philip R. Dutton | 10 Sep 21:12 |
| enable a GEGL graph evolution log | Jon Nordby | 24 Sep 17:23 |
| enable a GEGL graph evolution log | Debarshi Ray | 26 Sep 14:24 |
enable a GEGL graph evolution log
Hello GIMP devs!
I have started studying the GIMP code base because I'm interested in finding a way to log the basic GIMP operations I use during a GUI session. My use case is digital art (not much photo editing).
I ran across much talk and some implementation of GEGL. I can see how the Undo /History features would make great use of the DAG graph data structure used by GEGL.
Q: How hard will it be to log the GEGL graph evolution to disk in real-time using perhaps a rolling log? What is the best approach for an idea like this?
This would be really great! I want to use the data to archive my "art flow." From that data I can maintain my own list of personal art recipes. I should note that one of my workflows is to export the final art piece to PNG. I don't keep the GIMP file around in this case which might have some history stored.
Many thanks for the help and thanks for GIMP!
~fooledbyprimes
enable a GEGL graph evolution log
On 10 September 2016 at 23:12, Philip R. Dutton wrote:
I ran across much talk and some implementation of GEGL. I can see how the Undo /History features would make great use of the DAG graph data structure used by GEGL.
Q: How hard will it be to log the GEGL graph evolution to disk in real-time using perhaps a rolling log? What is the best approach for an idea like this?
For the approach, pippin and I sketched together a basic spec a couple
of years back.
https://mail.gnome.org/archives/gegl-developer-list/2012-June/msg00004.html
https://git.gnome.org/browse/gegl/tree/docs/journal.txt
"How hard" is always a tricky question to answer... One would have to implement such a Journal, including persistence and wiring up to follow GEGL graph changes. These tasks would require one to be fairly comfortable with C programming. Some GObject experience would be a benefit.
*However*, I believe the GEGL graphs used in GIMP are still "short lived" - used for the duration of one operation and then applied destructively. Meaning that there is no one graph which represents the entire document and thus the evolution of your artwork. It may be possible to try to stich together a sort of journal from all these , but probably there would be need for a significant amount of GIMP specific logic in addition... Not sure of the feasibility here.
Jon Nordby - www.jonnor.com
enable a GEGL graph evolution log
Hey,
On Sat, Sep 24, 2016 at 07:23:30PM +0200, Jon Nordby wrote:
On 10 September 2016 at 23:12, Philip R. Dutton wrote:
I ran across much talk and some implementation of GEGL. I can see how the Undo /History features would make great use of the DAG graph data structure used by GEGL.
Q: How hard will it be to log the GEGL graph evolution to disk in real-time using perhaps a rolling log? What is the best approach for an idea like this?
For the approach, pippin and I sketched together a basic spec a couple of years back.
https://mail.gnome.org/archives/gegl-developer-list/2012-June/msg00004.html https://git.gnome.org/browse/gegl/tree/docs/journal.txt[...]
*However*, I believe the GEGL graphs used in GIMP are still "short lived" - used for the duration of one operation and then applied destructively. Meaning that there is no one graph which represents the entire document and thus the evolution of your artwork. It may be possible to try to stich together a sort of journal from all these , but probably there would be need for a significant amount of GIMP specific logic in addition... Not sure of the feasibility here.
Other than what Jon already said, I wanted to point out that if you ran gnome-photos [*] with G_MESSAGES_DEBUG=all and GNOME_PHOTOS_DEBUG=gegl, then it logs an XML representation of the graph whenever something causes it to change. The final graph is stored persistently (as XML) in ~/.local/share/gnome-photos.
Since the editing UI is relatively simple compared to GIMP, we use snapshots to undo a whole series of operations, instead of undoing every single change in the properties. I think this is similar to transactions in Jon's references. The snapshots are again just XML in memory.
All this is pretty straightforward in gnome-photos, because, unlike current GIMP versions, it is structured for non-destructive editing.
Cheers, Rishi
[*] You'd need at least version 3.20.x.
