Darktable - Export to Piwigo - Unexpected change of filename

[urhekryd1]

Short description: Unwanted filename change at the end of darktable-piwigo-workflow. For me, it seems to be a bug, but maybe, I do something wrong.

Long description: (I’m german, sorry for my not perfect english) I use darktable in combination with piwigo, My equipment: Several Apple Computers, MacOs 12.01, Darktable v. 4.0.0, Latest Piwigo-Version [Version 12.3.0]

My workflow I collect my raw and jpg photo files on my Macbook Pro in folders (finder) and rename them first (Example filename: „2022-08-03_10492501_ury.dng“)

Settings Darktable: „Show global preferences - Import“: „keep original filename“: true

Next step: Import folder with photos in darktable (in lighttable) After import: DT „image information“ shows the correct filename, this is as expected: „2022-08-03_10492501_ury.dng“

DT Export - storage options - target storage: „piwigo“ „edit metadata exportation“: EXIF data: √ metadata: √ only embedded: not checked

Set Piwigo Server Settings and select Export-Folder Set format and global options Export photo to piwigo, ...that works perfectly √

BUT: The filename of the uploaded photo in piwigo has changed to: „darktable.PP96Q1.jpg“ This is unwanted. I want to maintain my self choosen filename

Now my question: Why is this? Why there is a new filename although I’ve choosen „keep original filename“? Is there something in the settings, I missed?

• darktable version : 4.0.0
• OS : MacOs 12.01
• piwigo: 12.3.0

Additional context

• Can you reproduce with a RAW or Jpeg or both? both
• Are the steps above reproducible with a fresh edit (i.e. after discarding history)? yes
• If the issue is with the output image, attach an XMP file if (you'll have to change the extension to .txt)

2022-08-03_10492501_ury.dng.txt

• Is the issue still present using an empty/new config-dir (e.g. start darktable with --configdir "/tmp")? I don't know
• Do you use lua scripts? no

Did you buy darktable from an application store ? no

[TurboGit]

For me, it seems to be a bug, but maybe, I do something wrong.

You are not doing something wrong. The export filename cannot be changed and is following a pattern darktable.XXXXXX.<ext>.

[urhekryd1]

Ok, thank you for information, ...I understand.

For me, this fact seems to show an inconsistency in DT:

-> If you export a photo through "storage options" -> "file on disk" you receive a file on disk, which have the same filename like the one, you imported, and also the same filename like the one shown in DT under "image information"

-> BUT if you export a photo through "storage options" -> "piwigo" you receive a filename (in piwigo) following a pattern, which has nothing to do with your original photo (and there is no convenient way for you, to trace it back)

Do you know the reason for this divergence?

[ptilopteri]

piwigo set it's own filename for it's database and that is what you see. If you open the image in piwigo, you can see it's real filename in the information.

[urhekryd1]

"piwigo set it's own filename for it's database..." Sorry, ...not true.

The more right is, like TurboGit commented: "The export filename cannot be changed and is following a pattern darktable.XXXXXX.."

I made a test some minutes before. This is my download list from Firefox:

Both files were downloaded from piwigo:

• The lower file is a previous via DT uploaded file, note the changed filename "darktable.xxxxxx.jpg
• The upper file was previously uploaded from my Macbook directly to piwigo, it shows my original filename, which hasn't changed, ...and thus, this is perfect for a professional workflow.

So, the comment from ptilopteri: "...piwigo set it's own filename..." is definitely not right.

Does anybody see a chance, that someone is going to solve this? I'm a pretty new user of darktable, and I can tell, I appreciate it! But I need beneath the capabilities of DT additionally a program, to share my photos.

DT has already an export option to piwigo, which works well (except change of filename). Piwigo is open source, like DT. For me, it complements DT perfectly, ...but I think, filenames shouldn't change at all, if the photographer doesn't want it. What is your opinion?

[gi-man]

darktable is using the piwigo api to upload the images. The darktable code generates a temporary filename for the upload. It looks like the file you uploaded might be using their website interface, so it might allow a different filename scheme.

I did a search thru the piwigo website and the current API might be able to handle a different approach, but it will need for someone to do the code and test it.

[urhekryd1]

gi-man wrote:

The darktable code generates a temporary filename for the upload.

Yes, that sounds right for me. And the problem is: This "temporary filename" ends up in piwigo then, and is not anymore "temporary" but permanent!

and:

It looks like the file you uploaded might be using their website interface, ...

Yes, my test upload was performed via piwigo website, ...of course, no change of original filename here

and:

I did a search thru the piwigo website and the current API might be able to handle a different approach, ...

Yes, I hope so, because it's like I said before: " ... filenames shouldn't change at all, if the photographer doesn't want it." If DT offers a possibility to export to another "system", it should work consistent and as expected, otherwise this option makes no sense.

finally gi-man wrote:

..., but it will need for someone to do the code and test it.

Yes again! I'm not able, to "do the code", but if possible I could help with testing. I think, there are good reasons to adjust this. Therefore my question: Is here somebody able to do it, ...and more important, convinced that it should be done?

I would appreciate it. Thanks for now.

[quovadit]

@urhekryd1 : I already created a PR which uses a different upload-approach without renaming the files: #11696 Hopefully it will be part of 4.2

[github-actions[bot]]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.