Luminous Landscape Forum

Raw & Post Processing, Printing => Colour Management => Topic started by: michaelbiondo on February 20, 2015, 02:25:32 pm

Title: Luminence value for web output
Post by: michaelbiondo on February 20, 2015, 02:25:32 pm
Ok, I know that this is mostly an unanswerable question but I gota at least try.
Think of it as the photographic equivalent of a controlled crash landing.
Does anyone have any thoughts about what to set  your luminance target for your display in preparing files for websites?
I am calibrating my monitors with  i1 software & hardware.

This is what I set up for targets...

White point = D65
Luminance = 120

Thanks!

MB
Title: Re: Luminence value for web output
Post by: howardm on February 20, 2015, 02:45:30 pm
Since most people have their monitors turned most of the way up or are using factory defaults, I would probably start
higher than that, 120-140+ and see how that goes.
Title: Re: Luminence value for web output
Post by: michaelbiondo on February 20, 2015, 02:59:37 pm
Thanks, I think that is a good starting point.
Most creatives I work with do have their monitors jammed up all of the way.
MB
Title: Re: Luminence value for web output
Post by: D Fosse on February 20, 2015, 06:06:19 pm
Most creatives I work with do have their monitors jammed up all of the way.

Yes, but that's their problem, not yours. I go for 120. If pressed for a standard, that's what most people would agree on.
Title: Re: Luminence value for web output
Post by: Wayne Fox on February 20, 2015, 08:28:21 pm
Yes, but that's their problem, not yours. I go for 120. If pressed for a standard, that's what most people would agree on.
“Most people” - if they are some how connected to the graphics/photographic industry and are familiar with the challenges of trying to use a computer display as a predictive device for printed output as well as the concept of color management, perhaps.

But that’s a pretty slim number of users out there. If you ask “most people” they would have no clue what you are talking about. And why should the great majority worry about using their displays this way, they have no need to use their systems to “predict” what a print would look like. And there is nothing wrong with using a display at a brighter setting or different white balance. Since that’s how the computer industry delivers the systems, that’s the “standard”, that’s the reality.

Additionally the environment of the computers is dramatically different for most users.  While most doing this type of work have their workstations in room with controlled lighting, the normal display is often in a brightly lit room.

The rationale for not doing anything is there is no standard so how can you do anything. While true, it ignores facts, one of them is 99.999% of the displays out there are much brighter, from 160-220 cd/m2, and often a little cooler.

So one can ignore that fact because there is no standard, or can decide that while there is not a standard, there is one fact, and that is the average conditions are vastly different than the settings we use when trying to use the computer as a device to predict printed output.

There have been discussions on this before.  I use to think there was nothing I should do.  Then I went to a computer store and pulled my gallery up on 10 or 15 different machines.  I started looking at my website when I was at friends homes.  And I realized all my images looked weak and flat.

So to the OP, I have two settings for my NEC, one is for printed output, one is to tweak things for web jpegs.  The web setting is 160 cd/m2, 6500k, sRGB. After experimenting with slight tweaks to my files for converting to web, I have settled on a very slight density increase, and a slight boost to vibrance and saturation. (these are settings within a photoshop action, not LR/ACR adjustments)  Subtle and still look pretty good on my 115 cd/m2 calibrated display.  Went down to the computer store, and things looked a little better. Still not perfect, but that will never happen. And I don’t try to “soft proof” every image, I pretty much just run with those settings.

Title: Re: Luminence value for web output
Post by: D Fosse on February 21, 2015, 06:31:34 am
The rationale for not doing anything is there is no standard so how can you do anything. While true, it ignores facts, one of them is 99.999% of the displays out there are much brighter, from 160-220 cd/m2, and often a little cooler.



Yes, but again, these people see everything this way. That's their environment, and if they're not bothered by that, why should your particular images be different?

I think the whole notion that you should try to compensate for the "average" setup is flawed to begin with. Aim for those who have things properly set up, and ignore the rest. I still think it's their problem.
Title: Re: Luminence value for web output
Post by: Rhossydd on February 21, 2015, 06:48:13 am
I think the whole notion that you should try to compensate for the "average" setup is flawed to begin with. Aim for those who have things properly set up, and ignore the rest. I still think it's their problem.
It becomes your problem if you loose sales/reputation because your images are seen as too dark.
Title: Re: Luminence value for web output
Post by: Simon Garrett on February 21, 2015, 06:51:31 am
There have been discussions on this before.  I use to think there was nothing I should do.  Then I went to a computer store and pulled my gallery up on 10 or 15 different machines.  I started looking at my website when I was at friends homes.  And I realized all my images looked weak and flat.

I don't quite understand this.  I assume your images look OK on your monitor (!)  I also assume that other images on the web look OK on your monitor.  So, if you go to another person's PC (uncalibrated, and high brightness), everything will look higher contrast and punchy - including your images, surely? 



Title: Re: Luminence value for web output
Post by: Simon Garrett on February 21, 2015, 06:59:57 am
Yes, but again, these people see everything this way. That's their environment, and if they're not bothered by that, why should your particular images be different?

I'm with you on this.

It's sometimes said that there's no point using colour management for images destined for the web.  You get the skin tones spot on, but then most people viewing the web have monitors showing false and unpredictable colour, so why bother?

The answer is this, I think: someone with an unmanaged monitor sees skin tones incorrectly, but they are used to how "correct" skin tones look on their monitor.  Most professional content (news sites, galleries etc) show correct colours, so if yours are also correct, then they'll look "right" on an unmanaged monitor - that is, they'll look the way to which the user has grown accustomed on their monitor.  
Title: Re: Luminence value for web output
Post by: LawrenceBraunstein on February 21, 2015, 07:13:00 am
As you can see, there are a lot of different opinions out there. None of them, however, really resolve the problem. I do a lot of printing and therefore prefer to have my main monitor calibrated to a luminance, white point, and contrast setting which best matches the paper/printer combination I use most often. However, I have a second monitor which is calibrated to a higher luminance and contrast setting. This is my ‘web’ monitor. Of course, the down side of all this is that I can’t really use both monitors to compare photographs. This doesn’t bother me so much since the second monitor is used during post-processing primarily to hold the library thumbnails in Lightroom while editing (or printing) photos in the develop (or print) module. Thanks for asking the question, though. I’m curious to read other ‘solutions’ to this unsolvable problem.

With best regards,

Larry
Title: Re: Luminence value for web output
Post by: michaelbiondo on February 21, 2015, 01:42:03 pm
Thanks everyone for their input.
I find myself leaning into the "can't beat em join em camp"
There are just too many clients of mine (and potential clients) using bright settings on their monitors.
I really like the idea of having one luminance setting for printing and one for web viewing.
This may work for prepping files for my website but what about file delivery to clients?
For that it may be a good idea to split the difference, say 180?
Hmm... need to give it more thought
MB



Title: Re: Luminence value for web output
Post by: Wayne Fox on February 21, 2015, 09:57:11 pm
I don't quite understand this.  I assume your images look OK on your monitor (!)  I also assume that other images on the web look OK on your monitor.  So, if you go to another person's PC (uncalibrated, and high brightness), everything will look higher contrast and punchy - including your images, surely?  

Actually my images are a little flat on others monitors.  They look fine on mine ... but then that’s only because I’m trying to make them look like printed paper and I’ve gotten use to a display with a lower brightness setting.  The first thing most have to figure out when when trying to use the display to predict printed output is turn the brightness down, which requires a density change in the image file to look correct.  Turn the display back up and it can look a little washed out.

What f I were selling a high end display that was to be placed in a frame and display the images this way ... would I use the same settings and have the same workflow? Probably not.

  We’re the minority here, we are using the devices in a special way for a unique purpose, and as I said the only thing that is really known is pretty much everyone else has their displays brighter.  

And on my monitor there are many images on the web that don’t look OK, because it’s a high gamut NEC and things just get weird sometime when surfing the web.  i understand why, doesn’t bother me.  But if someone is looking at my image and it looks a little washed out compared to what it would look like when printed, they don’t understand that. They just think that’s the way it’s supposed to look.

I don’t worry so much about color ... viewers adapt to color quickly, and often we only think color is “off” because we are comparing it - if they’re not the same then one of them must be wrong, right?.  so I don’t try to adjust things a little ‘warmer” because most displays are a little cooler than mine.
Title: Re: Luminence value for web output
Post by: Simon Garrett on February 22, 2015, 05:31:50 am
Actually my images are a little flat on others monitors.  They look fine on mine ... but then that’s only because I’m trying to make them look like printed paper and I’ve gotten use to a display with a lower brightness setting.  The first thing most have to figure out when when trying to use the display to predict printed output is turn the brightness down, which results in adding density to the image file. Turn the display back up and it can look a little washed out.

Well, several things could be happening here.  On a given monitor, if you calibrate to a higher brightness then the perceived contrast may well go up.  This is simply because peak white gets brighter but black stays the same.  However, it depends on the contrast setting on the monitor (effectively altering the gamma).  In my experience, most people turn the contrast up to get a more punchy image. 

At the same time, if you increase the brightness of an image, the perceived saturation will go down.  This could be one reason why images might look washed out. 

I did some tests: I created two calibrations for my monitor, one sRGB 100 cd/m2 and one sRGB 200 cd/m2.  On my monitor the greater contrast of the higher brightness outweighed the reduced saturation effect, and images did not look washed out at the higher brightness level, and I could not see any reduced saturation.  Images just looked more punchy - the opposite of what you observe. 

I can only guess that, when we start from images adjusted on colour-manged monitors with moderate brightness (around 100-120 cd/m2) then the appearance on general uncalibrated monitors is going to be unpredictable.  In the sample you tried you tend to see washed out colour, but in those I've tried the result has been the opposite. 

Title: Re: Luminence value for web output
Post by: Peter_DL on February 22, 2015, 02:20:59 pm
On a given monitor, if you calibrate to a higher brightness then the perceived contrast may well go up.

At the same time, if you increase the brightness of an image, the perceived saturation will go down.

I did some tests: I created two calibrations for my monitor, one sRGB 100 cd/m2 and one sRGB 200 cd/m2.  On my monitor the greater contrast of the higher brightness outweighed the reduced saturation effect, and images did not look washed out at the higher brightness level, and I could not see any reduced saturation.  Images just looked more punchy - ...

Agreed regarding the first statement,
from what I can tell:

the higher the monitor luminance, i.e. the closer it is to the scene luminance,
the less of tonal lifting is typically needed, e.g. referring to the common S-curve.

Quote: >>There are some new (and very expensive) display technologies on the market that have a real dynamic range of 10,000:1 and can produce extremely bright whites. With one of these, we could send a properly exposed scene-referred image directly to the display. The image would look just like we were there, …<< (Rendering the print , Karl Lang, see below link).

Images edited at high monitor luminance tend to look dark and flat at low viewing luminance (-> dark prints), whereas images processed at low monitor luminance (for good prints) tend to yield an over-processed, too contrasty look when changing to a high viewing luminance like e.g. with a slideshow on a TV screen.

Not sure though about the second statement regarding "perceived saturation going down with increasing brightness",
is it a known perceptual effect ?

--
http://www.lumita.com/labs/whitepapers/
http://www.lumita.com/site_media/work/whitepapers/files/pscs3_rendering_image.pdf

Title: Re: Luminence value for web output
Post by: GWGill on February 22, 2015, 05:31:10 pm
the higher the monitor luminance, i.e. the closer it is to the scene luminance,
the less of tonal lifting is typically needed, e.g. referring to the common S-curve.
Hmm. I'm not sure that's right.

Here's my hand-waving type explanation:

For a display to be usable, its brightness needs to roughly match that of its surroundings. If a display is much darker than the surroundings, then you will struggle to see any mid tone detail in it. If it is markedly brighter, you get a lot of eye strain.

A display in bright surroundings generates a lot of flare & glare in what we see, partly from reflection from the display itself, and partly because of the optical properties of our eyes. The bright surroundings also set our eye's brightness adaptation at higher level, making us less sensitive to darker tones (we are most sensitive to differences from what we are currently adapted to). So shadow detail tends to disappear, unless it is given a lift. Adding this lift corresponds to displaying the image with a lower power curve or gamma value.

A display in dark surroundings generates much less flare & glare in what we see, and our eye's brightness adaptation is set at a much lower level, so we are much more sensitive to the shadow detail. So if shadows detail is not to be over-emphasized, it needs to be reduced. Making this reduction corresponds to displaying the image with a higher power curve or gamma value.




Title: Re: Luminence value for web output
Post by: Simon Garrett on February 22, 2015, 05:52:49 pm
Not sure though about the second statement regarding "perceived saturation going down with increasing brightness",
is it a known perceptual effect ?

Surprisingly, yes it is.  Here's a series of strips from 5 photos merged together of the same plain red sheet, each with different exposure:

(http://www.simongarrett.co.uk/Colour_Strength.jpg)

Note how the darker ones appear to have greater saturation?  If you look at them in Photoshop, as one goes from lower to higher exposure, the saturation goes down and brightness goes up (hue stays the same, obviously).
Title: Re: Luminence value for web output
Post by: Peter_DL on February 23, 2015, 01:26:40 pm
Here's a series of strips from 5 photos merged together of the same plain red sheet, each with different exposure:
If you look at them in Photoshop, as one goes from lower to higher exposure, the saturation goes down and brightness goes up

... however the red channel is clipped at 255 in the +EV patches.

Could be an issue from gamut conversion, the file as downloaded is tagged with sRGB.

--
Title: Re: Luminence value for web output
Post by: Simon Garrett on February 23, 2015, 03:12:36 pm
... however the red channel is clipped at 255 in the +EV patches.

Could be an issue from gamut conversion, the file as downloaded is tagged with sRGB.

--

Hmm... it's OK in Lightroom (no clipping of the red channel, and it's and sRGB jpeg, so should be no gamut conversion issues).  However, I've done it again:

(http://www.simongarrett.co.uk/DSC_2524_Colour_12-Edit_sRGB_LR_LR.jpg)

I've loaded the jpeg into Photoshop, and the brightest patch has R=252, G=0, B=55.  The patches are 0.3EV apart. 

The effect perhaps isn't very clear on this, but originally I did this test for a course I was doing (written by Michael Freeman - author of "The Photographer's Mind" and many more).  What he said was:

Quote
What you should be able to see is that the actual colour changes with the exposure. Under-exposure produces a ‘stronger’ colour, and in professional photography this is quite a common technique.

Perhaps more realistic is to take a typical image.  I find that underexposed images often appear more saturated than correctly exposed ones, even if there is no clipping of colours. 

Title: Re: Luminence value for web output
Post by: Peter_DL on February 23, 2015, 04:31:59 pm
In LR/ACR this impression can result from the default S-curve which has a characteristic side effect on color saturation,
increasing it for the shadows and midtones while decreasing it for the highlights (insofar corresponding to the behavior of a RGB S-curve).
By varying the camera-exposure the data are initially placed under different sections of this curve.

--
Title: Re: Luminence value for web output
Post by: Peter_DL on February 23, 2015, 05:01:33 pm
For a display to be usable, its brightness needs to roughly match that of its surroundings. If a display is much darker than the surroundings, then you will struggle to see any mid tone detail in it. If it is markedly brighter, you get a lot of eye strain.
...
A display in dark surroundings generates much less flare & glare in what we see, and our eye's brightness adaptation is set at a much lower level, so we are much more sensitive to the shadow detail. So if shadows detail is not to be over-emphasized, it needs to be reduced. Making this reduction corresponds to displaying the image with a higher power curve or gamma value.

Hmm. I'm not sure that's right.

With a scene of broad dynamic range, and a white luminance far above a monitor’s candelas,
all tones usually look dark and flat with a linear, scene-referred rendition on screen:
/> the lower the monitor luminance,
/> and the brighter the surrounding light - the worse it gets,
… and the higher the need for a brightening S-curve, or a more elaborated tone mapping technique which adds brightness and contrast to the mid tones while preserving shadow and highlight details,
in order to obtain a pleasing rendition.

My 2 cents.

--

Title: Re: Luminence value for web output
Post by: Simon Garrett on February 23, 2015, 06:24:57 pm
In LR/ACR this impression can result from the default S-curve which has a characteristic side effect on color saturation,
increasing it for the shadows and midtones while decreasing it for the highlights (insofar corresponding to the behavior of a RGB S-curve).
By varying the camera-exposure the data are initially placed under different sections of this curve.

Yes, that's certainly true.  I'd not really thought about that. 

I've read in several places (not just by Michael Freeman) the idea of the same saturation appearing lower in brighter images than darker images but perhaps it's not a physiological effect, rather it's an artefact of the way raw conversion works (whether in-camera or on a computer).  In other words: converting from the scene-referred raw image to an output-referred jpeg or screen rendering, in almost all cases an S-curve is applied, with the effect you describe. 
Title: Re: Luminence value for web output
Post by: Tim Lookingbill on February 23, 2015, 09:47:13 pm
Yes, that's certainly true.  I'd not really thought about that.  

I've read in several places (not just by Michael Freeman) the idea of the same saturation appearing lower in brighter images than darker images but perhaps it's not a physiological effect, rather it's an artefact of the way raw conversion works (whether in-camera or on a computer).  In other words: converting from the scene-referred raw image to an output-referred jpeg or screen rendering, in almost all cases an S-curve is applied, with the effect you describe.  

Don't forget to consider the influences of the Adobe Color Engine designed by Thomas Knoll that operates under the color management hood of both Adobe Raw and gamma encoded image editors. The contrast influenced hue/sat shift you're describing is a well known issue/feature? going back at least a decade when complainers were advocating a more Lab space or HSV? preview behavior when editing color. I remember reading Mr. Knoll designed the color engine to behave that way to emulate a more film like color appearance.

Try making that red ramp in Lab space and see how the steps change in appearance. Not sure but I don't think it will make that much of a difference because the preview still has to go through the ICC base color transform of the custom display profile.

I've often thought that what confuses me and most photographers who post process when describing how edited color previews behave is that we seem to think the contrast/brightness tools are suppose to behave like real lights on a real object or scene we've captured which I don't believe these tools are primarily designed to do. There's seems to be too much "English" designed into the algorithms that map the color to the displayed preview.

From my observations increase/decrease in exposure is a photographic concept which has no correlation to how a real light behaves due to the fact the original light that illuminated the original scene changes in character from scene to scene that no slider or curve can match. That's why we're given so many other tools to work with in order to create a match according to how we remember the character of light.
Title: Re: Luminence value for web output
Post by: digitaldog on February 24, 2015, 10:28:52 am
Don't forget to consider the influences of the Adobe Color Engine designed by Thomas Knoll that operates under the color management hood of both Adobe Raw and gamma encoded image editors.
Actually do forget about it. Unless there's a bug in a CMM, the differences should be tiny (tests I've done were way less than a dE of 1 so invisible). Further, what ACE provides other CMM's may not is Black Point Compensation which really isn't a factor with this discussion.

Here is a 988 patches in Adobe RGB (1998) converted to sRGB using ACE and Apple CMM:

--------------------------------------------------

dE Report

Number of Samples: 988

Delta-E Formula dE2000

Overall - (988 colors)
--------------------------------------------------
Average dE:   0.02
    Max dE:   1.11
    Min dE:   0.00
 StdDev dE:   0.09

Best 90% - (888 colors)
--------------------------------------------------
Average dE:   0.00
    Max dE:   0.00
    Min dE:   0.00
 StdDev dE:   0.00

Worst 10% - (100 colors)
--------------------------------------------------
Average dE:   0.16
    Max dE:   1.11
    Min dE:   0.00
 StdDev dE:   0.25

--------------------------------------------------
--------------------------------------------------
SINGLE worst patch and ONLY one over a dE of one from all 988 color patches (RGB and Lab) values:
2.0   7.0   3.0   1.55   -1.82   1.07         
0.0   7.0   1.0   1.40   -2.59   1.64         
dE 1.11   

Basically forget about it Tim.
Title: Re: Luminence value for web output
Post by: Tim Lookingbill on February 24, 2015, 02:00:22 pm
Andrew, did you apply the same tests in other non-Adobe Raw converters which use a different color engine? (i.e. Iridient Developer, Capture One, etc.)? There is a difference unless things have changed in PV2012 with regards to preview behavior increasing and decreasing contrast in edits AND white balance adjustments in how blue/yellow & green/magenta hues and saturation levels are interpreted which also compounds the issue editing landscapes and interiors, not static patches of color in a profiling/calibration session.

This is a preview behavior not readily seen in controlled tests. Have you tried changing the contrast in a scene referred vs output referred landscape to notice a difference to hue/sat changes? Photographers don't use science to edit images, they use their emotions.

Title: Re: Luminence value for web output
Post by: digitaldog on February 24, 2015, 03:33:07 pm
Andrew, did you apply the same tests in other non-Adobe Raw converters which use a different color engine? (i.e. Iridient Developer, Capture One, etc.)?
ACE isn't available so it's moot. I did the conversions in Photoshop where switching from ACE to whatever other CMM's are available is accessible. But again, unless there is a bug with a CMM, the differences should and are tiny! So again, Actually do forget about it.
Quote
There is a difference unless things have changed in PV2012
That may be so, it's not ACE. That's not how CMM's work or are designed to work Tim.
Title: Re: Luminence value for web output
Post by: digitaldog on February 24, 2015, 03:54:09 pm
Photographers don't use science to edit images, they use their emotions.
Maybe that's why they think and report they see things that don't exist, like differences in CMM's. Colorimetry as shown below proves what they think they see doesn't exist.
Title: Re: Luminence value for web output
Post by: Tim Lookingbill on February 24, 2015, 10:08:13 pm
ACE isn't available so it's moot. I did the conversions in Photoshop where switching from ACE to whatever other CMM's are available is accessible. But again, unless there is a bug with a CMM, the differences should and are tiny! So again, Actually do forget about it. That may be so, it's not ACE. That's not how CMM's work or are designed to work Tim.

Can you provide proof because I read from the horses mouth Thomas Knoll that he designed the underpinnings that affect saturation in previews when editing contrast in order to render with a film like look in the very issue that is being discussed here and many years ago. He said he designed the color engine but I can't remember if he was referring to ACE which stands for Adobe Color Engine. Not CMM=Color Management Module. I'm not talking about color management here. I'm talking about contrast induced saturation changes when editing images.

So could you provide evidence that this behavior is not on account of TK's design of how edited previews behave this way? Maybe it's not called ACE but something else and I just assumed back then that ACE was where the design resided.
Title: Re: Luminence value for web output
Post by: GWGill on February 25, 2015, 02:44:51 am
He said he designed the color engine but I can't remember if he was referring to ACE which stands for Adobe Color Engine. Not CMM=Color Management Module.
ACE = Adobe's ICC CMM

But a CMM would be just one small part of an application like PhotoShops color code.
Title: Re: Luminence value for web output
Post by: digitaldog on February 25, 2015, 08:59:51 am
Can you provide proof because I read from the horses mouth Thomas Knoll that he designed the underpinnings that affect saturation in previews when editing contrast in order to render with a film like look in the very issue that is being discussed here and many years ago.
Tim, I'm afraid you don't know what you are taking about! First off, ACE IS a CMM! It is accessible from the CMM dropdown in PS itself along with others. Been that way since 1998.

I proved that there's tiny, tiny differences between it and Apple's CMM below using good old colorimetry. Of 988 colors, only one is 0.1 dE over a value of 1, 987 patches are invisible in terms of their differences. Further, of the 988 patches, about 800+ are 0.00 dE apart. Care to explain that?

2nd, if you understand the actual role of ACE as a CMM, you'd know you are being silly suggesting it's the causes of any numeric or visual differences from any other CMM. It would be just chaotic if using the same data, profiles and software (or different software), a conversion would be much different solely due to a CMM. UNLESS that CMM has a bug.

3rd, it is you sir that needs to prove your point which falls in the face of logic based on the above by stating: Don't forget to consider the influences of the Adobe Color Engine designed by Thomas Knoll that operates under the color management hood of both Adobe Raw and gamma encoded image editors. You have as yet no means to back that up yet you've got the balls to ask me for proof after I did so with a very simple test that shows ACE and Apple CMM with the same profiles and data produce colorimetrically identical visual output from the two conversions? You serious bud?

What ever Thomas told you, you obviously didn't understand. It's simply ridiculous for someone who thinks he understands the role and design of a CMM to make the point you did and you've so far have nothing to back it up.
Title: Re: Luminence value for web output
Post by: digitaldog on February 25, 2015, 12:30:51 pm
Oh Tim, here's a report converting from Adobe RGB to a print output color space (rather than to sRGB) using two different CMM's again. In this case NONE of the 988 color patches are visibly different!

--------------------------------------------------

dE Report

Number of Samples: 988

Delta-E Formula dE2000

Overall - (988 colors)
--------------------------------------------------
Average dE:   0.12
    Max dE:   0.85
    Min dE:   0.00
 StdDev dE:   0.15

Best 90% - (888 colors)
--------------------------------------------------
Average dE:   0.09
    Max dE:   0.31
    Min dE:   0.00
 StdDev dE:   0.11

Worst 10% - (100 colors)
--------------------------------------------------
Average dE:   0.41
    Max dE:   0.85
    Min dE:   0.31
 StdDev dE:   0.12

--------------------------------------------------
--------------------------------------------------
Title: Re: Luminence value for web output
Post by: Tim Lookingbill on February 25, 2015, 01:39:01 pm
ACE = Adobe's ICC CMM

But a CMM would be just one small part of an application like PhotoShops color code.

I was understanding it that way as well but I seem to not communicate effectively enough to Andrew. The behavior of edits within a color managed preview (that involves transforms and connection spaces when using editing tools to translate to the video system through ICC display profile) has to be tracked/encoded/described in order for the CMM to commit it to the final tagged image in order for the preview to match across other CM apps.

My question is at what stage does Photoshop/ACR/LR color coding and whatever else is rendering the previews influences this contrast induced saturation behavior shown in the red ramps and other similar color preview mapping and hands it off to the CMM and if the CMM has any transform/preview controlling influences.

Andrew, to keep it simple could you explain simply what is making the darker reds appear more saturated and light reds less saturated in the red ramp posted here?
Title: Re: Luminence value for web output
Post by: digitaldog on February 25, 2015, 02:46:13 pm
I was understanding it that way as well but I seem to not communicate effectively enough to Andrew.
Your communication was clearly wrong and understood by more than just me! ACE is a CMM. ACE has absolutely nothing to do with what you are referring to or understood from Thomas (still clearly undefined but you're quite sure it's spot on).
Quote
The behavior of edits within a color managed preview (that involves transforms and connection spaces when using editing tools to translate to the video system through ICC display profile) has to be tracked/encoded/described in order for the CMM to commit it to the final tagged image in order for the preview to match across other CM apps.
Yes and this has nothing to do with ACE.
Quote
Andrew, to keep it simple could you explain simply what is making the darker reds appear more saturated and light reds less saturated in the red ramp posted here?
It has nothing to do with the CMM named ACE. The statement: Don't forget to consider the influences of the Adobe Color Engine designed by Thomas Knoll that operates under the color management hood of both Adobe Raw and gamma encoded image editors. is simply incorrect. There's all kinds of proprietary image processing going on under the hood, about the only human here on LuLa what could know and explain it is Eric and that's unlikely to happen. Whatever those differences are, they have nothing to do with ACE as used as a CMM to convert color data. Got it?
Title: Re: Luminence value for web output
Post by: Tim Lookingbill on February 25, 2015, 04:41:18 pm
Quote
Whatever those differences are, they have nothing to do with ACE as used as a CMM to convert color data. Got it?

I got it you don't know and you don't have any evidence to prove what you're saying. But I do know you haven't been helpful in explaining the behavior of the red ramp saturation change. Got it?
Title: Re: Luminence value for web output
Post by: digitaldog on February 25, 2015, 05:46:15 pm
I got it you don't know and you don't have any evidence to prove what you're saying. But I do know you haven't been helpful in explaining the behavior of the red ramp saturation change. Got it?
Now you're playing the fool and deserve an academy award.
You made a false and rather ridiculous statement about ACE. Both Graeme and I had to point out that ACE is a CMM. I don't know if you even understand what ACE or CMM's provide but the point is, I easily dismissed the incorrect post you made:
Quote
Don't forget to consider the influences of the Adobe Color Engine designed by Thomas Knoll that operates under the color management hood of both Adobe Raw and gamma encoded image editors.
Quote
He said he designed the color engine but I can't remember if he was referring to ACE which stands for Adobe Color Engine. Not CMM=Color Management Module.
ACE has no such influence. I proved that using colorimetry and a process anyone here can replicate and prove to themselves. Meanwhile and as your usual M.O. you have provided NO such evidence of what you incorrectly wrote. So telling! The red ramp is your red herring. It has zero to do with ACE.

If you were as smart as I used to think you were Tim, you could have said something to the effect of: "Andrew, I must have confused ACE with something else" and accepted the facts I've provided about ACE, CMM's and their tiny differences on the data they touch. But no, you have to continue looking foolish to others here by ignoring the colorimetric facts, the facts of what a CMM should be doing and then going down a red ramp rabbit hole that isn't getting you off the hook for a statement you made based on severe misunderstanding of CMMs.

You may have thought you heard (or read, not sure) from the horses mouth (Thomas Knoll) that the sun rises in the west and sets in the east but that's simply untrue. When shown the error of this mistake, you ask about the color temp of the sun before it sets, ignoring it never sets in the east. That's foolish but you are welcome to act that way and ignore the facts. So far you are unable or unwilling to backup the statements you've made about ACE. While asking me to back up their facts on something that has nothing to do with ACE. Again, very telling.  

I don't know nor care at this point about the red ramp. We're not ready to discuss that until you either admit you're wrong about ACE or except what you incorrectly think about it and the setting sun is factual. Neither are. Got it?

Why you refuse to make this a learning experience for yourself with respect to ACE and your incorrect statements is also a shame and rather telling.
Title: Re: Luminence value for web output
Post by: Tim Lookingbill on February 25, 2015, 11:25:53 pm
I've spoken my peace and counted to three. We will have no more talk on this matter, Andrew Jackson Rodney.
Title: Re: Luminence value for web output
Post by: digitaldog on February 26, 2015, 04:24:33 am
I've spoken my peace and counted to three. We will have no more talk on this matter, Andrew Jackson Rodney.

Being ignorant is not so much a shame, as being unwilling to learn.”
― Benjamin Franklin

Yes Tim, probably best to ignore the facts about ACE and run away. Hopefully in terms of this subject in relationship to ACE the CMM, all other readers here understand the facts and your inability to learn and accept them. Useful for your future postings on the subject. Good-by.
Title: Re: Luminence value for web output
Post by: Tim Lookingbill on February 26, 2015, 12:17:15 pm
You're the one that can't explain effectively the saturation behavior in the red ramp demo so I'ld say you're just as ignorant and I'll add quite tone deaf to humor.
Title: Re: Luminence value for web output
Post by: digitaldog on February 26, 2015, 12:32:36 pm
You're the one that can't explain effectively the saturation behavior in the red ramp demo so I'ld say you're just as ignorant and I'll add quite tone deaf to humor.
That has zero to do with your erroneous statements about ACE. I know it's tough to look in the mirror Tim and admit you made a mistake and learn from it! Benjamin summed up your attitude perfectly.

I can't explain what took place prior to the big bang, but that doesn't alter the proof I provided that dismissed the two sentences you wrote about ACE. Two wrongs don't make a right. One unexplained process doesn't defend a severe miss understanding proposed by Mr Tim Lookingbill. That you continue to focus on a red ramp while ignoring a mistake you made about a CMM isn't going to disappear Tim. Get your facts straight if you can.

Now, as to what you think you heard or think understood from Thomas, you are so vague and confused I'm not sure what you are scrabbling about. I can tell share this:

Quote
A new message was posted by Thomas Knoll in

Adobe Camera Raw --
  Color reproduction in digital photography

While developing Camera Raw, I experimented with a pure luminance curve (as Simon suggests). However, based on my testing results, I rejected this algoirthm since it produced results that were most often visually worse looking that the tone curve algorithm actually used by Camera Raw (which is a special hue-preserving curve, NOT three indepent curves as Simon incorrectly assumed). The saturation effects that Simon considers a defect is actually something that most users actually want.

You have a short memory Tim: http://forum.luminous-landscape.com/index.php?topic=72369.new;topicseen
But again, this has nothing to do with your misinformation about the CMM Thomas built. Got it?
Title: Re: Luminence value for web output
Post by: digitaldog on February 26, 2015, 12:42:21 pm
We will have no more talk on this matter, Andrew Jackson Rodney.
And yet, you keep on talking. You're not even good to your own word Tim.
Title: Re: Luminence value for web output
Post by: Peter_DL on February 26, 2015, 04:59:36 pm
Many thanks Andrew,

- for clearing the way
so that we can return to the OP’s question which I for one find interesting:


Ok, I know that this is mostly an unanswerable question but I gota at least try.
Think of it as the photographic equivalent of a controlled crash landing.
Does anyone have any thoughts about what to set  your luminance target for your display in preparing files for websites?

I am calibrating my monitors with  i1 software & hardware.
This is what I set up for targets...
White point = D65
Luminance = 120
 
To quote from the whitepaper (http://www.lumita.com/site_media/work/whitepapers/files/pscs3_rendering_image.pdf) which I had referenced earlier:

>> Transforming scene-referred data with a 100,000:1 dynamic range into a print is a complex and subjective process. Any two viewers will disagree on what looks best. Transforming a 400:1 output-referred image to 300:1 or 200:1 is pretty straightforward and most people will be happy with a simple fixed method that is the same for all their photographs. Although the photographic industry still has not fixed a universal standard, most JPEGs and other output-referred images have a target dynamic range of about 400:1. By design, this also compares favorably with computer displays, so the images look correct on your screen as well. ... <<

… which makes me believe that there must be a kind of standard for the white luminance [cd/m2],
e.g. with the monitors in the labs of a camera manufacturer, where the engineers work on the algorithms for in-camera-JPEG conversion.  At least that's what I would assume that happens.

So following the logic of the above quote, when prints correspond to an avg. 250:1 dyn. range,
and assuming that ca. 125 cd/m2 on screen work for print-image-matching,
it makes a black luminance of 0.5 cd/m2,

and with a 400:1 monitor dyn. range,
it finally points to a white luminance of 200 cd/m2.

A lot of assumptions here as I have to admit, maybe too simplifying (?),
however, in practice it corresponds (roughly) to my monitor's output and brightness setting for the given purpose.

Peter

--
Title: Re: Luminence value for web output
Post by: digitaldog on February 26, 2015, 07:17:31 pm
Well one solution to the OP's question (Does anyone have any thoughts about what to set  your luminance target for your display in preparing files for websites?) is this: take a pile of postIt notes, write a group of values on 10 from say 100-200 on each, tape them to the wall, throw a dart and the value the dart hits is the answer.  ;D

We've got basically three groups. One is very sophisticated about color, photography and imaging (the vast majority of the LuLa audience). They are not using CRT's left over from the last century, they work with color managed applications including web browsers. And they care how they and others see their images.

The 2nd group isn't anything like the first. Many probably are working with 15 year old CRTs that today might output 75cd/m2 or they have to buy the cheapest LCD they can find. They will not calibrate because they have no idea that that is or if they do, they will not spend the money to do so. Futz with the OSD controls, maybe. They are unaware their browsers are not color managed. As long as there is any degree of color emitting off the display, they are basically somewhat of happy.

There's a 3rd group that's very much like the 2nd but whatever they see, it's wrong and they don't like it and will tell you how bad your images are. This group is helpless.

So basically the question is, aim for group 1, or aim for group 2-3 and suffer no matter what dart hits the PostIt note value?

One solution for group 1 and some group 2 stragglers who really do want to navigate to group 1 is to place a black to white step ramp somewhere on the web page and tell people who don't know otherwise that they should be able to make out say the 21 steps and if they see blown out whites in several patches, or blocked up blacks, they are incorrectly viewing the web images. A URL to a site that will inform them if their browser is color manages is useful too*. IOW, education. People either care about the color they see and strive to get it, they care but don't know how to achieve it or they don't give a crap and will complain no matter what you do.

Even if we agree on some ISO spec for cd/m2, it does no good for group 2-3. I'm fairly certain that within group 1, just here on LuLa, there is a range of calibrations for cd/m2, probably between 120 - 160 cm/m2, some lower because they wish to emulate the CRT's of the past. Might make an interesting poll. I calibrate to 150cd/m2 because that setting produces the closest visual match to my viewing booth. Yet when I travel about the web using my color managed browser, I cannot recall seeing 'quality imagery' (not the offering of group 2-3) that doesn't look AOK. The images look fine.

As to Peter's link, if Karl states it, you can probably take it to the bank. There are few people around who both understand this topic more and have brought to market two of the finest display products in imaging history (Radius PressView, Sony Artisan) and invented ColorMatch RGB. And it helps he really is a color scientist. Whether that equates to 200cd/m2 (seems a bit high) or not would make an interesting experiment for group 1 and do nothing to help group 2-3.

Frankly I do not think this a hill worth dying on. If your only concern is output to the internet and you feel 200cd/m2 is a good middle of the road, and you understand that you simply can't satisfy all the people who will view your images with or without color management, go for it. Or just throw that dart and see where it lands. In the grand scheme of things, probably doesn't matter. How many people viewing your images on the web are even using a browser that understand the numbers it spits out?   

*This is probably enough info for this group to understand: http://www.color.org/version4html.xalter
Title: Re: Luminence value for web output
Post by: D Fosse on February 27, 2015, 01:37:31 am

So following the logic of the above quote, when prints correspond to an avg. 250:1 dyn. range,
and assuming that ca. 125 cd/m2 on screen work for print-image-matching,
it makes a black luminance of 0.5 cd/m2,

and with a 400:1 monitor dyn. range,
it finally points to a white luminance of 200 cd/m2.

There's a basic flaw here. The dynamic range limitation in print vs. screen is the black point, not the white. Matte paper has lower contrast than glossy because the black point is higher.

To extend the dynamic range from 250:1 to 400:1, all you need to do is let the monitor go down to its native black point, which is usually in the 0.3 range (or lower).

A couple of calibration targets with different black points will take care of all this, and you can still have the same white point and overall luminance.

Great post by Andrew, summing it up nicely. Personally I just care about group 1 and ignore 2 and 3.
Title: Re: Luminence value for web output
Post by: Simon Garrett on February 27, 2015, 05:56:31 am
Great post by Andrew, summing it up nicely. Personally I just care about group 1 and ignore 2 and 3.

I agree. 

The 3rd group are beyond help so there's not much point worrying about them.

Group 2 are the "fat, dumb and happy" group.  No point providing images that will be "right" on their monitors, as every monitor will be different.  However, people get used to how images look on their monitor.  They adapt to what they see. 

An interesting recent example is this (http://www.telegraph.co.uk/technology/social-media/11438815/What-colour-is-this-dress-Tumblr-photo-could-actually-break-the-internet.html).   Colour photometry expert Taylor Swift sees only blue and black in the image.  She notes she's "confused and scared", which I would be if my monitor were that bad. 

By the way, I get a bit nervous about the v4 test page on the ICC web site, as it doesn't show what people think (or even quite what the site says).  It just shows whether the browser being used makes an attempt to use v2 and v4 profiles.  It doesn't show whether the user's monitor is calibrated and profiled, and it doesn't show whether the browser is fully colour managed.  For example it apparently shows that Internet Explorer is fully colour managed, which it isn't. 
Title: Re: Luminence value for web output
Post by: digitaldog on February 27, 2015, 04:12:03 pm
By the way, I get a bit nervous about the v4 test page on the ICC web site, as it doesn't show what people think (or even quite what the site says).  It just shows whether the browser being used makes an attempt to use v2 and v4 profiles.  It doesn't show whether the user's monitor is calibrated and profiled, and it doesn't show whether the browser is fully colour managed.
Yes, it could be more clear and it isn't the best designed page for group 2. I also like another URL on the topic but group 2's heads will explode:

http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html

The answer again is education. Like the step ramp, instructions have to be written for the group 2 users who hope to migrate into group 1. They will need hand-holding. I suppose if we left these two pages as our choice for informing them, we could add some text explaining they go to this URL and if big top image looks like the last and smaller image (multiple color renderings), they have a problem. I mean for some, we'll need to explain something as simple as gray ramp path 1 and 2 (or 20-21) have to show a separation of tone. We can't assume they even understand what "your #2 dark patch is blocked up" means without full explanation.
If someone wants to build a page for group 2 that's more self explanatory, be useful.

Funny timing, I got a call today from a friend who stated when he views his product packaging on his web page on the Mac, it's fine but looks awful on any mobile devices. He knows to send his web guy sRGB files. I went to his site, downloaded the image, it was in ProPhoto RGB! Whoever was working on his web page somehow uploaded the wrong JPEG.