Question: how much disk space is consumed by AI Denoising an image in Lightroom Classic 14.4?

[DonH]

Now that running AI denoise in Lightroom Classic no longer creates a new DNG, I assume it has to be storing a large amount of data somewhere.  Before I go crazy with denoise (the results are often amazing!) and consume many GB of storage in my Lightroom library files, I wanted to get an idea how much space this takes.

I have no way of measuring the library file size increase after a single operation, so I tried the same operation in Adobe Camera Raw (17.4) and found that denoising one 30.8MB Nikon D500 raw file created a new a 6.1MB .acr sidecar file.  So it appears that, at least in this case, denoise created an additional file that is about 20% the size of the original file.

Does anyone know if Lightroom Classic does something similar?  If it does, that means that running denoise on 5GB of raw files (only about 162 D500 files) will result in growing the library files by 1GB.  This is better than a whole new DNG, but it isn't insignificant, and would be part of library storage, not raw file storage!

As an additional question, will subsequently turning off (unclicking) denoise on an image in LRC eventually free up that additional storage requirement?

I use a Mac but the question would apply the same on Windows

Thanks in advance for any insight!

Don

[Rob_Cullen · Accepted solution]

This quote is taken from the link to the Lightroom Queen's blog-

https://www.lightroomqueen.com/whats-new-in-lightroom-2025-06/

"when we tested them on a 24 MB raw file, applying Super Resolution created approximately 48 MB of extra data, while applying only Raw Details generated around 18 MB of extra data. Denoise had the lowest impact, creating only about 5 MB of extra data. In Lightroom Classic, the new pixel data is stored in the .lrcat-data file alongside the catalog. In Lightroom Desktop Cloud mode, it’s saved to the cloud database."

[DonH]

Thank Rob, that's exactly what I was trying to figure out.  I suspect the ratio of denoise data to raw file size will vary by raw file type, degree and type of raw compression , etc.

Don

[C.Cella]

A SuperRes Image is way more than 2x the size of the RAW from which it orginates.

RAW file is 36,2Mb 
XMP no edits = 44Kb
XMP with SuperRes = 162,2MB

ACR saves Enhance data into a more efficient format the .acr

.acr with SuperRes = 129,7MB

The big problem is that LrC is inefficient at writing into XMP even on SSD.
This is how long it took to save the SuerRes data into the XMP form the moment of clicking "Save" to the moment the XMP is finally written.

LrC should adopt the .acr format to store this data which is both faster to read and write ( XMP requires all data be encoded as text) and is lighter than XMP.

For DNGs the SuperRes is saved in the file, in the inner-sidecar, so DNGs become massive.

Still not as big as with the baked SuperRes.

Looking at the .lrcat-data doens't fully reveal the impact of this big data for our storage capacity and workflows.

[robert36972564]

Oh no! 😮😣

Please, Adobe, store all of this data only with the RAW files!

My Lightroom Catalog already is about 1 TB in size, mostly due to (mostly standard sized, not 1:1) previews but also several GB for the data/db files of the catalog. The LR Catalog is stored on a high-end 2 TB SSD (just upgraded from 1 TB a few weeks ago), to make culling etc. fast enough.

I really DO NOT want to fill up this pricy storage with data that I or LR won't need the next few months/years after first processing. This kind of data belongs to archive/cold storage!

I mean I could manually move that .lrcat-data folder to my HDD and place a symbolic link or junction, so that LR doesn't notice. But this presumably would heavily slow down the AI processing while editing.

@Adobe Simply store all such data next to the RAW files.

My current projects (RAW + XMP files) are stored on another SSD for speedy edits and imports. The AI Denoise data would be there too. When I'm done, they get moved to external HDDs (consuming about 14 TB currently), not blocking scarce SSD space anymore.

I was so happy to hear about non-destructive AI denoise without monstrous DNG-files anymore. But now they broke the batch workflows (see other community threads) and clutter storage space... I will skip the 14.4 update. 😑

[C.Cella]

@robert36972564 For many ears all Ai mask and image data has been stored in the lrcat-data
That's where LrC keeps the Ai "images".

They "Enhance images" are are lighter than storing the actual image in a sidecar as the article that @Rob_Cullen has provided explains.

Your catalog is on a 2TB SSD, your .lrcat-data and will not be getting massively bigger anytime soon.
On the other hand you will have to pay attention to storage when storing the SuperRes into the sidecars.

I suggest to use VC to do SuperRes and any Enhance non destructive. 
Edit a VC and save it as snapshots ONLY when is needed to edit perhaps in ACR or LrD Local.
This way the SuperRes will not end up in the XMP until the moment is needed.

Skipping LrC 14.4 is not necessary, with a few precautions you can manage.

.

[robert36972564]

Assuming 5 MB of storage per ai denoised image, the remaining 900 GB will be enough for about 184.320 images. BUT not really as the 900 GB will be also slowly filled with further database and preview data.

(And take into account, that if the Catalog storage/SSD is full, you really cannot work with LR at all anymore until you fix that issue. - No more edits, imports, VCs, preview generation / viewing old images, cloud sync issues)

It won't be an immediate issue. Also not for the next year (if the assumption stays valid). But Adobe is wasting their user's money with this implementation and thats not a good thing.

If it is possible to store this data within 5 MB (or whatever) on the catalog drive, there can be no technical reason, why it wouldn't be possible to store the exact same data with similar compression, encoding and size as an additional RAW sidecar file or within XMP sidecars.

The enourmous XMP size it generates right now, that you and The Lightroom Queen reported, are not a good example, of course. I mean, I also work with 24 MP RAWs. A 27 MB RAW became a 55 MB DNG previously. Instead now we have a 5 MB catalog increase + potentially a 160 MB XMP increase. So I also support your request: Get this more efficient, Adobe, may it be with acr or other files.

A sidenote:

"with a few precautions you can manage" – Probably. But not acceptable. Much more than Photoshop (or ACR), Lightroom is a tool for fast and easy processing of fairly high volumns. I want to avoid every change that brings impaired workflows as they are annoying and costly. But this is more about the batch editing issues of other threads than about this topic here.

Also a software which's core is out there for decades and which's price was premium at all the times and was recently doubled, a user should not need many precautions (preferably almost none at all).

Sorry for sounding so pissed, cause I appreciate that you want to help.

This is just not an issue that needs any help from the community, this is an issue that needs a fix by Adobe. (And I'm perfectly fine if this fix comes in 14.5 or .6. They brought something new, they have to gather feedback and learn and improve. Few things can be perfect from the beginning.)

[DdeGannes]

@robert36972564 , I work with LrC as an alternative to Bridge / ACR /PS and do not depend on XMP sidecar files. My work done in LrC is stored in the Catalog and other data files that reside alongside the Catalog.

If there is a need to do additional work in Photoshop I use the edit in function to send a tiff to PS..

I am away from my computer this week and will see how I make out on my Win laptop  with LrC 14.4 next week. Lots of changes here to get familiar with.

[C.Cella]

@robert36972564 you don't seem to understand the technical challenge here.

It won't be fixed for LrC 14.5 or LrC 15.

You will wait in vain for many years.

SuperRes is for printing and to be done on carefully selected images.

Is not something that makes sense "en masse"

I want to print many of my images but SuperRes is the very last stage of the editing process, not the first.

I can't imagine doing SuperRes beside for carefully selected iamges as the costs for printing big are considerable.

Realistically none of us will ever run out of space due to SuperRes, if we are sensible.

What is way more important is to get better performance in LrC as even now editing SuperRes or high megapixles files is sub optimal when one does more than basic Masking.

.

[robert36972564]

Yes, I super rarely use SuperRes, but I use denoise. And if I use it, chances are, that I have 50-200 images each time.

And you are right, I don't see the technical challenge here.

[JohanElzenga]

Oh no! 😮😣

Please, Adobe, store all of this data only with the RAW files!

My Lightroom Catalog already is about 1 TB in size, mostly due to (mostly standard sized, not 1:1) previews but also several GB for the data/db files of the catalog. The LR Catalog is stored on a high-end 2 TB SSD (just upgraded from 1 TB a few weeks ago), to make culling etc. fast enough.

By @robert36972564

That is never going to happen. If you use Lightroom Classic, then you'll have to accept that Lightroom Classic is a database application, so all the edits are stored in the database and its supporting files. Storing the enhance data only with the images would make the database not contain all the edits.

As you said, your issue of having a 1TB catalog folder is not caused by enhance data and will not be exaggerated by enhance data (unless you would enhance every single image). It is caused by your previews (and smart previews if you have these too). The Catalog Settings contain more options to limit the size of previews. Previously you could only set how soon 1:1 previews would be discarded, but now you can specify a maximum size for the previews cache. Lightroom will delete standard sized previews of the images you did not view recently, starting with the oldest.

And if you have smart previews, then ask yourself if you really need them. Many people seem to think these are some kind of 'previews on steriods' or 'intelligent previews', that somehow improve what they see on screen. They're not. The name is misleading, because they have nothing to do with previews. They are proxies for your raw images, so you can edit even when the external disk is offline. If you never do that, then you don't need smart previews.

[robert36972564]

Yep. That preview cache limit was a nice change.

Hm. 🤔 I mean, maybe they can introduce such a setting for the AI storage. Would also be a perfectly fine solution.

I don't think, they need to store 5 MB for the edits. After all it's only 2 user parameters (on/off + intensity). And maybe a few hidden (ai version or something...).

[JohanElzenga]

It's not just two parameter settings. Because you want to see the results right away, and not have to wait for Lightroom to rerender everything each time you access the image in the Develop module, Lightroom needs to store these results somewhere. You could say that Enhance more or less still works the same way as when an DNG was created, except now the result is not stored as a separate DNG but inside the lrcat-data, so it remains accessible and can be changed at any time.

[daehxxiD]

But it does seem to be quite a bit more efficient than when it still stored a separate DNG file. Example: A ~30MB DNG from my A7IV denoised would be around 80MB. Now, with the lr-data solution, it is only a very small increase (as observed by Lightroom Queen).

The thing is, the 5MB is not telling the whole story. I did the following test: Take a folder from my LR-Catalog and convert it into a standalone catalog. I then opened that new catalog and created some AI denoised images from a subset of the images in the catalog. I noticed around 150 MB were created in lr-data. I then proceeded to create denoise for all images in the catalog: lr-data remained at 150MB... 🤯

Finally, I am synching my catalogs between Laptop and Desktop. I skip the synching of the lr preview-Folder on purpose, because that contains many small files which makes synching slow. Now, if I open the Catalog on the Laptop, it will ask me to "update the AI settings" on the images that I had previously AI denoised on my Desktop PC. I assumed that would mean that now my laptop would have to redo the whole AI-Denoising, but it was quite quick... So what it really did was just "recreate the previews from the denoise data stored in lr-data".

So a summary of what I've found out so far:

• lr-data seems to store ai settings and enhanced info (e.g. denoise)
  • The size increase of lr-data is kind of hard to track; sometimes it increases, sometimes it doesn't? --> Would be greate if Adobe could clarify
• lr preview-folder seems to store the previews with applied AI denoise
  • If you move the catalog with lr-data but without lr preview, LR will ask you to "update" the AI settings and this runs much faster than if you actually let AI Denoise run on that computer, since the "Denoise"-info seems to be lr-data

Did another small test, this time with  3 11~15MB DNG files from my GX80:

No image denoised
aiDenoiseTest.lrcat-data 0,03

1 image denoised
aiDenoiseTest.lrcat-data 1,75

2 images denoised
aiDenoiseTest.lrcat-data 4,56

3 images denoised
aiDenoiseTest.lrcat-data 6,09

Notice how the size increase is not always the same. The first image denoise was around 1,72 MB; the second 2,81 MB, the third only 1,53 MB. It all seems to be stored in the 00008.log (or so) file in lrcat-data.

Really curious how this actually works! Hope Adobe will chime in.

[C.Cella]

Catalog with a single GFX 100 file

101,8 Megapixles

File Size : 94MB
XMP : 6KB
lrcat-data: 30KB

I did SuperRes which makes it into a 407,03 Megapixel monster.
I saved into XMP

lrcat-data : 193MB
XMP: 247MB

So the full SuperRes is saved in the lrcat-data and alas in the XMP is even bigger (the inefficiency of the XMP format I spoke about)

I then have undone the Super Res, save the XMP
Opened the Image in ACR and I did SuperRes there, then saved.

.acr : 198MB

The XMP is 50MB bigger compared to an .acr file, that's a non trivial 25% increase.

XMP should never have been used to store this data (not even Masking IMO) since ONLY Adobe Products can make sense of this data, whereas Metadata such as keywords, title, caption and so on is universals.

So I suggest to not save SuperRes into XMP unless you are in need.

Maybe other will join my call and ask LrC to adopt the .acr format...a format which anyway LrC can read already.

[C.Cella]

@daehxxiD 

The blob and the acr. are nearly identical if you compare them.
Substantially is the same data

ACR has no database so saves AI images, bitmaps and so on into the .acr sidecar.
LrC saves AI images, bitmaps and so on into the lrcat-data (blob) AND inefficiently in the XMP, essentially bloating them.

(Well actually is still ACR that does the saving for LrC but the choice of format is LrC)

[daehxxiD]

@C.Cella Interesting! I agree with you then, that the "AI" or "Camera RAW" specific presets should probably be stored in separate ".acr" side-car files. I would prefer that, too. That would mean that my RAWs would be stored and backed up alongside the AI-Denoise/Upsampling information and the Catalogue-Folder would remain relatively light (Currently my Catalogue folder is around 5-6 GB; with most space used by Previews and the Catalogue itself being around 1.2GB).

For now I have not been using XMP; but essentially that is an XML-Format, right? I assume the AI-Relevant info will simply be stored in some text-format (BASE64?) inside the textfile. I wonder if a Filesystem with compression would significantly reduce the size of XMP to make it similar to ACR.

[C.Cella]

Key point is  "XMP requires all data be encoded as text"

So ti will not be as light as purely binary data like .blob or .acr
The entire purpose of XM originally was to store/share simple metadata (keywords, caption, etc...) across software and for archive...but then LrC puts edits into it, which is NOT a good idea.

I had one file with too many snapshots in XMP and the sidecar was a big 80Mb while the raw was 30Mb RAW

SuperRes is enormous is about 2 times the RAW (is after all a 2x pixels jump) and now it simply makes immensely inefficient to store metadata in the XMP

So for instance when you write a single new keyword, or add even a single comma or an empty space in your Caption he entire XMP is overwritten.
No big deal if the XMP is 6KB

It is a big deal if the XMP has SuperRes and is 100 of MB in size.

Saving keyword in XMP is a 16 seconds process for the GFX 100 file when it has SuperRes.

16 seconds to save one keyword!!!

It is very obvious to me that the decision to store edits into XMP was taken before this massive data was even conceived.

XMP is and Adobe creation and LrC keeps using it even if ACR has already abandoned it and opted for the better format.
 
Morale : don't save SuperRes in XMP 

P.s.

My catalog is much bigger than yours, 33Gb
80-90% of it is History

I need to cleanup 😅

[ouiouiphoto]

Deal all

Test with R7 raws 

In the XMP we are supposed to find metadata including dev metadata. If you do a simple dev your XMP is around 10Ko. If you add masks, you have to save in the XMP the mask drawing. This can take place.  But with a lot of masks,  you are still under 1Mo. But if you use Denoise by AI your xmp goes to 5Mo or more. Why to save the denoise result in the XMP ? Why not to save instead that denoise AI why used with the slider value like it is done for exposition. In the XMP you don't save the exposition result but just that is was used and the value of the slider. Why Denoise is not the same ? If anyone have an idea. Just to know why. Because personally i don't use xmp at all

Kind regards

[Jao vdL]

Normally the denoise result is put in the catalog only. It only gets put as a copy in the xmp when you have automatic xmp writing turned on. This data has to reside somewhere. In previous versions of Lightroom, a separate dng file would get created with the denoise data. In the new version, the denoise data that allows you to charge the amount of denoising after the fact is stored in the metadata in the catalog. Denoising this way unavoidably adds some megabytes that have to be somewhere.

[ouiouiphoto]

Hello @Jao vdL . When you add exposition or contrast, you don't have the exposition or contrast result in the XMP. You only have the slider value. So I wonder why this is different with Denoise. You could imagine just to have if it is applied and the slider value as for exposition And when you import in a new catalog the file with the XMP, as for the exposition, Lightroom will redo the denoise. 

[DdeGannes]

@ouiouiphoto , when you are using LrC the application is reading and writing to the Catalog file an other data files that reside in the same folder as the Catalog. So it's possible to use all the functions of LrC without the XMP sidecar files.

There is an option to automatically write XMP or you can do so manually, the XMPs are utilized by Adobe Camera Raw application or other third party applications.

Writing to XMP will slow the performance of LrC and utilize disk space to store data,

[ouiouiphoto]

Thanks @DdeGannes but i don'ty use XMP as written in my post. I know what is xmp. I just wonder why to put the denoise result inside and not the slider value as for all other parameters

[Jao vdL]

it would make the slider incredibly slow to respond if they didn't store the denoise data as every time it would need to recreate it. The data it stores is a reduced representation of the raw data as seen by the ai. The cool thing is that doing it this way allows them to on the fly dial in different denoise levels. Secondly, when you turn on xmp backups, what Lightroom Classic does is store the exact same data in the xmp sidecar backup as it stores in the catalog files. So this also includes this fast denoise data. This is no different from all the AI masks, AI remove data, etc etc. that all gets stored in the xmp sidecar if you enable the auto xmp writing even if Lightroom or camera raw could easily regenerate those masks. This can make the xmp sidecars really big indeed.

[ouiouiphoto]

@Jao vdL I understand it for AI mask or mask in general to save the shape but less for Denoise result.  Anyway, for sure, if you want to put in the xmp all to avoid AI recalculation you have to put it inside.