- This topic has 29 replies, 4 voices, and was last updated 1 year, 11 months ago by
.
-
Posts
-
Hi people,
i’ve been reading several topics here and first of all I have to say I am amazed about your knowledge concerning display technologies and measurements. 🙂
For the special purpose of measuring the smartphone and tablet color accuracy I did not found much but only one topic which is kind of similar to my problem but different though. So this is how I do it and the problems I am confronted with.
- I am using and Eizo EX4 which is in fact an Spyder X. With the right drivers and a work around i could make it work with display cal.
- On the smartphone or tablet I use spacedesk via browser to use it as a second screen for the pc on which is display cal installed
- In Display Cal I choose the “Generic Display PnP Monitor” , as Mode “Generic”, no corrections and as settings above “Actual settings”, then on the tab “calibrating” everthing on “as measured”
- I start with “calibrate and profile”, skip the measurement and proceed with calibration.
- In the end i get a result giving me the three color areas sRGB, Adobe and dci p3 in percentage accuracy.
These are my issues:
- I am not sure, if all the settings I used are the right. When i tried different modes it seemed it does not affect the results. Im not sure if the settings in the “validate”-tab do affect the procedure. Especially not sure if I need a certain ccss.
- On ipad and iphone i get pretty bad dci p3 around 70%, while its very high on a Samsung Galaxy S21. Thats not very plausible since new ipad screens should have extraordinary accuracy esspecially on dci p3. My first guess was that the safari browser i use does not support dci p3. But I tried with other browser, the results were the same. So maybe spacescreen is the cause. For that i read, it is possible to connect with thirdparty apps/services since display cal allows webhost. But I did not find any detailed instructions of how i can connect through a browser with the server if this is possible at all (?).
- When i use measuring report instead of the “calibrate and profile” button i get a lot of results like contrast ratio and delta e for all tested colors, but i miss the percentage of accuracy. is there a way to get it there too?
I am sorry, that i am not a pro like the most of you but i try my best to get a better understanding of measuring right and would appreciate any help. Thanks.
SpyderX Pro on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Discussed here:
Since SpyderX does not support CCSS but supots CCMX you’ll need:
-an spectrophotometer to crate a matrix correction for colorimeter ON EVERY DISPLAY you want to measure, a CCMX FOREACH DISPLAY
or
-“trust”/”believe” that certain spmartphone model X uses some well known backlight supported in built int measurement modes of Spyder X (mode in upper right screen in device tab). Measured whitepoint is very likely to be off vs actual one because all thsese uncertainties.
Ok, thanks a lot for that info. Yes, i gues you are right with the measured white-point. So what i did for a work around is to measure the white point and set it manually on a second run. That gave slightly better results.
Furthermore: What i am wondering about, is, that after first calibration i get three values of color range and color accuracy also the average delta e. But when i use the mearuement report above instead of “profile and calibrate” button, it gives me html report with all the values in detail, and there the delta e is totaly different value. Also am not sure if these colors are rgb or p3 or both. There is only a list with 51 colors and the delta e to each, and no percentage of accurancy at all.
So what method is to choose and why are the results so different?
Also am not sure if these colors are rgb or p3 or both.
These colors are RGB colors in current display gamut described by profile… unles you use some simulation:
-in color managed apps (simulate profile)
-in non color managed apps (simulate profile and use simulation as display profile, will all calibration disabled)It’s explained in the link, depending on measurement report configuration:
-validate if profile maches display colorspace (default)
-validate if profile is accurate enough to render accurately colors of some particular image colorspace in Ps/Lr (simulation profile)
-validate if display without calibration in its current OSD mode matches some colorspace (simulation profile + use as display profile)For smartphones if you want to test factory calibration you need the 3rd one. No DisplayCal calibration is needed.
HCFR, a display cal cousin app can do the same in a calman like UI (although DisplayCAL HTML report shows additional interesting info like grey range)Thank you very much. As said in that post you mentioned
“Remember: use dsiplay profile as simulation profile for testing out of the box sRGB/P3 modes.”
So this is what i do to make a testing out of the box sRGB/P3 quality
- Since the Spyder X does not support ccss i put the mode to generic or take a guess (i know this is not accurate, will eliminate with a spectrometer soon)
- I put settings to “actual settings”
- Profiling and calibration tab are not needed, so i skip that tabs (right?)
- On the last tab “Validating” i am not sure which testform and simulationprofile to choose when i want sRGB and DCI P3. I tried different, for example expanded testform and “DCI P3 SMPTE”.
- I put gamme to 2.2 and run the report
Results are pretty bad. Maybe its because i have chosen the wrong form and profile?
Results are pretty bad. Maybe its because i have chosen the wrong form and profile?
First of all you need to change smartphone screen mode to whatever you are trying to validate.
You can use HCFR to make a fast RGB primaries measurement so you know what “basic” or “cinema” screen modes actually mean. Or argyllCMS spotread, or DisplayCAL using the simplest patch set.
“DisplayP3” profile bundled with ArgyllCMS, ref folder, should be P3 gamut, D65 white, ~sRGB TRC.
You can make whaterver colorspace profile you want using Synth profile editor in DisplayCAL.You can use HCFR to make a fast RGB primaries measurement so you know what “basic” or “cinema” screen modes actually mean. Or argyllCMS spotread, or DisplayCAL using the simplest patch set.
Do you mean by these modes the smartphone settings or the modes i am testing with in displaycal? Basically i want to validate, how good or bad the color accuracy is on a smartphone with its default settings. So i won’t change any mode of the smartphone itself, which for example Samsung has, but iPhone dont. So is this advice still neccessary?
“DisplayP3” profile bundled with ArgyllCMS, ref folder, should be P3 gamut, D65 white, ~sRGB TRC.
You can make whaterver colorspace profile you want using Synth profile editor in DisplayCAL.Sorry, I dont really understand what you mean by ref folder. DisplayP3 is avaible and i can use it. And by “synth” profile you mean “sim”? I dont find any synth setting.
BTW: HCFR wont recognize my EX4 Sensor with Spyder X drivers. I will get my Spyder X Elite soon and hope it will work with hcfr or datacolor software.
You can use HCFR to make a fast RGB primaries measurement so you know what “basic” or “cinema” screen modes actually mean. Or argyllCMS spotread, or DisplayCAL using the simplest patch set.
Do you mean by these modes the smartphone settings or the modes i am testing with in displaycal? Basically i want to validate, how good or bad the color accuracy is on a smartphone with its default settings. So i won’t change any mode of the smartphone itself, which for example Samsung has, but iPhone dont. So is this advice still neccessary?
In smartphone settings. In android usually “default settings” is full native gamut not color managed, hence on AMOELD displays all should look bad.
IDNK if iOS devices are color managed in browsers, if they are and they render raw RGB colors as RGB you can’t validate whole screen, only if color management renders sRGB properly. For video if it has a default player that is color managed you’ll need to feed it with video patch sets encoded in certain colorspace that video app detects…HCFR seems handy here.
“DisplayP3” profile bundled with ArgyllCMS, ref folder, should be P3 gamut, D65 white, ~sRGB TRC.
You can make whaterver colorspace profile you want using Synth profile editor in DisplayCAL.Sorry, I dont really understand what you mean by ref folder. DisplayP3 is avaible and i can use it. And by “synth” profile you mean “sim”? I dont find any synth setting.
“ref” folder inside ArgyllCMS folder.
synth is synthetic. There is an app to make synthetic profiles. Define a gamut, define white, define TRC… and make a ICC profile that describes such colorspace you have created.
BTW: HCFR wont recognize my EX4 Sensor with Spyder X drivers. I will get my Spyder X Elite soon and hope it will work with hcfr or datacolor software.
Jumping on the wrong boat. Spyders X is a bad investment. Get an i1d3 colorimeter from Xrite: software updateable, faster, better low light readings, need to buy i1Displaypro if want to use HW calibration fro some displays.
I can find reasonable to “reuse” an existing, previously bought SpyderX that cannot be return to store…. but buying a new one? totally useless action.
IDNK if iOS devices are color managed in browsers, if they are and they render raw RGB colors as RGB you can’t validate whole screen, only if color management renders sRGB properly. For video if it has a default player that is color managed you’ll need to feed it with video patch sets encoded in certain colorspace that video app detects…HCFR seems handy here.
I think thats the point. Android phones give pretty plausible values measuring through the browser while ios devices get pretty bad results.
I dont have a spyder X, but a Eizo EX4 which i made run for displaycal with spyder x drivers. To ensure that this does not cause any faults i change to elite. I get the right drivers and i can try with datacolor software fits my purpose better.
Smartphone itself could have different approach to color management. CMS (color management system) is added to some newest Android versions but… all Android application were built as non color managed in past times. Now it seems that Android emulates sRGB for images in selected applications or globally in more expensive smartphones (or even recognizes ICC profiles in images), while device screens are roughly tuned to emulate sRGB when Android applies screen profile internally. AMOLED-based devices usually have vivid and natural color selector in settings, the last one looks like sRGB emulation. Note, that even PC-based browsers use different CMS, or at least different CMS settings. Firefox allows to set relative colorimetric intent (“direct color”, clipping for out-of-gamut colors) for image output, but it still shows quite less saturated colors than Photoshop. Chrome probably uses perceptual output, it does not have corresponding setting and it shows generally oversaturated images. Both have different content recognition modes, including paranoic sRGB assignement. I don’t know what may happen in mobile browsers. Bottom line is that most of Android devices don’t have explicit ability to use display ICC profile, you can’t clearly control image output, so you can’t really calibrate/profile these devices. And you can’t predict applications behaviour in general case, while using webhost display you need either non-corrected color output or standard profile emulation (colorimetric image correction permitted). I heard that some top-level devices have their own CMS, but I’ve never met them. May be, Datacolor has some special software that embeds ICC profile in Android core. X-Rite tool for mobiles is close to unworkable, it is only targeted to show images in special application and is buggy.
iPhones are fantastically different. I’ve met iPhone 12 Pro Max with strong yellowish tint and wrong color reproduction, and no settings/tools to correct it by eye. This was bought in Russia. But iPhone 11 Pro Max bought in America showed almost the same color as iMac 2017 Pro after calibration. I’ve met both bad and good cases with different iPhones, even different instances of ther same model. Note, that iMacs Pro and MacBooks Pro are factory calibrated, though not well and for some cool temperature (~7150K). Fortiutous Android devices are less accurate but also pretty good for sRGB images.
Note that when you compare two screens, both should have the same brightness and same tint. White consists of red, green and blue on your screen, so two times more bright smartphone shows much more saturated lady in red.
Always download images to web as documents if possible. This saves original files with profiles. When you download “as image”, new image without profile is usually generated. Some pools ignore profiles at all, so better to read their file type requirements. Some browsers and viewers ignore profiles in PNG files, but use them for JPEGs.
What do you mean “percentage of accuracy”? L*a*b/Lch are the best values to compare colors. Percentage is undescribed units in this case. Or you talk on gamut coverage percent? Really, 3D figure in L*a*b is better way to evaluate it (see Profile Info and you can generate it manually with much better grid with iccgamut and viewgam command-line utilities).
First of all, thank you for your reply.
What do you mean “percentage of accuracy”?
When I just start with “profile”-button, skip calibration a test is proceeded with a lot of images (about 175). After that i dont get the classic report but a little window showing me the accuracy AND gamut, which are two different things as you know, in percentage. See the attached pictore for more informations.
As I explained, the results here are pretty plausible when I use Android Smarthpones with Chrome Browser so I guess, it has a good CMS. But of course, i cannot be sure that some sort of wrong or none cms is causing other results here.
Again: My target is NOT to calibrate the display and to show its maximum capacity of showing accurate colors. My target is to measure how good the factory calibration of this display is out of the box. Only problem i am confronted with is, that i can depend on the application how colors are interpreted. So these are my possibilities:
- Using an app for measuring the display which is using a full cms. You mentioned x-Rite and datacolor. Since I get Datacolor the next days, i hope to get use of the app für ios/android for precise measurements.
- Using an app like gallary, put the pictures there manually and use HCFR which does support a manual mode from which you can choose the picture source manually. DisplayCal does not support a mode like this since it supports only via webbrowser right?
- Measure only in the browser and be clear about that i dont measure the device display itself, but how good colors are shown when you use the default web browser.
I would like to prefer first method.
Again: My target is NOT to calibrate the display and to show its maximum capacity of showing accurate colors. My target is to measure how good the factory calibration of this display is out of the box. Only problem i am confronted with is, that i can depend on the application how colors are interpreted.
Android config : default “screen configuration”
Do not calibrate, do not profile via web, just select remote web display on 1st tab
Measurement report: choose some patch set like 53 video or something not too big. Select sRGB as simulation profile, use simulation profile as display profile.For P3 LED or AMOLED screen re run this measuremeent report but with screen mode set to “basic” on android configuration (usually it is sRGB emulation if present)
PS: Do not buy an SpyderX… useless, get an i1d3 instead.
Thank you, I have now a i1studio, doing a good job with DisplayCAL.
In general I do as you recommend, so thanks for the advise.
I use advanced test form with 51 colors. My problem is, that these are always the same colors, no matter if I switch to sRGB or dci p3.
sRGB is no problem and I get a good report with pretty plausible results for different phones. For example the Samsung Galaxy S21 Ultra gives decent sRGB accuracy with low delta e (average of 0,96) on “natural color” mode in smartphone-settings, but gets worse results when putting it to the default “living colors” (delta e 3,5). On the other hand it covers the DCI P3 color space when you put in in living colors mode, so P3 results should be better than. To have a fair review, I should test this, so I put simulation profile to DCI-P3, but the report shows the exact same colors as with sRGB set.
Switching the test form to big with a number of 325 gives a better result of delta E av. 1,86, but still I don’t know which of these colors in the report are sRGB or DCI P3.
Is there a mistake I do or something I do not understand with the difference of measurements.
Patch set RGB numbers are the same, already explained.
Also if you want some kind of diagnosis of what you did wrong you need to attach full HTML report, since almost all user errors can be cheked there.
