Jpeg file loaded with script-fu not considered imported

[cyril42e]

Hi,

When I open a JPEG file with Gimp 2.10, either from the menu File/Open or with the command line "gimp file.jpg", the image is considered imported (this is in accordance with the spec), and there an entry "Overwrite file.jpg" available in the Menu entry (with the hint "Export the image back to the imported file in the import format").

But when I load the same JPEG file with script-fu:

Code:

(define (myload file)
    (let*
        ((image (car (gimp-file-load RUN-INTERACTIVE file file))))
        (gimp-display-new image)
    )
)

Code:

gimp -b '(myload "file.jpg")'

then the image is not considered imported: the Overwrite menu item is not available, the image name when trying to close Gimp is "file.jpg-1" instead of "[file] (imported)-1", and when choosing to export the proposed file name is file.png by default (thus PNG file).

This is annoying because instead of being able to save the result in 2 actions (click overwrite menu item + click export button), I now need 5 actions (click export menu item, change the file name extension or select the existing file, click export button, click replace button, click export button). I can mention that my actual script is more complex, performing some preprocessing, before leaving the hand to the user to perform manual operations and save (and the time saved by the automatic preprocessing is somewhat reduced by the extra steps for saving...).

I didn't find a way in script-fu functions to explicitly import the file, and I feel that the current behavior is not consistent with the specification aforementioned, Is it expected and wanted ? Should a file loaded like this considered imported, or should there be a way to make it considered as imported with script-fu ? Or did I miss something ?

Thanks

[Ofnuts]

(09-01-2022, 04:25 PM)cyril42e Wrote: Hi,

When I open a JPEG file with Gimp 2.10, either from the menu File/Open or with the command line "gimp file.jpg", the image is considered imported (this is in accordance with the spec), and there an entry "Overwrite file.jpg" available in the Menu entry (with the hint "Export the image back to the imported file in the import format").

But when I load the same JPEG file with script-fu:

Code:

(define (myload file)
    (let*
        ((image (car (gimp-file-load RUN-INTERACTIVE file file))))
        (gimp-display-new image)
    )
)

Code:

gimp -b '(myload "file.jpg")'

then the image is not considered imported: the Overwrite menu item is not available, the image name when trying to close Gimp is "file.jpg-1" instead of "[file] (imported)-1", and when choosing to export the proposed file name is file.png by default (thus PNG file).

This is annoying because instead of being able to save the result in 2 actions (click overwrite menu item + click export button), I now need 5 actions (click export menu item, change the file name extension or select the existing file, click export button, click replace button, click export button). I can mention that my actual script is more complex, performing some preprocessing, before leaving the hand to the user to perform manual operations and save (and the time saved by the automatic preprocessing is somewhat reduced by the extra steps for saving...).

I didn't find a way in script-fu functions to explicitly import the file, and I feel that the current behavior is not consistent with the specification aforementioned, Is it expected and wanted ? Should a file loaded like this considered imported, or should there be a way to make it considered as imported with script-fu ? Or did I miss something ?

Thanks

It is not mentioned anywhere that there is a one-to-one mapping between the API functions and UI actions (which is fortunate, otherwise you wouldn't be able to script variants of theses UI actions). While some API calls can replace several UI actions,many UI actions require several API calls.

You can use gimp-image-set-name and gimp-image-set-file-name to make the image ready to save where you want.

[cyril42e]

(09-02-2022, 11:40 AM)Ofnuts Wrote: You can use gimp-image-set-name and gimp-image-set-file-name to make the image ready to save where you want.

Thanks, but it seems that gimp-image-set-name does not exist in Gimp 2.10 (not mentioned in the reference manual, and triggers an error unbound variable: gimp-image-set-name), and I did try gimp-image-set-filename without success (it allows to change the name but not the extension that is still changed to png for export). gimp-item-set-name does not seem to apply to image either (error gimp: Gimp-Core-CRITICAL: gimp_item_tree_rename_item: assertion 'GIMP_IS_ITEM_TREE (tree)' failed)

(09-02-2022, 11:40 AM)Ofnuts Wrote: It is not mentioned anywhere that there is a one-to-one mapping between the API functions and UI actions (which is fortunate, otherwise you wouldn't be able to script variants of theses UI actions). While some API calls can replace several UI actions,many UI actions require several API calls.

True, got it. Still I can't find the API calls to replace this UI action and reach the same state... 

[Ofnuts]

Hmm. Indeed set-name doesn't exist, the name is taken from set-filename. And I can't find a way to twist the arm of the file saver dialog.

Possible solutions:

* Set a different default extension (doable since 2.10.22 IIRC)(Preferences ➤ Image Import & Export ➤ Export file type)
* Define your own export action, and associate a hot key to it.

And in radical departure, I wrote a script that does things a bit differently to quickly process a lot of files, a single call to the script :

• Execute some post-processing
  
• Export the file
  
• Close the file window (aka "display")
  
• Determine the next file in sequence
  
• Open that file in a window
  
• Execute some preprocessing
  

So you go from one image to the next with a single keystroke.

[cyril42e]

(09-04-2022, 09:00 PM)Ofnuts Wrote: Possible solutions:

* Set a different default extension (doable since 2.10.22 IIRC)(Preferences ➤ Image Import & Export ➤ Export file type)
* Define your own export action, and associate a hot key to it.

Thanks for the tips. Changing the default extension indeed saves one step (the slowest), so that's good.

However I didn't find anything about custom export actions, are you talking about writing a script ? I should indeed be able to reproduce the overwrite behavior (copy - flatten - save), maybe even without the confirmation dialog.

(09-04-2022, 09:00 PM)Ofnuts Wrote: And in radical departure, I wrote a script that does things a bit differently to quickly process a lot of files, a single call to the script :

• Execute some post-processing
  
• Export the file
  
• Close the file window (aka "display")
  
• Determine the next file in sequence
  
• Open that file in a window
  
• Execute some preprocessing
  

So you go from one image to the next with a single keystroke.

Sounds nice indeed, however in my case I need to provide two different images to the script, and they have to be manually selected. But I will keep this in mind for future needs, thanks.

[Ofnuts]

(09-05-2022, 09:36 PM)cyril42e Wrote:

(09-04-2022, 09:00 PM)Ofnuts Wrote: Possible solutions:

* Set a different default extension (doable since 2.10.22 IIRC)(Preferences ➤ Image Import & Export ➤ Export file type)
* Define your own export action, and associate a hot key to it.

Thanks for the tips. Changing the default extension indeed saves one step (the slowest), so that's good.

However I didn't find anything about custom export actions, are you talking about writing a script ? I should indeed be able to reproduce the overwrite behavior (copy - flatten - save), maybe even without the confirmation dialog.

Yes, that's the file-jpeg-save call. Keep in mind that it takes a drawable (usually I do a gimp_layer_new_from_visible). Once saved do a gimp_image_clean_all so that Gimp doesn't pester you with the unsaved XCF when you want to quit.

[cyril42e]

(09-06-2022, 07:08 AM)Ofnuts Wrote:

(09-05-2022, 09:36 PM)cyril42e Wrote: However I didn't find anything about custom export actions, are you talking about writing a script ? I should indeed be able to reproduce the overwrite behavior (copy - flatten - save), maybe even without the confirmation dialog.

Yes, that's the file-jpeg-save call. Keep in mind that it takes a drawable (usually I do a gimp_layer_new_from_visible). Once saved do a gimp_image_clean_all so that Gimp doesn't pester you with the unsaved XCF when you want to quit.

Thanks for the advice, I used gimp-image-duplicate and gimp-image-flatten, seems to work as well, and gimp-file-save in order to avoid having to provide lots of quality parameters (anyway I did not find how to read the original file quality, so defaults are ok). gimp-image-clean-all is nice to save another click, thanks (I'll ignore the documentation warning "Note that save plug-ins must NOT call this function themselves after saving the image." as it is a "private" plugin ).

Here the complete script in case it can help someone:

Code:

(define (gimp-overwrite image)
 (let*
   (
     (image_copy (car (gimp-image-duplicate image)))
     (image_name (car (gimp-image-get-filename image)))
   )
   (gimp-image-flatten image_copy)
   (define drawable (car (gimp-image-get-active-drawable image_copy)))
   (gimp-file-save RUN-NONINTERACTIVE image_copy drawable image_name image_name)
   (gimp-image-delete image_copy)
   ;(gimp-image-clean-all image)
 )
)

(script-fu-register
   "gimp-overwrite" ; func name
   "Overwrite silently" ; menu label
   "Silently overwrite the current JPEG file" ; description
   "cyril42e" ; author
   "" ; copyright
   "2022" ; date
   "" ; image type
   SF-IMAGE "Image" 0
)  

(script-fu-menu-register "gimp-overwrite" "<Image>/File")