Avoid variable expansion while exporting to gimp

[jenshannoschwalm]

If we are running darktable as a gimp plugin we might want to do regular exports using the path defined via the variable expansion.
But for the "final export" to the temp directory the filename must stay as defined in the darktablet/gimp API protocol.

Fixes #20283

@wpferguson can you confirm this fix?
@TurboGit ok with this "work around"?

[wpferguson]

@jenshannoschwalm testing now...

[wpferguson]

@jenshannoschwalm I tested with your latest push.

The image gets exported to %LOCALAPPDATA\Temp\darktablegimpexport_??????/image.exr. GIMP responds with an error Opening /path/to/image failed and then a (NULL) plugin could not open image. The image did open in darktable. When I exited darktable is showed the exporting message, and I found the file. Whatever needs to be sent to GIMP to tell it where the file is doesn't seem to be happening.

[jenshannoschwalm]

You can test the gimp interface by providing the command line parameters as
darktable --gimp file anyvalidfilename

and will see what is presented as the gimp protocol. GIMP takes the filename between <<<gimp gimp>>>
(It should not get confused by any other log text - we agreed on this with gimp team)

darktable --gimp file /home/hanno/BilderRaw/Tests/xtrans/DSCF9639.RAF
     0.0003 [dt starting]
 darktable --gimp file /home/hanno/BilderRaw/Tests/xtrans/DSCF9639.RAF
     7,0988 [export_job] exported to `/tmp/darktablegimpexport_L0YBK3/image.exr'
<<<gimp
/tmp/darktablegimpexport_L0YBK3/image.exr
gimp>>>

Could you port what you see?

[wpferguson]

C:\Users\bill>"C:\Program Files\darktable\bin\darktable.exe" --gimp file \users\bill\Pictures\testdata\Y5050211.ORF
     0.0001 [dt starting]
 C:\Program Files\darktable\bin\darktable.exe --gimp file \users\bill\Pictures\testdata\Y5050211.ORF
Magick: caught exception 0xC0000005 "Access violation"...
C:\Users\bill>"C:\Program Files\darktable\bin\darktable.exe" --gimp file C:\users\bill\Pictures\testdata\Y5050211.ORF
     0.0001 [dt starting]
 C:\Program Files\darktable\bin\darktable.exe --gimp file C:\users\bill\Pictures\testdata\Y5050211.ORF
    19.7824 [export_job] exported to `C:\Users\bill\AppData\Local\Temp\darktablegimpexport_BN4EK3\image.exr'
<<<gimp
C:\Users\bill\AppData\Local\Temp\darktablegimpexport_BN4EK3\image.exr
gimp>>>

So it appears that darktable is doing it's parts, as long as you give it the full path, including drive, but GIMP doesn't seem to be picking it up.

[jenshannoschwalm]

So it appears that darktable is doing it's parts, as long as you give it the full path, including drive, but GIMP doesn't seem to be picking it up.

1. At least not with this PR
2. Or did you test with master?
3. Not sure how GIMP does exactly check the logs, it could be it gets confused by the --gimp xxx line in logs? I will remove that log while in gimp mode just to make sure

[wpferguson]

I'm building with your PR, so I'm pulling it from what you built with but it's pretty close to master. I had to install potrace to get it to compile.

I started GIMP with the exported image file as an argument and it did open it.

[jenshannoschwalm]

ok, i have force push an update that doesn't log the "possibly misleading" line. Would you be able to re-test?

[wpferguson]

Still doesn't work. Checked and the image.exr file is created but GIMP still isn't picking it up. '

EDIT: Read the GIMP code and discovered a debug flag to set. Here's the output...

more_output.txt

[jenshannoschwalm]

@Jehan any idea?

[jenshannoschwalm]

@wpferguson please this again :-) I think i have found the problem, we still used dt_util_fix_path() while we should avoid expansion.

The recent version includes -d imageio reporting if we - allow/must not - use the variable expansion.

[wpferguson]

Works for me 🎆

[Jehan]

@Jehan any idea?

I have not followed the whole thing here, but looking at the last few comments, it looks like whatever was a problem here got fixed, right? :-)

[jenshannoschwalm]

@TurboGit seems we can go for this PR