[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

[Ember-ruby]

(pixel 7p, default app) i checked the exif, but there doesn't seem to be anything directly relating the RAW and JPEG, but the filenames are the same, other than the extension, wouldn't that be good enough?

[FibreTTP]

The Camera app (at least on Pixels) now saves JPG and RAW files in the same directory (which is fine, but) with the naming format: PXL_YearMonthDay_HourMinuteSecondMillisecond.RAW-<01.COVER.jpg | 01.MP.COVER.jpg | 02.ORIGINAL.dng>

• JPG: PXL_20231225_041836351.RAW-01.COVER.jpg
• RAW: PXL_20231225_041836351.RAW-02.ORIGINAL.dng

Where the date and time is in UTC (I think... the time is at least).

There still doesn't seem to be any EXIF tags that denote which raw file belongs to what JPG (and vice versa).

[gabemcg]

Yes, this is causing raw and jpg to not be auto stacked when uploaded. I also noticed a strange bug on my wife's phone where the Raw (DNG) files don't have the correct orientation when uploaded from her Pixel 6 Pro (taken with the default camera app). The Jpg files and thumbnails for both jpg and dng files appear with the correct orientation but when you open the dng file in the android app they show up rotated 90 degrees counter clockwise. They appear correctly oriented when viewed in a web browser, and even via partner sharing on my phone. It seems to be just her phone's immich app that displays the wrong orientation for raw files. The Google Photos App on her phone shows them correctly as well.

[joaocsousa]

@gabemcg I noticed the orientation issue too. I'm on a Pixel 9 pro.

[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

[justin13888]

A simple question...so is anybody working on automating stacked photos currently? If not, I might just write an experimental PR to work it out

[bo0tzz]

Auto stacking will be covered by #1673, which is in the works.

[Danilado]

I don't completely understand how the stacking feature works with albums. It seems like I can't add a couple of stacked photos to an album on web (when adding to album, they apper unstacked) but I can do that in mobile app. Then, inside the album on mobile, the stack appears in the album showing the amount of photos in the stack but if I try to view them, only the first picture in the stack is accessible.
I guess the feature doesn't yet work with albums, so the question is: Will the stacked photos be supported in albums in later releases?
I would find this feature very handy

[lgrawet]

There is also a feature opened for stacked photos in albums, external libraries...
You can vote for it! > #6387

[brownphotographic]

+1 to stacking raw and jpeg

Is this on a roadmap somewhere? (Is there a roadmap I can review?)

PhotoPrism's implementation is quite good... just review that and adopt a similar approach?

[jrasm91]

Auto attacking is on the roadmap.

https://immich.app/roadmap

[brownphotographic]

Thank you...

And thanks for the link.

[cuu508]

Roadmap says "auto stacking burst photos". Is stacking JPG+RAW pairs also planned?

[cuu508]

Ah, thanks for the tip, @bo0tzz!

I upgraded, and now see this:

There's now a "Stack" option–great! But what's confusing now, these two photos are already stacked.

[bo0tzz]

That seems like a bug, photos that are already stacked with eachother obviously shouldn't be detected as duplicates. Can you report an issue for that?

[cuu508]

Ah, OK – I'll re-run the duplicate detection job, and if the issue remains, I will report it.

[jrasm91]

@brownphotographic 1, except workflows are also on the roadmap.

[spyfly]

Is stacking JPG+RAW pairs also planned?

Would be great to include HEIF+RAW stacking aswell, newer Cameras like the Alpha 7IV support this.

[terinjokes]

Is there a way to choose which item of a stack is used as the preview when photos are manually stacked? On my instance there seems to be little rhyme or reason to which is chosen.

[Quadrubo]

#8498

[carsten12]

Hello,

not knowing whether it is the right place but I wanted to share my technical research on Panasonic TZ-101 and Sony A6700 with respect to stacking. Find my findings below. There is some chance, that the mechanism is used for other models.

From my point of view, stacking (1) JPG and RAW (2) Bursts (3) Brackets and (4) edited images would be a great enhancement. The feature should be used (1) optional when importing (2) running on demand on (2a) all or (2b) a selection of images. Manual intervention to stack/unstack should be possible. Taking this need, I wrote some quick-n-dirty scripts to load the data into (1) immich with immich-go, which has a stacking feature mainly for mobile phone photos by name (2) photo prism, which can use time/location and/or uuid, and/or file name and (3) darktable with an existing script that uses date/time.

My analysis has shown that Sony will not use EXIF:ImageUniqueID. It will use MakerNotes:SequenceLength tag to announce three cases:
0: there is a burst. MakerNotes:SequenceFileNumber will count up from 1 to number the pictures of the burst
1: this is a single shot
other: this is a bracket, EXIF:ExposureCompensation is distinguishing the pictures of the bracket

Panasonic also doesn't use EXIF:ImageUniqueID. It will use MakerNotes:BurstMode for the cases
0: this is a single shot
1: is is a burst, MakerNotes:SequenceNumber will count the images of the burst
2: this is a bracket, EXIF:ExposureCompensation is distinguishing the pictures of the bracket

As the filenames are like they are, you need to sort them first, read an image, check on the mode, and process them accordingly.

Hope this helps to get such a nice feature!

BR,
Carsten.

[skaza2125]

Is this related to auto stacking just for bursts or also RAW+JPEG for phones? I think the same feature for non burst photos would be great. I have the same issue in my Pixel 9 pro xl and would love for the raws and processed to be stack like they are in Google photos

[mainrs]

Yes, that is the plan. See #2479 (comment). For the mean time, you can use something like this: https://github.com/tenekev/immich-auto-stack I have it running on my home server and it works for your use case.

[skaza2125]

Do you use any custom stacking at all? the default only found about 164 photos to stack but i know for sure I have more than that : (, over 1500 of them, taken on a 9 Pro XL. NOt sure if its just not searching through all 20K photos I have or something?

[shawnphoffman]

Piggybacking on all of the previous discussion, automated photo stacks would be a really nice solution for scanned photo projects as well. Specifically, photos that are scanned and have writing on the back so the back is scanned as well.

The Epson FastFoto can detect handwriting on the back and include a scan of that as well with "_b" appended to the filename.

Example:

Misc_0028.jpg (Original)

Misc_0028_a.jpg (Enhanced)

Misc_0028_b.jpg (Back)

It would be amazing if photo stacks could be configured to handle things like this. Similar to the previous conversation that recommended matching filenames with different file extensions. This could take that a step further to handle matching filenames with a matching regex pattern or something. It would help keep related photos together for future processing (e.g. ML the backs to extract metadata to apply to the originals)

[bo0tzz]

Does that scanner write any information into the EXIF that can be used to link the files together?

[shawnphoffman]

Does that scanner write any information into the EXIF that can be used to link the files together?

It doesn't appear to do so. It only appends _b for the back scan and _a if it performs any enhancements.

The only metadata it adds is CreateDate if you specify the time period before scanning.

[Extarys]

I'm also looking for something similar as I'm preparing to scan 3 box full of pictures hehe

[shawnphoffman]

I'm also looking for something similar as I'm preparing to scan 3 box full of pictures hehe

FWIW - I've had a lot of success with @dfyx tool below.

I forked it and added a bunch of my own logic to it to suit my needs. I basically updated it to stack anything with a similar basename with the primary asset priority logic going as follows:

1. A modified version of the photo based on a filename patterns (_mod, _a)
2. Base photo
3. RAW
4. Back of the photo

[dfyx]

I've created a small tool that does what I need for my usecase: https://github.com/dfyx/immichtools (I've uploaded a windows build, you should also be able to build it for linux and macOS)

For now, I use a regex on the filename for stacking which is why I run it on individual directories instead of the whole library at once. For example, IMG_1234.CR2, IMG_1234.JPG and IMG_1234_whatever.JPG are all considered variants of the same image. I have also included the option to search subdirectories for matching files because I put my edited photos in a subdirectory.

For the main image of a stack, the tool prefers images from subdirectories (because this is where I store my edits), then non-raw, then raw.

Example:

ImmichTools.exe autostack -h "https://immich.example.com/" -k mysupersecretapikey -r -m "/data/2025.02.14 Some event"

-h and -k are required to specify the server and API key
"/data/2025.02.14 Some event" is the path to a directory in the form that Immich sees
-r will recursively search subdirectories for files with matching names (for example if you have "JPEG" or "Edited" subdirectories)
-m will copy metadata (date and location) from the raw file to other files if needed

[albebert]

@dfyx
allway the same : .ORIGINAL.dng and .COVER.jpg
PXL_20250405_142136468.RAW-02.ORIGINAL.dng
PXL_20250405_142136468.RAW-01.COVER.jpg

i think that is the same for all pixels phones.

thanks :)

[dfyx]

Ah, alright. Right now, my tool only looks at the beginning of the name because I have mine in an external library as IMG_1234.cr2, IMG_1234.jpg, IMG_1234_small.jpg and so on. I will see if I can find an intuitive way to fix that.

[mainrs]

@dfyx allway the same : .ORIGINAL.dng and .COVER.jpg PXL_20250405_142136468.RAW-02.ORIGINAL.dng PXL_20250405_142136468.RAW-01.COVER.jpg

i think that is the same for all pixels phones.

thanks :)

That is also the case for phones that use Google Camera as their camera app, with Pixel phones using it by default. I had a script for pixel phones specifically that I used, but I re-provisioned my homelab and I am not sure if the script got lost or not. If I find it, I'll ping you here @albebert :)

[dfyx]

Should be fixed now. I'm not on the right machine to create a release build right now but if you either wait or build it yourself from the latest main, it should work.

[albebert]

@dfyx : seems to work thanks

[Majorfi]

Hey everyone,
I’ve been working on a Go-based version of the immich-auto-stack (which was awesome but not compatible with the latest Immich releases) to better suit my workflow and tech stack. It’s not a full 1:1 port but replicates the core features and has been running smoothly on my 13k photo library. It has:

• Automatic stacking based on filename and date (by default, but can be customized)
• A few options to configure the result and the assets to stack
• Sorting options so you can choose the parent asset

If you're interested, check it out:
👉 https://github.com/Majorfi/immich-stack

Docker support is here!
Would love any feedback or contributions!

[dewi-ny-je]

I wish it were integrated into immich.

[alehel]

There seems to be two different kinds of conversations going on here. One about stacking based on similar photos (burst mode for instance). The other one about combining RAW+JPEG. It may have been pointed out already, in which case I apologise, but these are two very different things.

If one has photographed in RAW+JPEG, and those images are in a stack, the RAW+JPEG images should still be "merged" together within said stack. Several desktop applications support this, ApolloOne and Lightroom are two examples. There, a merging of RAW+JPEG is the default behaviour. I've attached an example of how this looks in the ApolloOne application.

The typical behaviour here would be for the application to show the JPEG, but offer the ability to download the RAW file. This means that if someone wants to make edits to an image, they can base those edits on the RAW file, but without cluttering up the image library with what looks like a bunch of duplicates.

[TKaluza]

Absolutely. I have the feeling that not many people actually read through it. Stacking and pairing are very basic features in most professional software, so it would make sense to separate them from the current stacking feature.

In reality, it’s just two different things. Maybe we shouldn’t even call it “stacking.” Ideally, this should (and could) happen automatically. A manual option might be useful if someone keeps many different edited versions of a photo—but that’s not really Immich’s focus.

I once started a discussion on this, but it was overlooked:
#17697

[ginko-leaf]

I don't know anything about anything, but I just wanted to pop in to +1 on the ability to stack raws+jpgs automatically. I basically want the Adobe Lightroom behavior: jpg and raw are treated as the same image, transparently. Ideally with a single filename.xmp file corresponding to filename.raw and filename.jpg. None of this filename.jpg.xmp business.

I don't know if there is like a 'feature bounty' somewhere but I would be happy to chip in to pay to get this done.

[mainrs]

I think for this to happen it would be great if someone that has knowledge about the code base could chime in and provide information on how and where this would have to be implemented. It would be great to have a MVP working before tackling down more complex tasks.

A good starting point could be auto-stacking of images that have the same Image ID or XMP Unique ID (if this is not already a thing).

The main question would probably be: when would the process of finding these groupings trigger? The easiest would be to check against the internal database and see if an image with the same unique ID already exists and if yes, apply the stacking. This would probably need schema changes, which should be fine!

Then, the specific feature request could be converted into an issue that people can work on. I am not sure if bounties are enabled for this repository though :)

[trommegutten]

Support for captureIdentifier (PhotoIdentifier/DocumentID) to group photo variants #stacking #versions #edits

Immich today assigns a unique asset ID per file, which works well for ensuring file-level uniqueness.
What’s missing is a systematic way to recognize that multiple files are actually variants of the same capture (for example: iOS original + portrait edit, or RAW + exported JPEG).

Without such a link, stacking currently depends on manual action or fragile heuristics — filenames can change, timestamps shift, and bursts or exports become hard to distinguish.

That’s why identifiers like PhotoIdentifier (Apple/QuickTime) and XMP:DocumentID stand out: they are robust, persistent, and designed to survive edits and exports, making them ideal candidates for grouping versions of the same photo.

⸻

Proposed behavior

On import (with XMP sidecar taking precedence if present), Immich should ingest a captureIdentifier in this priority order:

1. PhotoIdentifier (Apple QuickTime/HEIC/ProRAW metadata)
2. XMP:DocumentID (Adobe/XMP workflows, some Android/RAW)
3. If neither exists → autogenerate a new UUID and store it as captureIdentifier

If two or more assets share the same captureIdentifier:

• Suggest auto-stacking
• Could use the identifier for duplicate review and version management.

Database change:

• Add one nullable field to asset:
  • captureIdentifier TEXT NULL

⸻

Why not use other metadata IDs?

Several existing fields are not reliably unique or stable enough:

• Exif:ImageUniqueID → Often missing, reused, or inconsistently written by vendors.
• Filename + timestamp → Altered by export, AirDrop, editing, timezone shifts.
• XMP:InstanceID → Changes on each save; cannot link original + edits.
• Device/local IDs (e.g. deviceAssetId) → Platform-specific, not portable, don’t survive migration.
• Heuristics (time + camera model + GPS + perceptual hash) → Helpful as fallback, but probabilistic; can misgroup bursts or HDR brackets.

⸻

Why PhotoIdentifier and DocumentID?

• PhotoIdentifier → 128-bit UUID stored in QuickTime/HEIC metadata. Remains constant across original + edited/portrait variants. Represents one capture.
• XMP:DocumentID → Stable 128-bit UUID persisting across edits/exports in RAW/Adobe workflows.

Both are true UUIDs:

• Length: 128 bits
• Possible combinations: 2^122 ≈ 5.3 × 10^36 (practically collision-free)

They are deterministic, extremely collision-resistant, and widely used in real workflows.
They align with Immich’s non-destructive philosophy: multiple versions, one capture.

When these are missing, an autogenerated captureIdentifier ensures every asset still belongs to a capture group, even if only containing itself.

⸻

Example (exiftool)

$ exiftool -PhotoIdentifier IMG_9330.HEIC
Photo Identifier : 7AFBD03D-837C-419A-9D2E-7358C8932017

If helpful, I also shared a write-up of this idea here: #21118

[dewi-ny-je]

The most basic feature is stacking/grouping/collapsing/whatever of raw+jpg, and it's the easiest to implement since filename and shooting time are identical or within milliseconds.

The likelihood of mistakes is next to zero.

All the rest is nice but probably much less common.

[Rolf-Smit]

I just want to add some extra thoughts.

I have been using Immich for the past year to compare it to PhotoPrism (I have been a long time PhotoPrism user and have a library of more then 100.000+ photos). However even with external auto-stack scripts Immich cannot replace PhotoPrism for me personally, even though I very much like everything else about Immich (it is truly well built and fast). The main culprit for me is the pretty bad support for RAW image file workflows.

Not only is stacking RAW + JPEG not natively implemented, but the bigger issue is that even if you create these stacks through other means (manual or external script) the album view does not support stacks, the same is true for search and the locked folder (and 'explore' although in the 'explore' feature I kinda understand it, since it is supposed to show the raw folder structure).

In PhotoPrism it seems to work all a bit more intuitive, as if from day one they thought about having the same image in multiple formats stored, it seems to be a core part of what PhotoPrism is.

So maybe this is the wrong discussion to add this information to, but in my opinion auto-stacking itself is not so much an issue (since external scripts solve that very well), the bigger issue is how these stacks are being treated, shown and used (inconsistently) throughout Immich.

• First step: Better support for stacks throughout Immich (albums, search etc.)
• Next step: auto-stacking (which may prove more difficult, as it may have a lot of different use-cases)

[dfyx]

I agree in principle but to make that happen, we would probably have to better define what a "stack" means. Some see it as multiple versions of the same image (RAW, JPEG, maybe denoised DNG or an edited version) while others use the feature to stack burst shots and I'm sure there are others with yet a different approach. Optimizing behavior for one of these approaches may break workflows for others.

The current behavior of stacks in albums and search seems to come from an interpretation where individual photos in a stack are mostly treated as different. They can have different metadata and you can add them to albums separately. Therefore, you can't just display the whole stack in those views because not all of the stack's photos might fulfill the criteria to be shown.

The ideal solution would be to properly introduce the concept of "variants" where all variants of a photo share (most of?) their metadata and get added to albums as an atomic unit but I have no idea how to represent this in the UI.

[nerdlich]

Maybe I am seeing this too simplistic, but in my view the reason for doing a stack always boils down to grouping photos together where one photo (the one on top of the stack) is the one I want to see, whether that's in an album, in the library or anywhere. It doesn't matter whether I stacked RAW+JPG or bursts or brackets or other reasons for "similar" images.