Bug 511225 - Allow hide/show sidecar image (not metadata) for the same basename
Summary: Allow hide/show sidecar image (not metadata) for the same basename
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Sidecar (other bugs)
Version First Reported In: 8.8.0
Platform: Other Other
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-10-27 16:50 UTC by Webysther
Modified: 2025-11-06 08:35 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Canon 50D manual (573.39 KB, image/png)
2025-10-27 16:50 UTC, Webysther
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Webysther 2025-10-27 16:50:28 UTC
Created attachment 186235 [details]
Canon 50D manual

SUMMARY

This feature is not related to software itself, but rather to the general behavior of cameras. Nowadays, it’s important to have an option to hide or show auxiliary files that are not metadata — such as the extra JPGs generated by Samsung phones or Canon cameras.

I believe that, at first, it’s essential just to ensure the removal of duplicates for those who need to work with RAW files, since the current grouping behavior actually causes more problems when used to address this situation:

* When grouping RAW and JPG files (as in HEIC or CR2 cases), the JPG appears at the front of the group, which disrupts the entire RAW-based workflow.
* In the future, it would be useful to explore opportunities for using auxiliary files in image processing, as done in other tools. However, that’s not the focus of this request.

Below the option "Sidecar file names are compatible with commercial programs" can have and option with:

"Hide sidecar images generated by cameras".

ADDITIONAL INFORMATION

The script (https://github.com/dmpop/digikam-recipes-resources/blob/main/dkgroup.py) work partially but it's more a workaround

In the Attachment has my old canon 50d manual as example
Comment 1 Webysther 2025-10-31 04:46:32 UTC
I will expand this with real life examples:

Let's start with this photo:

https://commons.wikimedia.org/wiki/File:Webysther_20150501201754_-_Interior_Sala_S%C3%A3o_Paulo.jpg

This is not a single photo, now it is, but it's not. It's 60 images merged using software, like every panoramic photographer, this is normal. The 60 images are a stack, because they alone mean nothing, but grouped represents 1 single photo, I take lots of sequences to build a few images like this one, every one using RAW+JPEG.

In a first moment I build the single image using the RAW but configured to use as 1:1 the sidecar image, which is less slow than using the RAW, after confirm the photo works, I want for some hours to finish using the RAW.

So, how this works:

RAW+JPEG for every single piece it's not a stack, it's a photo with more 2 sidecar's JPEG+XMP

60 images (composed by RAW+JPEG+XMP) are a stack, manual made

In essence I'm a panorama photographer, I use stack alot and after trying to move to software like digikam, darktable and immich the main problem is the mistake to treat RAW+JPEG as a stack, which is not, this need to be fixed.
Comment 2 Webysther 2025-11-04 21:23:36 UTC
I also opened a discussion on Immich and Darktable to debate the possibilities of unifying a standard or configuration for this; your participation, which is fundamental, would be appreciated.

https://github.com/immich-app/immich/discussions/23397
https://github.com/darktable-org/darktable/issues/19620
Comment 3 Webysther 2025-11-04 21:36:11 UTC
(In reply to Webysther from comment #2)
> I also opened a discussion on Immich and Darktable to debate the
> possibilities of unifying a standard or configuration for this; your
> participation, which is fundamental, would be appreciated.
> 
> https://github.com/immich-app/immich/discussions/23397
> https://github.com/darktable-org/darktable/issues/19620

One of darktable joined the discussion on immich, hope here someone give us some light over this. :)
Comment 4 Maik Qualmann 2025-11-05 07:25:46 UTC
A grouping method, like the one darktable has now implemented with the LUA script (Group RAW/non-RAW), is something we can also do.

However, JPG files are by definition not sidecar files, and we will not treat them like metadata sidecar files (*.xmp). This would contradict the understanding of most users.

Maik
Comment 5 caulier.gilles 2025-11-05 08:57:52 UTC
Hi Maik,

Just for info, to follow your last comment, i remember that some camera generate .thumb file as sidecar, which are in fact a simple JPEG thumbnail container with Exif metadata and more if necessary. This is especially used with RAW shots.

https://forums.windowscentral.com/threads/camera-questions-preview-time-and-thumbs.441056/

My 2 Cts €... (:=)))...

Gilles
Comment 6 Webysther 2025-11-06 07:52:24 UTC
(In reply to Maik Qualmann from comment #4)
> A grouping method, like the one darktable has now implemented with the LUA
> script (Group RAW/non-RAW), is something we can also do.
> 
> However, JPG files are by definition not sidecar files, and we will not
> treat them like metadata sidecar files (*.xmp). This would contradict the
> understanding of most users.
> 
> Maik

Can you elaborate a bit more on:
- "JPG files are by definition not sidecar files" definition from where?
- "contradict the understanding of most users." users from software, workflow or what?

I'm really trying to understand why some users use the RAW+JPEG and have the same problem than me and for others this just don't exist or looks like to being not relevant, this is because:
- Don't shot RAW+JPEG at all?
- Don't need group because the style of the material produced
- Never used commercial like LrC or Apollo that deal with this natural as air.
Comment 7 Webysther 2025-11-06 08:08:20 UTC
(In reply to Maik Qualmann from comment #4)
> A grouping method, like the one darktable has now implemented with the LUA
> script (Group RAW/non-RAW), is something we can also do.
> 
> However, JPG files are by definition not sidecar files, and we will not
> treat them like metadata sidecar files (*.xmp). This would contradict the
> understanding of most users.
> 
> Maik

Using the same terminology, Photo Mecanic deal in the same way with RAW+(non-RAW) which deal with JPG as sidecar files, like in the Photos on mac (ref. https://youtu.be/dqw_Szm0m7E?si=U3-BuUddbglF3v8X&t=179).

I'm not a professional photographer, I use the tips from photographers videos and from Wikimedia commons that they told me centures ago, sounds strange that only in the software community the ideia change, for instance, the video link explain the same I use about RAW+JPEG. If you ask me I can send you dozens of links and material talk about this, but I can't find no one group or using tags for organizing RAW+JPEG, because will be hell on earth, the feeling that I have: i'm missing something?