[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

[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.

[TKaluza]

I totally get where @Rolf-Smit is coming from.
@nerdlich, I see your point, but I’d really appreciate a foolproof way to automatically stack/group “obvious” things—while still having the flexibility to manually organize photos, like bursts or similar.

[gibhubb]

While it would be interesting to have variants, at least a RAW+JPEG is easy to have. If there are 2 files with the same name but different file type, stack those and display the JPEG.

[PANICBUTT0N]

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.