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: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
