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

Hi Adlbert,

That might add all kinds of great functionality to gimp, enabling it 
could be optional, although wouldn't handle the old edits I want to 
train nets on so I can just stop editing 'now'. :-)

In planning it, I'd think of what core functions are required for basic 
touchup, so a network could be trained to make optimal use of them once 
they could be worked out mathematically from all one's old edits 
(worst-case, autoadjust 20? numerical sliders til you get the least net 
'distance' from the edited pic, likely faster with some optimization 
library, then accept or reject each best-effort by visual inspection 
before it is used for training). It'd be like having your own custom 
version of equalization but I expect it'd be good and final about 80-90% 
of the time for people who spend less than a few minutes editing each 
photo. I wonder if a joint effort with ImageMagick or other groups might 
be worthwhile, given the possibility for shell-scripting as well as 
within workbenches.

I'm being gradually educated / figuring out how NNs might be applied in 
further discussion here:

https://www.reddit.com/r/computervision/comments/kktdq4/derive_transformation_matrix_from_two_photos/

Bill

https://twitter.com/photoriot/status/1344064933248421889?s=20

On 12/29/20 4:46 PM, Adalbert Hanßen via gimp-developer-list wrote:
> 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
>>
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [email protected]
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
-- 
Phobrain.com
_______________________________________________
gimp-developer-list mailing list
List address:    [email protected]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list