[Feature] Automatic stacking

[mirisbowring]

The feature

Immich has become really great and has some "killer features" in contrast to other solutions like librephotos or photoprism.
Still there is one feature missing i really liked in photoprism.

It's the Photostack.
When i e.g. shoot an Image with my Sony A6500 i can configure the camera to output RAW+JPEG.
The Files will be named ABC001.ARW and ABC001.JPEG (same name except file extension).
If i edit this image on Lightroom e.g. The result is exported as ABC001-1.JPEG (another iteration as ABC001-2.JPEG, etc.).

As far as i understand immich right now, I would have the same photo (example from above) 3 times in the timeline assumed that #2156 is resolved.

Instead, i would like to display only the latest iteration e.g. (...-2.JPEG) as thumbnail and have the option to show all versions in the detailed view.

This Feature would also apply to high frequency photos. Imagine you shoot a fast scene with multple shoots per second and you end up with 30 Photos. You don't want to have each frame separately in the timeline. Instead, those images could be stacked and shown as "single image" with the option to show them all in details.

Besides, thank you for this great work and product and have a nice weekend!

Regards

Platform

• Server
• Web
• Mobile

[bo0tzz]

Can you check the EXIF data of those files and let us know whether there is a matching UUID or such between them?

[mirisbowring]

On the paper you are right. Those are linked photos. Technically, i would display / mark photos (-groups) that contain a RAW Image separately to directly identify them. In short term they should be "mergable" manually.

An automatic approach would still be preferred (probably we could adapt the photoprism approach for this) - like same Filename (with an ascending number) and same camera model, etc.

Especially when shooting many Photos with RAW+JPEG it would be very beneficial. Manually Mapping hundrets of photos is a nogo unfortunately :)

[akoen]

As a first pass combining photos (especially RAW+JPG) with the same base filename taken at the same time would be a killer feature as Immich grows to accommodate DSLR/mirrorless cameras.

[mirisbowring]

I would also add the Camera Model to the comparison - just to make sure :)

[AngelaDMerkel]

I would like to caution against using a file naming technique to handle burst images, because there are many instances where two separate and distinct images could be taken in close sequence and display an incremented filename, but ought not to be stacked. I see the usefulness of this though, and it depends on how each user names their files. In my case, it would cause a serious disruption if automatic, so perhaps a toggle to enable this feature?

[alehel]

All of my RAW and JPEGS have InternalSerialNumber in their exif, which seems to be unique for my camera. One possible way to match RAW+JPEG would be to compare InternalSerialNumber in combination with file name and timestamp.

[lorenz]

I would also very much appreciate this and would be willing to work on it as soon as we come up with a design. All photos shot with my camera are typically JPEG+RAW. My typical workflow is that I import them and like to have the JPEG visible, but the RAW available for download. If I see particularly good photos (or ones which the camera did a poor job) I download the RAW, develop it into a JPEG and would like to upload that JPEG as the new image to show, keeping the attached RAW image. What would also be great is if I could attach profiles (XMP, PP3, ...) which are small (usually text) files containing the settings used to develop a RAW to the JPEG so that if something needs to be changed later or a new RAW development is needed, I can pick up from the development settings of the last JPEG.

[mirisbowring]

Another Case from me:
I have JPEG+RAW and improve the images in Lightroom. Sometimes i don't have "this final image" Its more like "I cannot decide between those 2 or 3 versions - why bot keep them"

Therefore the stack could contain multiple "production fotos" (monochrome, color, etc.)

It should be easy to see all images that are in the stack.

[lorenz]

Yeah, I'd think it would be useful to design with multiple stacked images in mind from the beginning as that will definitely come up.

[mirisbowring]

Probably via an accordion within the sidebar when the stack was opened 🤔

[odoryanse]

I would also like to be able to manually stack photos. In case you use Immich to save drawings, there are slightly different pictures that I would like to stack them.

PhotoPrism didn't do a good job of this, its AI couldn't handle the drawings so it required to rename the file before uploading, which was very annoying.
I think it's very difficult for AI to handle drawings correctly at the moment, so allow user to manually stack photos.

Tysm.

[ShinasShaji]

I could be wrong, but I don't think PhotoPrism stacks images by perceptual similarity. Is that what you were referring to as 'AI' here? It does stack by filename, yes.

[ShinasShaji]

I did some peeking into the EXIF data from a burst taken on an iPad and found that there is indeed a matching UUID called a Burst UUID in the EXIF data. I assume its similar for iPhones as well.

I also found some documentation regarding Apple Tags here.

Here's an example:

135A10E2-A933-42EF-B411-EB1FBA003C12.JPG

and

2FD9EEAD-BA17-4813-9EBF-D44FFDAFA0C0.JPG

Note that the Burst UUID is exactly similar while the Sub Sec Time tags vary.

My two cents is to only rely on UUIDs for matching and stacking photos - I've had issues with PhotoPrism stacking unrelated images due to similar filenames (e.g. Hello.JPG and Hello.MP4 and even Hello_1.MOV into the same stack, if I recall correctly) and stacking unrelated screenshots due to them being imported using PhotoSync at roughly the same time (since they lack Date/Time Original).

A UUID would ensure that none of these conflicts happen, but would be limited to cameras that do write a Burst UUID or similar into EXIF. Alternatively, photos could be manually stacked if the user so desires.

[lorenz]

We'd still have to see if RAW images typically have such an identifier. If yes, that would be optimal however with the wide range of RAW formats available I think it's likely that at least one common format doesn't. So we still have to have a solution if that's not possible.

[lorenz]

So I checked and for my Nikon camera there is no such UUID, at least for regular photos (haven't checked burst, don't think I have any of these in my library). But the EXIF metadata is (mostly) the same between the RAW and the JPEG, so I think camera model + serial number + 10ms accurate creation timestamp all hashed together should produce good results.

[Rydberg95]

Semi related to
#1885

, which also involves handling/using EXIF Burst info.

[sibbl]

I'd also like to move my photo library to Immich but have a bunch of raw files next to jpeg files, which are currently displayed as 2 separate images.

Would love to get this feature 🙏

[ebbyb]

So back in my youthful photography career, I amassed an Aperture vault of 2TB of RAW, JPG, and Photoshop files. (That was pretty good back then) Aperture grouped all these copies/versions into Stacks and made it so easy to find and manage files. I've been waiting for somesort of stacking feature for years and this is the main reason I haven't fully adopted any online solution yet.

It would be amazing to have versions grouped together. If you need more sorce/EXIF data to test, I can provide some more images.

So a big +1 for this feature form me. Thanks for all your hard work. It's great watching this software evolve and grow over time.

[klaus1k]

A thing that has to be considered for this feature is how downloads should be handled.
For my use case that would mostly be stacking of raw + jpeg. The jpeg in front. If I share these as an album with friends, they are only interested in the jpegs, which should in my opinion be able to download.

Or make it possible to choose from options:

• download front files/images only
• download all files
• maybe even: download base files/raws only

[klaus1k]

This sounds like a good solution!
Best would probably be the highest level of arbitration: In the end it shouldn't matter how many images are stacked, what format they are in, or why they are stacked (burst shot, google like "top" shot, developed image,...)

[AngelaDMerkel]

There should be a good default behaviour for handling stacking. A lot of users are discussing this feature in the context of importing their entire lives' photo libraries including RAW and manually reviewing each stack isn't practical. If there is a stacking feature it should involve an automated behaviour on import with clear, fixed rules.

[lorenz]

By default I'd just pick the latest developed image.

[klaus1k]

I also think that this should be there right from the start of this feature - we could start with stacking by filenames as a standard. Later on this could be expanded to ML stacking or whatever...

[jrasm91]

One idea is all files are individual assets that go through the same default pipeline, this makes it really simple.

Then we can let an asset l have a "parent" referring to another asset. This is essentially how live photos work.

Stacked photos are just multiple photos all belonging to the same parent.

We can exclude assets with parents in the main timeline.

We can, during metadata extraction, come up with a way to auto create stacks. We could have some configurable options for what gets automatically linked, etc.

[mardom1]

Not sure if this is implied, but please also allow grouping of files that are in different directories (import library). I have my raw files in a subdirectory to the edited ones.

I.e.

some-album/
  raw/
    IMG_0001.CR3  # Camera RAW
    IMG_0001.JPG  # Camera JPG (if present)
  IMG_0001.jpg  # Manually edited JPG

[ebbyb]

EDIT: welll... sorry, I tried to get that indenting working like mardom1. Failed pretty good. Hope it still makes sense.

I like mardom1's structure, though if I may offer some suggestions:

storage_template/
stack_IMG_0001/ #1
.hero #2
.thumbnails #4
IMG_0001.CR3 # Camera RAW
IMG_0001.JPG # Camera JPG (original in this example)
IMG_0001-20230926.jpg # Edited JPG version added to stack #3
IMG_0001-final.psd # Photoshop version
IMG_0001-final.jpg # Manually edited JPG

Changes and reasoning:
#1 stack_* identifies a folder to process as an image set containing all files and variations.
#2 .hero file specifies user selected display version; defaults to newest created (JPG for easy processing?) file.
#3 versions with duplicate filenames would have creation date appended. (Probably not going to run into that too often, but crossed my mind with the above example)
#4 I don't know if you really need a thumbnail folder, some raw files have built-in thumbnails that may be extractable, but just in case, I'm guessing those of us with a tiny NAS CPU's don't want to process thousands of RAW files more than once. It might be handy just in case. ;)

Anyways, thanks for reading!

[ebbyb]

allow grouping of files that are in different directories

I don't know why that didn't click, but I just did a facepalm. My suggestion is exactly not that.

My stacks are more media management, while your stacks are more (I'll call it something different to reduce confusion) groups. Moving files together suits my needs better, but I totally get the merits of groups.

I've also been thinking about the pros/cons of phashes. (Yeah, just daydreaming) Groups would be better suited if there were some phash detection as groups could be modified easily without moving files. Both could be displayed the same in the UI.

[Willena]

Stacking RAW and JPEGs would be nice. I would make my library cleaner.
Here is what I think it could look like in the library to be able to identify assets with "linked" content

[ebbyb]

Oh! That looks nice with that little icon!

[AngelaDMerkel]

I think it would helpful if there were different stack iconography to indicate (for example) burst images and RAW+JPEG stacks maybe through the inclusion of the aperture blade icon often in use when representing raw files.

[ajnart]

Some kind of badge (RAW + JPG) like on iOS photos app would be very nice

[tleichtw]

I fully agree with the above. There is a huge difference between stacking similar or burst images and a JPG+RAW pair. The former is just a grouping to organise photos, whereas the latter represents the same image in two instances/processing stages. So the latter are very closely linked and if you make a change or delete to one, it should typically affect both.
So ideally it needs a "RAW+JPG" or "JPG+RAW" tag (ideally you could even set the top one) and a number tag for similarity stacks.

[archerne]

I am really loving this stack feature since my phone save the RAW+JPEG. Would it be possible to auto-stack those photos though? I have many many months of photos to go through and stack manually and it has become a major time-consuming adventure. The photos have the same name but different extensions. abc123.dng and abc123.MP.jpg

[ajnart]

Also would love this stacked feature, I always shoot in JPG+RAF (Fujifilm RAW) so it would be nice to have all the files accessible as one inside of immich, like how Photoprism does it or Apple photos showing a RAW/JPG badge on top of the image when you view it in full size, then when you click on the information about it you can download the "original" which is the raw file

[aisbergde]

and what about assigning each item a fingerprint for similarity detection (which is on the road map) and give an option to stack by similarity? Then this could be a setting and stacking could happen for different users by their own threshold.

This should be additional to stacking by a burst id or some other id, detecting related pictures.

[lgrawet]

This is how photoprism is doing it according their documentation.
This would be a good start!
https://docs.photoprism.app/user-guide/organize/stacks/

1. Files that have exactly the same file and folder name are always stacked, for example /2018/IMG_1234.jpg and /2018/IMG_1234.avi
2. Files with related, sequential names like /2018/IMG_1234 (2).jpg and /2018/IMG_1234 (3).jpg may be stacked as well (optional)
3. Pictures were taken at the same GPS position and second (optional)
4. Image metadata contains the same Unique Image ID or XMP Instance ID (optional)

You can change the behaviour for 2 - 4 in [Settings > Library](https://docs.photoprism.app/user-guide/settings/library/).

[lgrawet]

Totally agree with both of you. However, file name is meant to cover most of cases.
For the rest, there is "Place & Time" and "Unique ID" are selected by default in photoprism ("Sequential Name" is not).
What it means is file name is not an option but you can alter defaults for the rest.

[mirisbowring]

But filename does only work if you have an existing folder structure. By default immich stores this in "a database".
Like when i upload today IMG_1 (which was shot 10 years ago) it will be processed and everything is fine.

Tomorrow i go to the store and buy a new camera. I make a test shot and upload it! Unfortunately the camera just used the default naming and this image is also named IMG_1!

According to your approach, immich would import it, check the filename, will see that there is another one with this name (luckily deduplication is based on checksums and not names) and would stack them - falsely!

So there must be metadata verification. Just because photoprism is doing it this way, does not necessarily mean this is the correct way for implementation! Especially since photoprism and immich have an different view on how to organize things.

[ajnart]

But filename does only work if you have an existing folder structure. By default immich stores this in "a database".
Like when i upload today IMG_1 (which was shot 10 years ago) it will be processed and everything is fine.

Tomorrow i go to the store and buy a new camera. I make a test shot and upload it! Unfortunately the camera just used the default naming and this image is also named IMG_1!

According to your approach, immich would import it, check the filename, will see that there is another one with this name (luckily deduplication is based on checksums and not names) and would stack them - falsely!

So there must be metadata verification. Just because photoprism is doing it this way, does not necessarily mean this is the correct way for implementation! Especially since photoprism and immich have an different view on how to organize things.

I think you are mistaken, what @lgrawet demonstrated is that photoprism only uses metadata to stack its photos, with Time and location information. I believe this makes the most sense, names are really arbitrary. Then there is the option to stack them with a unique id (if it exists on the metadata that is) and optionally to merge copies of the same photos (IMG_4302(3).png for a photoshop export for example)

I believe having the stacking feature for edited pictures would also be great, it's what Lightroom does when you do an edit using photoshop

[lgrawet]

More precisely, in their approach they first match "Files that have exactly the same file and folder name" (mandatory) then they try other subsequent optional criterias. This may help to save cpu time...

Immich doesn't save assets in DB. They are stored on disk according this default storage template until v1.92.0

{{y}}/{{y}}-{{MM}}-{{dd}}/{{filename}}

Starting from v1.92.0, all assets remain by default in the upload directory for new installs. See corresponding release notes

[cole21771]

This would be amazing

[WarlockFish]

When will this feature be added? When raw photos cannot be recognized, purple photos will appear 。After Stacked Photos, JPG photos can be directly displayed。
in immich

in photoprism

[qkrrmsdud1]

Not sure if this specifically has been mentioned here yet; I would like to add on that another photo format that would be nice to have auto stacking for would be Google Pixel Pro Res Zoom photos, which auto stack (the original and processed photo) in Google Photos.

[skaza2125]

Is there any update on this one? Just curious if someone is looking at it. Or if the community has settled upon some external solution?

[webysther]

Please, follow this discussion here (#23397 We need to talk about real sidecar images (not metadata) raw+jpeg before Automatic stacking) as RAW+JPEG is not a stack thing.

[Itschotsch]

For this feature, it would be very useful to have a setting that determines which of the files should be displayed.
For example, when a JPG and CR2 file are stacked automatically, should it show the JPG or the raw CR2 file?
I noticed that the raw version of a low-light photo developed by Immich is extremely noisy while the JPG file looks fine.
In this case, showing the raw version would defeat the purpose of the stack.
I am unsure whether this is generally the case or if the raw file is preferred by some, so I would suggest adding a setting for this.

[gibhubb]

CR2 is a RAW file and is going to look bad with all applications until you process it. The JPG is a processed file.

[dfyx]

And CR2 with a sidecar XMP file from me processing it will be closer to what I want than the JPG the camera generates with standard settings.

I would vote for having JPG as the default but an option to change it.

[Goldmaster]

I have a similar issue #24135 with jpg and dng files from Samsung s10. That if I use immich go to upload a folder, they show up as separate files not automatically stacked as 1 image.

The main thing also is that it results in 2 separate xmp files being created such as .dng.xmp and .jpg.xmp rather than .xmp like normal. Which results in duplicate info about the same file. Immich should by default use .xmp rather than the other other option.

[CuriousJames]

This is the EXIF for the JPG and the CR2 shot from my Cannon 80D, I can't see any UUID or alike, but I think if they're the same file name in the same folder and same photo taken time (within 2s - as CR2 can take longer to save) just one is .CR2 and the other is .JPG then that should stack, and ideally not suggest either for deletion as a duplicate of the other (I see this a lot in the immich duplicates tool).
IMG_0629.CR2_exif.txt
IMG_0629.JPG_exif.txt

[CuriousJames]

Additionally it would be great if it could auto-stack my google photos imports, for edited photos where the only link is the file name say photo.jpg and photo-edited.jpg and again in the same folder and same photo taken date/time.
20221010_094042-edited.jpg_exif.txt
20221010_094042.jpg_exif.txt

[bobloadmire]

has there been any consensus on a direction for this? I wouldn't mind stacks to be both RAW+JPEG and also rapidly shot images. Google Photos does this, and you just need the single tumbnail with an icon indicating its a stack. if you are interested in the photo, see its a stack, you just click it to see what versions there are of it. I don't think its that serious.

[ggmoritz]

On the Pixel 10 Pro there can be 3 photos for created at once when zooming in more than 30 times. google photos neatly groups them:
original jpg - PXL_20260120_171307163.BURST-02.original.jpg.txt
dng / raw - PXL_20260120_171307163.BURST-03.ORIGINAL.dng.txt
ai upscaled jpg - PXL_20260120_171307163.BURST-01.jpg.txt

[big1tasty]

I'm really excited if this feature will be implemented!
I really liked the Pixel Edits but a lot of times at least on my 9a the jpegs get overprocessed.
That's why i always shoot RAW + JPEG. Since i also occationally print my pictures i often use the RAW and edit them slightly before printing.

Naming of pixel:
PXL_20260121_195958829.RAW-01.COVER.jpg
PXL_20260121_195958829.RAW-02.ORIGINAL.dng

[blarrbot]

i hate to look a gift horse in the mouth, immich is great, but why has this stack feature been implemented in API for over a year now and still hasn't made any progress in the GUI? raw+jpeg is supported on just about every smartphone with a decent camera, and every actual camera body made in the last few decades. if you use raw+jpeg, which anyone serious about photography does, you are punished by immich displaying doubles of every photo you take, forcing you to either rely on third party scripts, or abandon immich entirely.

please, this really needs to be addressed.

[Majorfi]

In the meantime feel free to take a look at https://github.com/Majorfi/immich-stack

No GUI, but configurable so you can do that automagically

[jschneider]

But does not work with locked folders, unfortunately. :-(

[Majorfi]

Correct. I worked with the locked folder to bring stacks there but:

• The locked folder require a "Session Token" instead of an API key
• This session Token can be created (in theory) via the API with an API key, but this does not appear work currently
• So the only way is to provide your email/password which is far from ideal
• Even if you do this a got a "Session Token", the stacks do not persist on the Locked view (cf: Stacked assets (including locked) displayed independently in memories #18721)

I have a code ready for this once it's fixed, but for now, the locked folder is locking it

[kryzar]

Adding my grain of salt to the discussion. I also think it would be great if Immich could store RAW+JPEG files as a single pair.

Here is the use-case. Some of my photos are taken on a pro camera. When I'm about to shoot truly meaningful moments, I switch RAW+JPEG. This gives me both a JPEG file, and the possibility to edit the picture later. I think it would be very convenient if these pairs were be stored at the same place, and managed as two parts of a single asset.

Immich could display the JPEG, store the RAW (but not display it as a separate asset), and leave the possibility to download the RAW, delete it, or delete the whole pair.

This topic has been mentioned before (e.g. here on Reddit), and some people store their JPEGs and RAWs separately. I don't want to do that, as I would prefer the benefits of having one master source of storage. This makes it easier to organize, keep the RAW and JPEG files in sync. I also don't do so much editing, so having Immich act as a storage service for the RAW files is perfect for me to see what I can do in a quick glance.

I don't know how to implement this feature, but I think it would suit a lot of people who casually use a good camera.

[Alessandrolosco]

I am a Fujifilm user and those cameras are very good in converting raw-to-jpeg in cameras (they support various film-like simulation that the community loves). I shoot raw+jpeg all the time (i've been shooting in this way for years / TBs of photos).

I also want to migrate from photoprism, and this is the one and only feature that i miss from there. Photoprism automatically detects and stacks together raw+jpeg+similar photos.

[kryzar]

I'm using Immich for my phone photos, but I'm still waiting for that feature to use Immich for my DSLR photos! :)

[justin13888]

I don't think it's coming immediately at this point but it's totally doable in theory.

[blarrbot]

I don't think it's coming immediately at this point but it's totally doable in theory.

Photoprism has had this feature for a long time at this point. It's quite simple to implement, but the trick is finding the various naming schemes used by devices, e.g. Google Pixel camera app names photos differently from how a traditional camera body does (which is typically just filename.jpg/filename.raw). So there would likely need to be some device-specific whitelisting for the different naming schemes. A bit tedious, but honestly there aren't that many different ways to name paired photos. What Photoprism lacks is the ability to manually stack photos. All Immich really needs to do is add the ability to select photos and stack them in the GUI, so we can manually fix existing photos, then they can spend as long as they'd like on the actual automatic stacking that Photoprism has. If this feature is really this low of a priority, then at least give users something in the meantime to de-clutter our existing photo library that doesn't require third party CLI/API tools. At this point I'm just running Photoprism and Immich together while I gauge which one I prefer. Immich would win if it had stacking, but Photoprism is my current daily driver until I can fix my cluttered raw+jpeg library.

[mirisbowring]

Maybe even a workflow option would be nice.

[sixtyfive]

Has there been any indication by the dev team that RAW+JPEG stacking will eventually be implemented and whether it will then apply to existing installations (perhaps via a simple re-scan) or require setting up an entirely new database?

Edit: may linking the currently still maintained fork of the immich-auto-stack script be helpful to someone...

[bo0tzz]

The indication is that this thread is still open; if we didn't want auto stacking in Immich, we would close it.
As mentioned in #2479 (reply in thread), it should eventually become possible through workflows.

[sixtyfive]

Thank you, bo0tzz!

[jeggy]

Maybe I'm a bit out of the loop on everything regarding workflows. But would it mean potentially I could create a workflow for this, and it would be a workflow for all users on my instance?

[bo0tzz]

No, workflows are per-user.

[Alessandrolosco]

No, workflows are per-user.

What if there's only One user that uploads RAW files?

[KairuiLiu]

Summary of the auto-stacking discussion

1. Existing samples and implementations

Auto-stacking is the user-facing result: related images end up in the same stack. The tricky part is that “related” means different things to different people. The requests in this thread roughly fall into six buckets:

• RAW and JPEG/DNG files from the same shutter press
• Native camera or phone bursts
• RAW, COVER, and BURST variants produced by devices such as Pixel phones
• Edited versions exported from Lightroom, Photoshop, or Google Photos
• Exposure brackets and HDR sequences
• Scanned photo sets containing the original, an enhanced version, and the back side

I used AI to help summarize the samples and EXIF data shared in this thread. I also used it to review the detection logic in Majorfi/immich-stack.

• immich-stack already implements automatic grouping based on filenames, paths, and timestamps. By default, it uses a normalized basename with a one-second tolerance. It also supports device-specific regexes, edit suffixes, file-type preferences, and primary asset selection.
• Apple burst photos share the same BurstUUID, even when their sub-second timestamps differ. Sample
• The Sony A6500 RAW/JPEG sample has the same InternalSerialNumber and ShutterCount. Lightroom exports may also contain RawFileName and PreservedFileName, pointing back to the source RAW. Sample
• The Canon sample has no shared UUID, but the RAW and JPEG files share the same basename, camera serial, capture time, lens, and exposure settings. Sample
• Sony and Panasonic MakerNotes expose fields such as SequenceLength, SequenceFileNumber, BurstMode, and SequenceNumber. Combined with exposure compensation, they can distinguish regular bursts from exposure brackets. Sample
• Pixel files usually share a capture prefix, as in .RAW-01.COVER.jpg and .RAW-02.ORIGINAL.dng. Sample
• In one Pixel 10 Pro set, one file’s EXIF timestamp is about ten seconds later than the others. A fixed one- or two-second window would miss that group. Sample
• Google Photos edits may change the dimensions and orientation while preserving the original capture time, device, exposure, and location. Filename markers such as -edited need support from metadata or visual similarity. Sample
• RAW files may live in a subdirectory while JPEGs and edits remain in the parent directory. Directory proximity can increase confidence, but different directories should not rule out a match. Example
• Scanned photo sets may use _a for an enhanced front and _b for the back. Some files also include a Backside XMP field. Example

2. Possible detection rules

Some signals are strong enough to establish the relationship directly:

• A shared Burst or Capture ID
• Camera serial plus ShutterCount
• Explicit lineage fields such as RawFileName, PreservedFileName, DocumentID, or DerivedFrom
• Known device patterns, such as the Pixel capture prefix

Other signals are useful when combined:

• A matching normalized basename
• A reasonable file-type pair, such as RAW + JPEG/DNG
• Matching or nearby DateTimeOriginal values
• Matching camera, lens, focal length, exposure, ISO, or GPS
• The same or a related directory
• A sufficiently small image embedding distance

There are also a few good ideas we can borrow from immich-stack:

• Recognize explicit version suffixes such as -edited, -final, -crop, -hdr, and ~2
• Extract Pixel capture keys or BURST... identifiers with regexes
• Keep group detection separate from primary asset selection
• Prefer COVER, edited, or processed files as the primary asset
• Use version numbers and file size as tie-breakers between files of the same type

3. I don’t think this should require a Workflow

A maintainer mentioned in this comment that auto-stacking could be implemented through Workflows. I would rather see it as a built-in Immich feature.

Auto-stacking needs a consistent way to handle detection rules, confidence levels, suggestion state, dismissals, incremental processing, and backfilling existing libraries. Most users will expect to enable the feature and get sensible results without setting up a Workflow first.

Workflows could later control when detection runs or which confidence level is eligible for automatic stacking. Immich would still provide the default detection layer shared by the web app, mobile apps, and future features.

4. How this relates to existing duplicate detection

Immich already has duplicate detection and manual stack operations. Duplicate detection uses image embeddings to find visually similar images, and some of those results are already good stack candidates: bursts, lightly edited photos, and repeated exports.

The existing similarity pipeline could provide the first batch of stack suggestions. It could also serve as supporting evidence for later metadata-based detectors.

Visual similarity still misses some important cases. JPG+DNG and RAW+JPEG pairs may fail the current threshold because of differences in RAW previews, color processing, cropping, or orientation. Two photos from separate captures may also look nearly identical.

Immich already extracts BurstID, BurstUUID, CameraBurstID, and MediaUniqueID into autoStackId, but that field is not currently used to create stacks. Later detectors could use this data alongside RAW/JPEG relationships, device-specific rules, and edit lineage.

5. My plan

I’d like to start with the smallest useful end-to-end version: feed existing high-confidence duplicate and near-duplicate matches into a new Stack Suggestions flow.

The first version would be intentionally conservative:

• Create suggestions only, with no automatic stacking
• Store the suggestion type, confidence level, and supporting evidence
• Process new uploads incrementally and backfill existing libraries in batches

If the first version has a low enough false-positive rate, we could later add optional automatic stacking for high-confidence relationships.

The flow would remain explicit: find candidates, classify the relationship, create a suggestion, and let the user’s settings decide which confidence levels may be stacked automatically.