I run into a peculiar erroneous behavior in naming files upon export. In the export dialog I select jpg, sRGB etc. and for the output size I set 1920 x 1920 (so that the longest side of the exported image is always at 1920px).
For the export folder and file name I include the export dimensions as follows: ~/Pictures/$(FILE_NAME)_$(EXIF.YEAR)_$(WIDTH.EXPORT)x$(HEIGHT.EXPORT)
Now, for the most part, it works as intended, but for some random files the export dimensions are set incorrectly at 0x0 (a number of example output file names below):
If I export a single image with the 0x0 dimensions again (right after the initial export), the same thing happens. But if I open the offending image in the darkroom and export from there, it writes the file name with the correct dimensions.
I output without exif, so I cannot consult this info, but despite the 0x0 file suffix the exported files have the correct 1920px dimension.
There are two images in the export with the 0x0 dimensions: _T5A8385 and _T5A8430. I had a quick look inside the log, but nothing stood out to me (not that I have much of an idea what to look for…).
Have you tried to export an image again from lighttable after switching once to darkroom and back? I bet it works then as expected. My suspicion from a short look at the coding is that the variable for the export sizes is only filled correctly, if the pixel pipe is executed once in the darkroom.
@Photoniker So, I did some more testing: Let’s assume you have edited an image in darkroom. Back in the lighttable and after exporting, the exported files have the expected name (according to the pattern you mentioned above). Now, I remove the image from the darktable database (without deleting the xmp), and add them again to the database. The thumbnail on the lighttable looks like it was edited (also the litle icon in the upper right corner indicates this), but now the exported file name has 0x0 for the export size.
Do you recall if you ever re-imported the affected images?
Anyway, it makes sense to raise an issue on Github.
Thanks for looking into this!
The images are fairly recent, so they were not deleted and re-imported (but the images were added to a pre-existing folder). But I share the database between the flatpak and a source-compiled version of dt (never at the same time!). Maybe this causes trouble.
Anyway, I’ll try to figure out mentioning it on Github.
This sounds similar to Github issue 18210, opened a year ago and closed due to inactivity. Perhaps you should open a new issue with a reference to 18210, or I could reopen 18210 and you add your comments and a reference to this thread. Let me know if I should reopen …
I added the $(WIDTH.CROP)×$(HEIGHT.CROP) variables to the lightroom tooltip, as you described, and it also shows the 0x0 dimensions. So the issue is pretty much identical… but not quite.
I then went into the darkroom, made some modifications, go back to the lightroom, but the tooltip still shows 0x0. But the export now works with the correct dimensions.
I think, it would be best, if you could re-open the old case and I’ll add my comments. Thanks!
I looked at 18210 and figured out what was going on. There’s not a fix for it yet, but there is a work around in the form of a lua script that I’ve attached to it. The script forces a thumbnail refresh when you change an image and leave darkroom or switch to another image. A side effect of the thumbnail refresh is that the lighttable idea of the image information gets refreshed.