Adobe Bridge preview bug in ACR edited images

[QuixoteS2]

Hi, I think I've stumbled across a bug in the way that Bridge v10.01.126 previews images edited in ACR. 

First of all, I can confirm Bridge is reading all embeded color profiles correctly.  If a series of identical unedited test images are tagged with sRGB, A98, ProPhoto, or WhackedRGB, etc. they will all look identical. See first attachment.  

Secondly, I have Bridge set up to display HQ previews.  ACR uses A98 as a working space.

I have a wide gamut profiled monitor.    

Issue:  After editing raw files (or even tiffs and jpegs captured in A98 color space) in ACR v14.3, Bridge previews the edited image in sRGB and not whatever profile is embedded in the image.  I only discovered this after editing some images that had colors that were towards the edge of A98, and definitely outside sRBG.  The Bridge preview is muted in the extended colors while ACR (and opening is PS) shows the full color gamut.  Sure enough, if I convert the edited image to sRGB in ACR or PS, it looks like the Bridge preview. 

I'm wondering if it has something to do with how Bridge is reading and previewing the ACR edits from the sidecar files.   I've tried clearing cache after editing, to no avail.      

I've attached a screenshot of an ACR edit with A98 embedded, so if you have a color managed viewer it will show the differences particularly in the out of sRGB gamut reds.   

[QuixoteS2]

N.B. you won't see a difference between the reg flags clicking on the document preview this site uses.  Furthermore, only a wide gamut monitor and a color managed viewer will show the differences.  

[D Fosse · Accepted solution]

Bridge has always, from the beginning, built its previews as sRGB jpegs. So it's not just from ACR.

Back in the day this was probably not considered a big deal, wide gamut displays were relatively few and far between. Today it might be high time to reconsider this policy.

Lightroom previews, for instance, are Adobe RGB.

That said, I've never used Bridge for any kind of critical assessment of color, so it hasn't bothered me much.

[QuixoteS2]

Wow, after all this time I had no idea. So it is actually reading embedded profiles and then converting to sRGB? It's not a bug, it's designed this way???  I'd always stuck with Bridge+ACR due to the latter's superior catalog performance compared to the earlier iterations of LR.  Any idea why the preview difference exists between LR and Bridge.  LR was built from the ground up, but, yeah, surely Adobe could bring that preview code over to Bridge.  You're right, this isn't a huge issue except for a few outliers, but now I know just how far I can and cannot trust the Bridge thumbnails; I've been using exclusively wide gamut displays for over ten years.    

[TheDigitalDog]

---

@QuixoteS2 wrote:

Wow, after all this time I had no idea. So it is actually reading embedded profiles and then converting to sRGB? It's not a bug, it's designed this way??? 

Not a Bridge user, never was. 

That said, I see nothing 'wrong' with how Bridge produces previews and they do not appear to be in sRGB (not that this would be a problem, more in a bit). Here's a preview in Bridge of an image in ProPhoto RGB and the image in Photoshop (and yes, they differ in zoom ratio):

If that preview to the right (smaller) was sRGB, the balls would look less saturated than the image shown larger in Photoshop. They match. 

This is a wide gamut display. The screen captures are tagged with the display profile and then converted to sRGB to post. But they match. 

And even if Bridge did only provide sRGB previews, as long as they are color managed, that's fine. As discussed, the previews outside of Develop in Lightroom Classic are Adobe RGB (1998). But they are correctly converted so they are color managed even if the source isn't Adobe RGB (1998). 

BTW, ACR doesn't use Adobe RGB (1998) as a Working Space. 

Lastly, I can force ACR to open this Gamut Test File TIFF (this is not ACR as a filter). The image opened in ACR is in ProPhoto RGB of course and again, you can see, that it matches the others. 

I do not see a problem here.

[QuixoteS2]

This is a wide gamut display. The screen captures are tagged with the display profile and then converted to sRGB to post. But they match. 

Can you post a screenshot NOT converted to sRGB.  By doing so, you lose the extended gamut of ProPhoto and they will look identical. 

BTW, ACR doesn't use Adobe RGB (1998) as a Working Space. 

In ACR settings you select whatever Color Space you deem necessary:  Settings>Workflow>Color Space>A98, sRGB, P3, ProPhoto, etc. All edits are then subject to that space.   

[TheDigitalDog]

---

@QuixoteS2 wrote:

In ACR settings you select whatever Color Space you deem necessary:  Settings>Workflow>Color Space>A98, sRGB, P3, ProPhoto, etc. All edits are then subject to that space.   

---

Indeed but that is not ACRs Working Space, that's the encoded color space for the rendering. ACR does have a Working Space, the space under which it edits and it has no name (but is a variant of ProPhoto RGB with a linear TRC). This is why I always render from ACR and LR into ProPhoto RGB. Now that rendered color space/ Working Space is a wide gamut Working Space outside of ACR/LR.

[TheDigitalDog]

---

@QuixoteS2 wrote:    

I've attached a screenshot of an ACR edit with A98 embedded, so if you have a color managed viewer it will show the differences particularly in the out of sRGB gamut reds.   

---

NEC wide gamut display, your screen capture from Safari. They appear to match to me:

Seems something is wonky on your end. Try disabling GPU in all products, or creating a new display profile (matrix, not LUT, V2 not V4). Again, nothing I see here from you, or testing on my end indicates any problems. 

[QuixoteS2]

---

@QuixoteS2 wrote:    

I've attached a screenshot of an ACR edit with A98 embedded, so if you have a color managed viewer it will show the differences particularly in the out of sRGB gamut reds.   

---

NEC wide gamut display, your screen capture from Safari. They appear to match to me:

Seems something is wonky on your end. Try disabling GPU in all products, or creating a new display profile (matrix, not LUT, V2 not V4). Again, nothing I see here from you, or testing on my end indicates any problems. 

By @TheDigitalDog

What is your working space when viewing my screenshot? Are you downloading my original image and not using "Save As" (or equivalent in Mac)?

My i1 profile is Matrix, v2.

Saving your screen of my image, I see it has been converted to sRGB and so they will look identical. The images tagged with ProPhoto, A98, they are all being brought down to the lowest common denomenator which is sRGB.  

[D Fosse]

I've just retested and I can confirm that Bridge previews are indeed sRGB. They have not changed this.

This screenshot has Adobe RGB embedded, and you will only see the difference here with a wide gamut monitor. To anyone with a standard gamut monitor all four will look identical:

EDIT: you need to right-click and and open in a new tab. The inline image apparently strips the profile, so it shows as sRGB in all browsers. And then of course we have the current forum bug that prevents this. Sigh, there's always someting...

[TheDigitalDog]

---

@D Fosse wrote:

I've just retested and I can confirm that Bridge previews are indeed sRGB. They have not changed this.

---

You are indeed correct. My bad for NOT using the same zooming ratio and here's a new test. It is a JPEG but from a wide gamut display, tagged with my display profile. It isn't in sRGB as I upload it.

 I zoomed them as close as possible. I can see that yes, the Bridge preview and the sRGB conversion from ProPhoto RGB match. The ProPhoto RGB is more saturated. But the sRGB converted image from ProPhoto RGB previewed in Photoshop and the sRGB preview in Bridge match; I see no bug/issue here. Yes, it would be nice if Bridge treated its previews like Lightroom Classic (out of Develop). But I see no bug or problem, it's Bridge, a browser not an editor. The Bridge preview is color-managed and matches Photoshop (sRGB to sRGB). 

[QuixoteS2]

Yes, that's it! 

For any images that do not contain colors outside sRGB, this is a moot point because Bridge is reading embedded color profiles and then doing a final CONVERT to sRGB. No color information is lost in this conversion becasue none go beyond sRGB.  Even the crazy "Whacked RGB" tagged profile found here: http://www.gballard.net/photoshop/pdi_download/#downloads looks correct in Bridge because that purple hue is actually within sRGB gamut.  Push the saturation and the real mechanics behind bridge start to show.   

If there are colors outside sRGB, those get lost in the conversion.  It's exactly the same as taking a saturated ProPhoto tagged image in Photoshop and going Edit>Convert to Profile>sRGB.   Those colors outside sRGB get brought down to the nearest possible color in sRGB which can be far less saturated.    

Is there a feature suggestion section anywhere in the community or on Adobe's support site?  I would say Adobe is depricating Bridge except they keep coming out with new versions!  As D Fosse said, Bridge isn't "for any kind of critical assessment of color."  Time to Lightroom...

[TheDigitalDog]

---

@QuixoteS2 wrote:

Is there a feature suggestion section anywhere in the community or on Adobe's support site?  I would say Adobe is depricating Bridge except they keep coming out with new versions!  As D Fosse said, Bridge isn't "for any kind of critical assessment of color."  Time to Lightroom...

---

I don't see one specifically for Bridge. You can try it here and hopefully, it goes to the right team:

https://community.adobe.com/t5/lightroom-classic-ideas/how-do-i-write-a-feature-request/idi-p/123863...

[Bob_Hallam]

I have a feature request for the developement of this issue.  Seems a very valid and reasonable ask.  Probably get some pushback due to the speed to display thumbnails but we will see.  

[QuixoteS2]

But would converting to an A98 space rather than sRGB be slower?  I don't know enough about the bits and bytes of each framework, i.e. how/if a larger gamut corresponds to more comput power.  A cursory look at the file size of the .icc profiles (definitions?) for sRGB and A98 are only a couple KB each.   

[TheDigitalDog]

---

@QuixoteS2 wrote:

But would converting to an A98 space rather than sRGB be slower?    

---

Probably not, no proof of concept. Simply not the case or the design of Lightroom as correctly posted. All previews outside Develop are JPEGs in Adobe RGB (1998).

Just try as an example to convert images in Photoshop to sRGB vs. Adobe RGB (1998). Even a lot of them. It is extremely unlikely this is due to speed.

Bridge is a browser only, you don't edit images there, the thumbnails don't really need to match anything wider gamut than sRGB (be nice, not mission critical) to wider gamut originals. They are all subsampled, smaller to view, AFAIK, you don't get the opportunity to view them 1:1 of original size. Bridge is free. It isn't going to get the love or engineering resources of other products that are editing image data. This is akin to expecting everyone's web page/browsers to support wide gamut previews which we don't see here as pointed out. In short, there isn't really anything wrong here and expecting Adobe to re-enginner the preview architecture for a wider gamut but limited audience is unlikely to get much effort. You and others can and should ask. Just don't expect anything for the reasons (and likely more) outlined. 

[QuixoteS2]

That's understandable.  But as things progress (P3 is already becoming more standard and widespread on devices) the software should too. And Adobe keeps rolling out new versions of Bridge.

I use Bridge loupe (1:1) and full screen 100% previews ALL THE TIME.  It's just one less step than opening in ACR or PS for quick review.  But, as you said earlier, this isn't mission critical.  

[D Fosse]

My main problem with Bridge right now isn't preview color space (which doesn't bother me), but thumbnail/preview speed. It feels like Bridge is constantly rebuilding thumbnails and previews, and for a big folder that can take a  l o n g  time (as in go get a coffee and chat with the neighbors).

I don't know if it's just because my archive is rapidly approaching 10 terabytes, so there's no way to keep a reasonable amount of that in the cache. I do keep the cache on a fast NVMe drive (same as primary Photoshop scratch disk).

Whatever the reason, I'm shopping for a faster and more responsive file browser. The problem is that Bridge has so many additional and extremely useful functions, and I'd hate to give those up. I really love Bridge, if it could only hurry up a little... 😉

[TheDigitalDog]

---

@D Fosse wrote:

Whatever the reason, I'm shopping for a faster and more responsive file browser. 

---

How about a fast one for rendered and raw, and a raw Histogram too?

https://www.fastrawviewer.com/?utm_source=program&utm_medium=splash&utm_campaign=FRV

[QuixoteS2]

Interesting!  But we should speak no more of it on an Adobe forum 🤐, lol!

[TheDigitalDog]

---

@QuixoteS2 wrote:

Interesting!  But we should speak no more of it on an Adobe forum 🤐, lol!

---

Since Bridge is free, I doubt (as an ACP) it's an issue. 

[QuixoteS2]

Agreed.  Not the quickest even with a solid state cache location.  One setting I've resorted to using is "High Quality on Demand" under "Options for thumbnail quality and preview generation" icon on the top bar.  This way, Bridge won't rebuild the thumbnails for a folder until I click on an image.  Usually there is only a handfull or more at one time even in a folder of a couple thousand that I'll look at simultaneously.  I also, Do Not check " Generate 100% Previews" as this slows things down considerably.  I don't need Bridge to generate full scale previews of all my images at once, immediately.  It does so only when I click on a thumbnail.

And finally, (you probably know this already) if you have the space on the solid state drive, bump up that cache size slider in Bridge settings.

Thanks for sussing out the nuances of Bridge display!    

[D Fosse]

Oops! Turns out 100% was checked, I was sure it was off. Thanks for making me go in and re-check my preferences...

Let's see if that helps. I've limited the cache to 200GB, I really don't want to give it any more than that.

Fastrawviewer looks interesting, but I need it for PSDs mainly. I do use Lightroom to manage all my raw files, and it works well for that. It sort of works for RGB files too, but for a long list of reasons I need to keep raws and RGBs completely separate. They even have separate physical drives. I'll keep looking.

[TheDigitalDog]

Ouch, PSDs are bad. <g> Dr. Schewe would disapprove. 

August 22, 2007

https://forum.luminous-landscape.com/index.php?topic=18965.msg134830#msg134830

PSD is now a bastardized file format that is NOT a good idea to use. Even the Photoshop engineers will tell you that PSD is no longer the Photoshop "native" file format. It has no advantages and many disadvantages over TIFF.

TIFF is publicly documented, PSD is not. That makes TIFF a preferred file format for the long term conservation of digital files.

TIFF uses ZIP compression for max compression, PSD uses RLE which if you save without the Max compatibility will be a bit smaller, but at the risk of not being able to be used by apps, like Lightroom.

TIFF can save EVERYTHING a PSD can save including layers, paths, channels, transparency, annotations and can go up to 4 GIGS in file size. TIFF can save all the color spaces PSD can. The ONLY thing I can think of that PSD can save that currently TIFF can't save is if you Save out of Camera Raw a cropped PSD, you can uncrop the PSD in Photoshop CS, CS2 or 3. That's one tiny obscure thing that PSD can do that TIFF currently doesn't. How many people even knew that let alone use it?

PSD used to be the preferred file format back before Adobe bastardized it for the Creative Suite. The moment that happened, PSD ceased to be a Photoshop "native" file format. PSB is the new Photoshop "native" file format for images beyond 30,000 pixels. And , at the moment, only Photoshop can open a PSB.

Getting back to the fist point, Adobe can do anything including stopping support for PSD because it's a proprietary  file format. TIFF is public, even if it's owned by Adobe (by virtue of the Aldus purchase). Even if Adobe went belly up tomorrow, TIFF would continue.

And, let me be blunt, anybody who thinks PSD is "better" than TIFF is ignorant of the facts. If Adobe would let them, the Photoshop engineers would tell you to quit using PSD. Lightroom for the first beta did NOT support PSD and Hamburg fought tooth and nail to prevent having to accept PSD. He blinked, but you still can't import a PSD without Max compat enabled-which basically makes it a TIFF with a PSD extension.

Look, I'll make it REAL simple...

TIFF = Good
PSD = Bad

Ok?

[D Fosse]

I'm not worried. If Adobe goes belly up I'll deal with that when it happens 😉 I'm sure my Photoshop copy will work long enough to batch resave into something else.

The other arguments I'm not even sure I buy, they seem more like opinion than reality. Whether it's native or not is irrelevant as long as it does what it needs to do. Compression is moot, I don't compress. And I need PSB too, 4GB isn't always enough.

Maybe PSD isn't better than TIFF, but I can't see why TIFF is better than PSD either.