Re: [Gimp-developer] deriving transform by comparing image before/after edit

[Adalbert Hanßen <Adalbert Hanssen gmx de>]

Hello Bill,

your problem could be solved much easier and doing that would open great
new things to Gimp:

Let us for short think of all of Gimp's functions (I just cal them
functi, but their names of coursee would be unique within Gimp), which
are accessible from any menu function, being split into a parameterizing
function parametrize_functi and an actual operating one operate_functi, i.e.

* parametrize_functi just asks for all parameters (if there are any) but
does not process them

* imagine thatparametrize_functi createsa log entry "functi, pi1, ....,
pin"with all necessary parameters which it has obtained when the ok
button is pressed (if there is one),

* those log entries would be recorded.

* when the ok button is pressed,operate_functi functions would be called
through one central placewith those recorded parameters. Thefuncti
areidentified by the firstentry in each recorded parameter set.

Then it would become very easy to automatically re-run such recorded
steps . Your question “How exactly did I achieve this result?” would
become superfluous.

Would that not be great?

In Gimp, all theses log entries should be recorded strictly inthe
sequence in which they are done. Of course, the number of the tab to
which they go (and the plane in it and son on) also have to be recorded.
When the clipboard is used, that has to be recorded too and if the
clipboard-content doesnot originate from this particular Gimp session, a
copy of it has to be stored to make everything reconstructible. (IfGimp
does not get notified when the system clipboard is changed outside of
Gimp, Gimp has to maintain ashadow copy of a clipboard with an image and
it has to compare the current system clipboard containing an image to
its own shadow copy, in order to storea reconstruction copy of the
system clipboard image, if any operation happens, where the system
clipboard from outside of Gimpis actually used in Gimp).

With such log-keeping, even all “destructive” functions could be undone
in Gimp without much storage requirements: In the worst case, the
sequence of processing steps would have to be redone from the very
beginning. One could speed that up by storingintermediate result toa
file, until the session ends.

When a picture is stored or exported, some cleanup has to be done to
eliminate all logged operations and possibly also all stored system
clipboards which entered the flow of operations but do not not influence
any non-stored result any more. Idemat the end of a session or closing a
tab,

Of course, loading an image has also a parametrize function: The one
which lets you select the image to be loaded and the tab to which it
goes. Of course, switching to anothertab also has to be recorded. When
you copy something from one tab and paste it e.g. to a plane in another
tab, the associated processing logs become “mangled” because the
pasted-to history now also depends on the history of the pasted-from tab
and its associated image.

The number of parameters of the functi differ from one function to
anotherone. There could be none, like in transform to grayscale. There
could be only a few, like in setting a threshold transforming to B/W or
when doing some brightness or colour manipulations. There would also
onlybe a few like when pasting something from the clipboard to a
specified place (i.e. the coordinates of the placement and possibly an
orientation angle). There could be functions which have many parameters,
like cutting out some fancy shape.

The whole log filecould be a plain ASCII file! It would besomething like

tab1, openFile, full_path_to_it

tab1, rotateImage, centerx, centery, degrees

tab1, cropImage, x1, y1, x2, y2

tab2, openFile, full_path_to_that

....

All selection operations, all cloning operations, all matrices used in
convolutions, all colour adaptation operations, really everything you
can do with Gimp could be recorded like this. Theoretically you could do
that by hand by just exactly write down each processing step together
with its parameters. But some functions have quite a lot of parameters,
like e.g. cutting parts with an irregular shape, or using
paintbrush-operations and the like. But a computer does not get tired
when it is told to do tedious things over and over.



Debug and improve mode

In such an Interpreter approach, one could also provide a mode, where
each parameterizingfunction is called again, but then all parameterizing
steps are preset as they were done when the Gimp session was recorded.
In the debug and improve mode the user can vary what wasdone before and
continue, when the varied parameters have been input.

If proper construction schemes are used, the parameterizing functions in
this special mode are exactly the same ones as they are used in the
normal mode, the only difference being that instead of only an ok
button, you also haveadditional buttons "interactive", "skip" and "exit".

* When you click on "interactive", you continue with arbitrary Gimp
processing steps, returning to the place after each step where you
clicked "interactive" in the old recorded procedure after each Gimp
processing step. Of course, during such an operation, all additional
functions and parameters are recorded as well, such that the whole debug
and improvesession yieldsa new plain ASCII description of all Gimp steps
used to achieve the new final result.

* When you click in "skip", the actual processing step is left out and
Gimp proceeds to the next step from the processing list.

* When you click on “exit”, the whole batch processing in the special
debug and improve mode is left and Gimp continues with its normal mode
(i.e. without continuing to process not yet processed recorded logged
operations).



Feasibility

Most probably, the main conditions for such an approach are already
there, the only missing thing would be to create and manage the log entries.

I have never looked at a single line of source code of Gimp, neither
have Iunderstood the programming paradigmsof Skript-Fu or of the other
programming tools. Perhaps almost all what I spoke abut is already
there. Possiblythe basics are also already in Gimp’s native image
storage format. Are they?



Further Benefits

1. It becomes possible to also include the logged processing stepsinto
the metadata of an exportedresult, even into aJPEG-file! Of course all
processing steps in other tabs which had no influence aparticular stored
or exported oneshould be cancelled in that.

2. Later edit such a sequence in order to improve a result achieved
earlier, but with a slight modification!

Recorded log fileswould be a great teaching resource: One could publish
“best practice” sequences: The original picture + all processing steps
leading to a particular result. The steps could be numbered as above and
some explanations why the authordid the particular processing steps
could be published in addition.

For that purpose I proposeto let the Gimp user record oral explanation
blocks to each processing step. If the authorgoes back some steps, I
would automatically wind up therespective oral explanations and replace
them with new ones, if he decides to proceed differently.



In the firs half of the 1980’s I lead a project, I which we designed an
electronics unit controlling microscope equipment. It was designed in
Modula 2 and it used exactly such an architecture. This system was using
an 8086 microprocessor and firmware completely in ROM. Butit could be
adapted by plugging additional function boardsinto the rack. The central
point in the software were lists, containing function names, boundary
conditions for the parameters and the like plus the entry points of the
operational functions andthe stack lengths of the parameter-depot for
them. The real sequence of operational functions could be called almost
as quickly in sequence as if they had been written in sequence as
function calls. All parameter checking, all conversions and so on were
done before.


Adalbert


2018-07-08_Standard

Am 28.12.20 um 11:02 schrieb Bill Ross:
> Thanks Adalbert,
>
> I don't want to reverse the transformation, just characterize the
> forward transformation enough so that I can train neural nets to
> suggest one I like when shown any photo. You might say I want to use
> my before/afters to derive a filter for each photo, then train nets
> with large numbers of
>
>     input_pic_i -> filter_i
>
> so the net can learn to improvise a new filter for each new pic to my
> taste.
>
> ...
>
> Here's an example of how neural nets can pick up my taste in pairing
> photos:
>
>     http://phobrain.com/pr/home/siagal.html
>
> Bill