Calibration brightness level

[digitaldog]

No, not at all cofused. I've understood this since ACR came out in 2003 and Bruce's book came out.

I'm sure you think that is important but what really is, is that the CMS architecture in Adobe products under discussion predates that by 7 years. And some of the people trying to get you to fully understand this architecture were working directly with Adobe on this, before the product shipped and were asked by Adobe to explain it in a white paper referenced here.
Take it from someone under those conditions: you're kind of confused. 

Again, I'm not "arguing". You are arguing and insulting.

I apologize if correcting your misunderstandings on basic color management is insulting.

And assuming a lot about what others know or don't know.

I'm not assuming; I'm referencing your own writings that are confused, asking you to explain and mostly, you cannot.

Be professional...

Your profession is what sir? With a total lack of transparency, it is impossible to know but you can tell us.
Mine is totally transparent.

[digitaldog]

My goal, for images destined to be only viewed on the web, is to have the utmost consistency. That's all. And all I can control in this consistency is the colorspace of the image I'm exporting.

Example of consistency with color management and how, as long as this is used fully and correctly, the posting on the web in terms of the color space DOES NOT MATTER.
Image came from Tango drum scanner into Lab (Bill Atkinsion's work).
One image converted from Lab to ProPhoto RGB.
One image converted from Lab to sRGB.
Both previewing using color management of course.
Screen capture is color managed and uploaded.
The two match exactly.
What color space to post on the web when the process from start to finish is color manage? Doesn't matter!
What matters alone is that the image data before or after conversion is color managed.
What matters alone with that is that data is previewed using color management.
Hopefully this example proves that and that a picture is worth a thousand words. And for some  here, pictures were worth more than $1000!

So all I can do to make sure my images are seen the same for most everyone, is to export as sRGB

No! And even YOU agreed on your first post the correct fact: you cannot control what other's see of your images.

You can't control what others see, but more than 120nits -> darker images for most folks.

[digitaldog]

The two match exactly.

And to show this exact match in a color managed web browser, using LuLa's actual output to a color managed display:

[Alan Klein]

I posted just before this. What do you mean it doesn't matter? Are you saying all display devices out there can corretly display 100% Adobe RGB or larger colorspaces? That's news to me

OK, maybe "assume" was the wrong word. But from all the testing I've done over the years, untagged images that are sRGB display the most similarly in apps that are not color managed. Untagged Adobe RGB or others look way off. So again, it's about being practical and pragmatic too.

As I mentioned earlier, I have my monitor set for the highest CD about 212cd and use that to edit and dump some of them into Flickr.  Are my pictures too dark, too light or OK?

These are 4x5 chromes.  https://www.flickr.com/photos/alanklein2000/albums/72157715763486212
These are digital https://www.flickr.com/photos/alanklein2000/albums/72157717671668191

[digitaldog]

As I mentioned earlier, I have my monitor set for the highest CD about 212cd and use that to edit and dump some of them into Flickr.  Are my pictures too dark, too light or OK?

The one example posted here, that you ignored is too dark. WAY too dark.
But that may also be due in large part to someone having difficulty properly exposing his images. Or editing them. I accept both could be possible based on the source of the image(s).

Are my pictures too dark, too light or OK?

You have this odd habit of asking questions of others, when your long posting history and agenda show/prove, you have no desire or ability to accept any answer. No need to ask.

[digitaldog]

But from all the testing I've done over the years, untagged images that are sRGB display the most similarly in apps that are not color managed. Untagged Adobe RGB or others look way off. So again, it's about being practical and pragmatic too.

1. Don't ever produce untagged images: RGB mystery meat.
2. sRGB untagged and assumed to be sRGB (bad) will preview the least awful on an sRGB gamut display. That in no way means it is previewing correctly or will match as it should WITH color management!
3. Adobe RGB (1998) untagged (bad) and assumed to be sRGB will look poor on an sRGB gamut display; the assumption is wrong.
4. sRGB untagged (bad) on a wide gamut display will look poor/ way off.! And there are millions of such displays.
Don't assume. Don't produce untagged data. Don't expect untagged data to preview as it should.

Untagged Adobe RGB or others look way off.

Sometimes yes, sometimes no. Untagged sRGB or others look way off, sometimes. Tagged data never has any of these issues. Hence, you can upload any tagged RGB to the web: IT DOES NOT MATTER and the illustrations have been provided.

So again, it's about being practical and pragmatic too.

No, it is about handling the data correctly and understanding why!
Note: I've outlined gamut because that is simply ONE attribute at play here and it goes full circle back to the actual topic before the hijacker arrived: Calibration brightness level.
sRGB and Adobe RGB (1998) as two examples have differing color gamuts. There is more to their attributes than just the color gamut; on a wide gamut display or an 'sRGB gamut' display.
A display may have an sRGB color gamut, fine. You can hook up two identical new displays with an sRGB color gamut and calibrate one to 80cd/m2 and a CCT white point of 5500K (the numbers define a large range of possible colors), and the other to  100cd/m2 and a CCT white point of 6500K: they will NOT match. Yet they have the same color gamut.
Editing in sRGB, which IS a fixed attribute (if you use the real sRGB), is divorced from the two displays above BY DESIGN. 
Editing in an sRGB color space doesn't alone provide anything useful per se, and it pretty much guarantees you've clipped colors you can capture and output.
sRGB should be used as an OUTPUT color space and that's it. For the web yes; for those that unfortunately do not use color managed browsers ONLY on sRGB-like displays (which are fading like dodo birds). Otherwise it makes no difference what you upload, the web is color space agnostic and all the images will preview, again as clearly illustrated IF you use color management.
Mr Ghost, a video for you I would hope, unlike the hijacker who always ignore facts, you may watch:

sRGB urban legend & myths Part 2

In this 17 minute video, I'll discuss some more sRGB misinformation and cover:
When to use sRGB and what to expect on the web and mobile devices
How sRGB doesn't insure a visual match without color management, how to check
The downsides of an all sRGB workflow
sRGB's color gamut vs. "professional" output devices
The future of sRGB and wide gamut display technology
Photo print labs that demand sRGB for output

High resolution: http://digitaldog.net/files/sRGBMythsPart2.mp4
Low resolution on YouTube: https://www.youtube.com/watch?v=WyvVUL1gWVs

[Alan Klein]

Yeah, so what ICC profile should I export my photos with for web if not sRGB? sRGB guarantees all monitors can handle it. Should I export with Adobe 98? Nope. Some Display P3 variant because Apple devices use that now? Nope! So yeah, sRGB is still the best option.

100nits is good enough to edit in - I know the spec says 80 with 64lux ennvironment, but are people measuring their ambient light? Not really. 100 (like for REC 709) is good for a dim envorinment editing so you can see details. More than that is up to you, but this is what I've found works when later viewiing my images on a variety of devices with britghness cranked way up, etc.

How does histogram enter the discussion?  For example, let's say you edit a photo and the histogram is covered from 0-255, with no clipped data.  Why does the CD setting on the monitor matter?  It may look darker at 80cd and brighter at 200 cd, but why would that matter? 

[digitaldog]

How does histogram enter the discussion?

It doesn't. And you asked this before and you were provided the same answer.
https://forum.luminous-landscape.com/index.php?topic=139472.msg1228446#msg1228446
But it seems you cannot find, or comprehend answers to your questions.
And why do you ask this of someone who appears equally iffy understanding this technical and somewhat complex topic? Answer: Modus operandi

Why does the CD setting on the monitor matter?

And you asked this before and you were provided the same answer.
https://forum.luminous-landscape.com/index.php?topic=139472.msg1228446#msg1228446
But it seems you cannot find, or comprehend answers to your questions.

It may look darker at 80cd and brighter at 200 cd, but why would that matter?

And you asked this before and you were provided the same answer.
https://forum.luminous-landscape.com/index.php?topic=139472.msg1228446#msg1228446
But it seems you cannot find, or comprehend answers to your questions.

You have this odd habit of asking questions of others, when your long posting history and agenda show/prove, you have no desire or ability to accept any answer. No need to ask.

Must you continue to hijack this thread? Isn't the Bear Pit forum sufficient a place for you to conduct this kind of Modus operandi?
Happy Thanksgiving. 🦃

[digitaldog]

For example, let's say you edit a photo and the histogram is covered from 0-255, with no clipped data. 

You believe that pixels that are zero/255 are not clipped?
With your ultra high cd/m2, did you intend to indeed, clip your sky or it was just a misunderstanding, a lack of understating RGB (or Lab) sampling points in your editor, or some other factor that provided the example below?
I don't expect an answer but your audience may

[ghostwind]

Mr Ghost, a video for you I would hope, unlike the hijacker who always ignore facts, you may watch:

sRGB urban legend & myths Part 2

In this 17 minute video, I'll discuss some more sRGB misinformation and cover:
When to use sRGB and what to expect on the web and mobile devices
How sRGB doesn't insure a visual match without color management, how to check
The downsides of an all sRGB workflow
sRGB's color gamut vs. "professional" output devices
The future of sRGB and wide gamut display technology
Photo print labs that demand sRGB for output

High resolution: http://digitaldog.net/files/sRGBMythsPart2.mp4
Low resolution on YouTube: https://www.youtube.com/watch?v=WyvVUL1gWVs

I did watch your video and also read the tech paper on Adobe working spaces. I don't think I disagree with anything in either, and this is how I've understood things for a long time as well. What I do disagree with is how important and absolute you make some of the points sound for everyone - "e.g. some of the thing you talk about in 'The downsides of an all sRGB workflow'". For many folks it may be quite fine and suitable for example, and they are not "wrong" necessarily for choosing said workflow (or a part of it), or fools that can't and don't understand color management. Color management and all this stuff is hardly rocket science really. Anyway... So nothing new except for one thing I'll mention next, so I'm not sure what exacltly you so adamantly object to in my process or in what I've said. The only new and interesting thing (to me) I found, was in your video where you say/show how sRGB tagged images will look more saturated on WCG displays in apps that are not color managed compared to Adobe RGB tagged images, so it's better to use Adobe RGB in this case. Perhaps, I haven't tested this. I will, as I'm curious, but I believe you. Neither is correct, so one can debate which wrong is "more right" or "more pleasing", but no point as it's all subjective.

And yes, I understand (as does any professional photographer) that we can't control how users see our images (or videos in my case as well as images) when they go out on the web to be seen on various devices, most of which are not calibrated to D65, have excessive brightness, etc. It's a frustration all professionals deal with. But where I disagree, and I know people fall into two camps here, is that one cannot try to do something about it. One camp says you can only make sure you stick with the standards and then it's out of your control. The other, while understanding this, tests things on different devices and makes small changes/compromises to the ideal image/video in order for it to look more consistent. And I fall in the latter camp. Is it all in vain? No, because I do test things and can see the results. So there is no right or wrong camp to be in - it's a choice.

Yeah, sRGB @ 80nits in a surround of 64lux is spec. D65 and all. All I said for the OP was that to be practical, 80-120nits is a good range, and said why from my experience. No we don't know how people will exactly view things, but I can pretty much bet most view on much-too-bright displays instead of proper or too dim, so yeah, there's a reasonable range to work in.

[digitaldog]

What I do disagree with is how important and absolute you make some of the points sound for everyone - "e.g. some of the thing you talk about in 'The downsides of an all sRGB workflow'".

My position in the video hasn't changed since the Adobe White Paper I wrote and referenced that included a section starting with:

There are no perfect RGB working spaces
In a perfect world, there would be only one RGB working space that was ideal for all uses. An ideal RGB working space would be one that could fully contain all the colors from your capture device or the gamut of the scene, and the gamut of all your output devices.

The section goes on to explain this further but again, my position has not changed in decades, but some RGB Working Space are far more limited than others!

sRGB is about the least useful RGB Working Space for the facts provided in both the White Paper and the video and again, sRGB is only useful as an output color space for a very specific output as also outlined. There is no more or less 'precision' in sRGB when editing high bit, in fact its gamut efficiency is pretty awful if you examine this and accept it:
http://brucelindbloom.com/WorkingSpaceInfo.html
There are no, again repeat no capture devices that produce sRGB natively. If you have a scanner or digital camera that feeds you an sRGB image, it got converted to sRGB from something else, and something with a larger "color gamut" (range of colors) than sRGB (keep in mind that cameras and scanners do not have a color gamut).

An sRGB workflow that starts off providing the user sRGB for editing has in many cases, clipped colors that were captured and can be output. EVEN to the web, for the tens of millions of displays who's color gamut exceed sRGB.

If all you produce is images with a low color gamut** or B&W work, fine: sRGB's color gamut limitation isn't an issue. From raw workflows, there isn't a color space worse in terms of preserving colors you have and may wish to use.

** https://www.dpreview.com/forums/post/59559609

While it is true that the wider the gamut of a color space, and thus the wider granularity in a color space, (moot in high-bit editing)the harder it is to handle subtle colors. This is why wide gamut displays that can't revert to sRGB  are not ideal for all work (ideally you need two units). There are way, way more colors that can be defined in something like ProPhoto RGB than you could possibly output, true. But we have to live with a disconnect between the simple shapes of RGB working space and the vastly more complex shapes of output color spaces to the point we're trying to fit round pegs in square holes. To do this, you need a much larger square hole. 

Simple matrix profiles of RGB working spaces when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. The opposite is seen with print (output) color spaces. Printers produce color by adding ink or some colorant, while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB again due to the simple size and to fit the round peg in the bigger square hole. RGB working spaces have shapes which are simple and predictable and differ greatly from output color spaces. Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a color space or smaller gamut, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. So the advantage of ProPhoto isn't only about retaining all those out-of-gamut colors it's also about maintaining the dissimilarities between them, so that you can map them into a printable color space as gradations rather than ending up as blobs. 


Here is a link to a TIFF that I built to show the effect of the 'blobs' and lack of definition of dark but saturated colors using sRGB (Red dots) versus the same image in ProPhoto RGB (Green dots). The image was synthetic, a Granger Rainbow which contains a huge number of possible colors. You can see that the gamut of ProPhoto is larger as expected. But notice the clumping of the colored red vs. green dots in darker tones which are lower down in the plot. Both RGB working space were converted to a final output printer color space (Epson 3880 Luster). 

http://www.digitaldog.net/files/sRGBvsPro3DPlot_Granger.tif

[ghostwind]

Again, I understand what you're saying and writing about. I don't disagree with it. But for me, it's about simplicity and WYSIWYG in my workflow.

My master files are the RAW files and their associated sidecar .xmp files that hold my edits. I do 95% of my editing in ACR and export as needed. I know that ACR works in ProPhoto RGB and that if I set it to sRGB (or even Adobe RGB) colors could get clipped. I know my camera can caputre more. But it doesn't matter, because that's why I shoot RAW and keep those as my master files - for any future use in larger spaces and output.

If my files are going to be exported as sRGB, yeah, I prefer any clipping to happen in ACR on intial render, before I start editing, because then I know as I'm editing that I'm seeing exactly how the end output sRGB file will look. There will be no hidden colors that could appear or change later on conversion to sRGB in PS after I'm done editing. So it makes editing simple and accurate, as WYSIWYG. Same would be true if I used Adobe RGB from beginning to end, as my monitor can display almost 100% of Adobe RGB when calibrated to its native gamut. The reason I don't yet use Adobe RGB (for web use) yet, is because from testing on various displays out there, sRGB seems to still be the most compatible with most - just about any display can handle sRGB's full gamut. The landscape is changing, I know, but Apple is doing their thing with Display P3, and most WCG displays aren't even close to 100% Adobe RGB.

If I need to export to Adobe RGB (for printing), then I change the setting in ACR to that space after looking at the file to see if there is clipping, where in the image, and how much/how important is it to the image/me (many times it's not significant to me, so I don't change), and I make any small edits/adjustments as needed. So for me, I find it easier to work this way, than to work of say some master TIFF in ProPhoto RGB where I export to sRGB for web, Adobe RGB for print, etc., because again, I prefer any clipping to happen up front, before editing, not on export.

[digitaldog]

My master files are the RAW files and their associated sidecar .xmp files that hold my edits. I do 95% of my editing in ACR and export as needed. I know that ACR works in ProPhoto RGB and that if I set it to sRGB (or even Adobe RGB) colors could get clipped. I know my camera can caputre more. But it doesn't matter, because that's why I shoot RAW and keep those as my master files - for any future use in larger spaces and output.

If my files are going to be exported as sRGB, yeah, I prefer any clipping to happen in ACR on intial render, before I start editing, because then I know as I'm editing that I'm seeing exactly how the end output sRGB file will look. There will be no hidden colors that could appear or change later on conversion to sRGB in PS after I'm done editing. So it makes editing simple and accurate, as WYSIWYG. Same would be true if I used Adobe RGB from beginning to end, as my monitor can display almost 100% of Adobe RGB when calibrated to its native gamut. The reason I don't yet use Adobe RGB (for web use) yet, is because from testing on various displays out there, sRGB seems to still be the most compatible with most - just about any display can handle sRGB's full gamut. The landscape is changing, I know, but Apple is doing their thing with Display P3, and most WCG displays aren't even close to 100% Adobe RGB.

If I need to export to Adobe RGB (for printing), then I change the setting in ACR to that space after looking at the file to see if there is clipping, where in the image, and how much/how important is it to the image/me (many times it's not significant to me, so I don't change), and I make any small edits/adjustments as needed. So for me, I find it easier to work this way, than to work of say some master TIFF in ProPhoto RGB where I export to sRGB for web, Adobe RGB for print, etc., because again, I prefer any clipping to happen up front, before editing, not on export.

Sounds like an interesting workflow for someone who either does no post rendering edits in say Photoshop, or one who likes doing this over and over again for each rendering who's only (?) difference is the color space used.
Raising the question, do you render from raw at web resolution too, or render once to sRGB, at native camera resolution and then, use Photoshop just to resample to size for the web?
Old digital desktop scanning workflow in the early days when prepress would drum scan to output size and specific targeted CMYK output color space was the old norm: “scan once, use many”. It was a game changer. Scan at full resolution in scanners profiled color space, once. Then ALL Phototshop work. That's the master "file". 🤔

Lastly; you really want to see more outside sRGB gamut display, you want WYSIWYG and a wider color palette? Consider a wide gamut display and join the move towards sRGB going the path of the dodo bird.
Wide gamut LCDs, my first review way back in 2006:
http://digitaldog.net/files/NEC.pdf

[Alan Klein]

Again, I understand what you're saying and writing about. I don't disagree with it. But for me, it's about simplicity and WYSIWYG in my workflow.

My master files are the RAW files and their associated sidecar .xmp files that hold my edits. I do 95% of my editing in ACR and export as needed. I know that ACR works in ProPhoto RGB and that if I set it to sRGB (or even Adobe RGB) colors could get clipped. I know my camera can caputre more. But it doesn't matter, because that's why I shoot RAW and keep those as my master files - for any future use in larger spaces and output.

If my files are going to be exported as sRGB, yeah, I prefer any clipping to happen in ACR on intial render, before I start editing, because then I know as I'm editing that I'm seeing exactly how the end output sRGB file will look. There will be no hidden colors that could appear or change later on conversion to sRGB in PS after I'm done editing. So it makes editing simple and accurate, as WYSIWYG. Same would be true if I used Adobe RGB from beginning to end, as my monitor can display almost 100% of Adobe RGB when calibrated to its native gamut. The reason I don't yet use Adobe RGB (for web use) yet, is because from testing on various displays out there, sRGB seems to still be the most compatible with most - just about any display can handle sRGB's full gamut. The landscape is changing, I know, but Apple is doing their thing with Display P3, and most WCG displays aren't even close to 100% Adobe RGB.

If I need to export to Adobe RGB (for printing), then I change the setting in ACR to that space after looking at the file to see if there is clipping, where in the image, and how much/how important is it to the image/me (many times it's not significant to me, so I don't change), and I make any small edits/adjustments as needed. So for me, I find it easier to work this way, than to work of say some master TIFF in ProPhoto RGB where I export to sRGB for web, Adobe RGB for print, etc., because again, I prefer any clipping to happen up front, before editing, not on export.

That was my theory as a layman.  I'm only editing for the web which is sRGB. Also, most people viewing don't have calibrated monitors anyway. So why should I get all excited if I miss certain colors of let's say Adobe palette? I can't imagine one person in a million could notice without having a second Adobe palette image in that space next to the sRGB one to compare. 

One thing I do though when scanning film, is I first remove all dust spots left from the scan before doing any other edits.  That way, if I decide to change the entire editing in the future because of changes to color space or whatever, I won't have to repeat cloning out the spots again, a time-consuming process.

Also, If I decide to print, later on, I'll deal with different color spaces then and settings for cd brightness level.  This raises my question again.  What relationship is there between the cd setting and histogram?  In other words, if you have the cd setting low, let's say at 80cd so you don't get too dark prints, won't the histogram clip as you push the brightness slider higher to get the "right" brightness? 

[digitaldog]

That was my theory as a layman.  I'm only editing for the web which is sRGB.

A layman who doesn't know what he's talking about and can not learn: THE WEB IS NOT sRGB!.
That is nonsensical and wrong.

The rest of you comments are almost (always) equally as
nonsensical.

[Alan Klein]

A layman who doesn't know what he's talking about and can not learn: THE WEB IS NOT sRGB!.
That is nonessential and wrong.

OK I get that.  But it's also not Adobe or ProPhoto, is it?

The final file I upload is converted to sRGB before uploading to the web.  So that's why I edit in sRGB.  To keep it simple and not chance color changes I don't like when switching from another palette.

[digitaldog]

OK I get that.  But it's also not Adobe or ProPhoto, is it?

Why do you ask questions that have been answered that you didn't read in the first place?

[Alan Klein]

Why do you ask questions that have been answered that you didn't read in the first place?

Thank you for your response.

[digitaldog]

Thank you for your response.

Your posting MO proves you will never grasp this :
"Learning is not attained by chance. It must be sought for with ardor and attended to with diligence. "-Abigail Adams

[ghostwind]

Sounds like an interesting workflow for someone who either does no post rendering edits in say Photoshop, or one who likes doing this over and over again for each rendering who's only (?) difference is the color space used.
Raising the question, do you render from raw at web resolution too, or render once to sRGB, at native camera resolution and then, use Photoshop just to resample to size for the web?
Old digital desktop scanning workflow in the early days when prepress would drum scan to output size and specific targeted CMYK output color space was the old norm: “scan once, use many”. It was a game changer. Scan at full resolution in scanners profiled color space, once. Then ALL Phototshop work. That's the master "file". 🤔

Lastly; you really want to see more outside sRGB gamut display, you want WYSIWYG and a wider color palette? Consider a wide gamut display and join the move towards sRGB going the path of the dodo bird.
Wide gamut LCDs, my first review way back in 2006:
http://digitaldog.net/files/NEC.pdf

I do very little in Photoshop, and when I need to do more (retouching for example), it's easy to keep track of things because I don't do it often at all. And photos where I have to do retouching, with skintones, are ok in sRGB anyway - stuff is in-gamut. I used to use PS more, but ACR/LR are so powerful now, I can do it all really in there. I don't resize and sharpen in ACR - I leave that for PS to answer your question. I suppose I can do it in ACR, but I have some actions and plug-ins that I've gotten used to in PS.

I don't do it over and over again, because most of my stuff is for web, so it's sRGB for now. I only use Adobe RGB when I have to print something as I was saying. And I usually know ahead of time if and image is going to web, print, or both, so I'm not doing a lot of extra work at all. If it's web, I use sRGB. For print or print + web, I use Adobe RGB.

I'm not sure why you say it's "interesting". I prefer to see what I'm editing, so unless I can have a monitor that does 100% ProPhoto RGB, then no, I'm not going to be using that space and have PS clip colors I've already worked on in the conversion to a smaller color space for me and surprise me. So it's simple really for me this way. For me this is THE most important point, as outlined in my prior post. I don't know how others work with colors they can't see and then rely on PS to convert and clip after they work hard to adjust colors to taste, etc.

I could use Adobe RGB for web instead, as I said in my prior post, as my NEC PA271Q monitor can do close to 100% of that gamut, but I haven't changed yet for reasons stated. Yes, it is WYSIWYG, and it's what I use when printing.

I think things are moving towards Display P3 to replace sRGB, not Adobe RGB. Apple is doing it, BenQ monitors have it, and some others. More so than Adobe RGB. They are close in gamut, but a bit different where it counts for me - reds/organges. Perhahs the time will come soon to use Display P3 for web in my workflow. I need to create a Display P3 SpectraView II target to get my NEC on board, but I think the NEC's native gamut aligns more closely with Adobe RGB than Display P3. SpectraView doens't have a Display P3 target for comparison's sake.

I do have one question that's never been entirely clear to me: How do ACR/LR use the monitor profile? I know PS will render images using the monitor profile, but is this the exact same case with ACR/LR? Or do they bypass it and work in the space chosen in ACR/LR? Or some sort of mix, as the white point is not changing from calibrated D65.