starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

Import: Add option to render raw files into originals instead of sidecar #1319

New issue

Closed

opened 2026-02-20 00:10:30 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 00:10:30 -05:00

Owner

Originally created by @valpackett on GitHub (Feb 9, 2022).

Is your feature request related to a problem? Please describe.

For the "add raw files now, maybe edit them later" workflow, the fact that PhotoPrism places the rendered jpegs into the sidecar folder can be annoying, because when I edit them later and add to the originals directory, a simple (fast) reindex operation would just ignore them, while a full one would just stack them together with the sidecars. But I want my edits to fully replace the sidecars, deleting them from disk!

Describe the solution you'd like

Add a configuration option that changes the destination of raw-to-jpeg rendering from sidecar to originals.
This way, when exporting from a RAW editor I could just overwrite the auto-converted file in place inside the originals directory.

Describe alternatives you've considered

The other option would be to:

notice new jpegs with the same name in the originals directory (on a fast reindex too)
make them default in the stack (#1028)
and if an option is enabled, automatically delete the sidecar jpeg

But that's a bit more complicated (and not mutually exclusive, both can be added)

Additional context

¯\_(ツ)_/¯

Originally created by @valpackett on GitHub (Feb 9, 2022). **Is your feature request related to a problem? Please describe.** For the "add raw files now, maybe edit them later" workflow, the fact that PhotoPrism places the rendered jpegs into the sidecar folder can be annoying, because when I edit them later and add to the originals directory, a simple (fast) reindex operation would just ignore them, while a full one would just stack them together with the sidecars. But I want my edits to **fully replace** the sidecars, deleting them from disk! **Describe the solution you'd like** Add a configuration option that changes the destination of raw-to-jpeg rendering from sidecar to originals. This way, when exporting from a RAW editor I could just overwrite the auto-converted file in place inside the originals directory. **Describe alternatives you've considered** The other option would be to: - notice new jpegs with the same name in the originals directory (on a fast reindex too) - make them default in the stack (#1028) - and if an option is enabled, automatically delete the sidecar jpeg But that's a bit more complicated (and not mutually exclusive, both can be added) **Additional context** ¯\\\_(ツ)\_/¯

deekerman

2026-02-20 00:10:30 -05:00

closed this issue
added the
idea

please-test
labels

deekerman commented

2026-02-20 00:10:31 -05:00

Author

Owner

@lastzero commented on GitHub (Feb 9, 2022):

The sidecar path can be configured using PHOTOPRISM_SIDECAR_PATH

👉 https://docs.photoprism.app/user-guide/advanced/folders/#sidecar

@lastzero commented on GitHub (Feb 9, 2022): > The sidecar path can be configured using `PHOTOPRISM_SIDECAR_PATH` 👉 https://docs.photoprism.app/user-guide/advanced/folders/#sidecar

deekerman commented

2026-02-20 00:10:31 -05:00

Author

Owner

@valpackett commented on GitHub (Feb 9, 2022):

You mean setting the sidecar path to be the same as the originals path?

I guess this might work as a workaround, but I don't want the YAML files in the originals directory, just the JPEGs rendered from RAWs.

@valpackett commented on GitHub (Feb 9, 2022): You mean setting the sidecar path to be the same as the originals path? I guess this might work as a workaround, but I don't want the YAML files in the originals directory, just the JPEGs rendered from RAWs.

deekerman commented

2026-02-20 00:10:31 -05:00

Author

Owner

@lastzero commented on GitHub (Feb 9, 2022):

It's not a workaround, it's designed to work that way. What we don't have are additional options to specify the location based on file type, but we already have more options than most users have time to understand. So I think this is also "as designed".

@lastzero commented on GitHub (Feb 9, 2022): It's not a workaround, it's designed to work that way. What we don't have are additional options to specify the location based on file type, but we already have more options than most users have time to understand. So I think this is also "as designed".

deekerman commented

2026-02-20 00:10:31 -05:00

Author

Owner

@Rolf-Smit commented on GitHub (Apr 11, 2022):

It would be nice though to be able to rescan (parts of) the library and make the scanner detect the new JPEG files, stack them (with the original RAW file), and if PhotoPrism previously generated a JPEG sidecar file automatically remove it.

@Rolf-Smit commented on GitHub (Apr 11, 2022): It would be nice though to be able to rescan (parts of) the library and make the scanner detect the new JPEG files, stack them (with the original RAW file), and if PhotoPrism previously generated a JPEG sidecar file automatically remove it.

deekerman commented

2026-02-20 00:10:31 -05:00

Author

Owner

@lastzero commented on GitHub (Apr 12, 2022):

They should be detected already. You are welcome to open a GitHub Discussion if you have specific questions or think you found an edge case or a potential bug.

BTW, this should create sidecar JPEGs in Originals:

PHOTOPRISM_SIDECAR_PATH: "."

Has anyone tried it? Docs say you can provide an absolute or RELATIVE path. This has also been discussed and mentioned in other places. Unless there is a bug, I don't think we need to implement any other options or settings.

@lastzero commented on GitHub (Apr 12, 2022): They should be detected already. You are welcome to open a GitHub Discussion if you have specific questions or think you found an edge case or a potential bug. BTW, this should create sidecar JPEGs in Originals: ```yaml PHOTOPRISM_SIDECAR_PATH: "." ``` Has anyone tried it? Docs say you can provide an absolute or RELATIVE path. This has also been discussed and mentioned in other places. Unless there is a bug, I don't think we need to implement any other options or settings.