I really just want Android to stop messing with the camera and let it take pictures. It's getting harder to take a photo without it stripping all the texture from people's faces and blurring out the background, or worse.
Here's a video of me moving around on a static background, taken from a tripod. Evidently bending the fabric of the universe as I move:
That's the stock camera app on my brand new Pixel 3a. Since this was taken, I've been experimenting with every setting possible to try to convince it that I don't want to "pop" or be "motion stabilized" but no, there's nothing that will stop it doing this.
What you are asking is certainly reasonable but may be technically impossible to achieve. It is probably not android but the camera hardware itself that does a large part of this processing.
The reason that today's cameras on phones look so much better than those of 10 years ago (especially for static photos) is due to advanced methods of image processing. The information available to the image is limited by the diffraction of the lens and by the thermal noise of the captor, and these are two physical constraints that can not be loosened. Thus, any increase of resolution is due to heavy image processing, that denoises and de-blurs the images so that they look as if they were better than they can actually be acquired by this captor. This is an ill posed problem since denoising and deblurring essentially act in opposite directions! The solution to this problem inevitably goes through projecting the low amount of information that you have into an image model of higher resolution. This necessarily leads to artifacts in some cases.
For the case of video, the motion artifacts that you observe in the rocks are often due to video compression and the correction of camera shake. The first is done in hardware so there's not much that you can do about it. The correction of camera shake may have a software part that you may be able to disable. Have you tried different camera apps?
Yeah wow, that's pretty bad. It looks like it thinks you are the thing that should be stationary and it's stabilizing the rocks with you as the reference point. Nice climbing by the way!
In the same vein I wish that Google would just let me view all the photos I had taken on my phone.
I almost exclusively use the "Camera" Album in the Photos app on my Pixel 2, but some update seemed to irreversibly back up and delete most (but not all?) of my photos. Now when trying to view all these backed up photos online (as there doesn't seem to be a way to get them back onto my phone) the feed is polluted with other random images from Whatsapp, etc. with no way to filter any of them out. And now I can't easily show anyone anything I took on my phone from a few months ago!
It's annoying because I quite like the Pixel 2 camera, but definitely agree with you that it should have more "dumb" options.
The odd thing is that a given piece of unrelated rock will be in perfect focus, then suddenly go blurry when I get near it (but not so near as to cast a shadow).
If it were video compression, you'd expect it would try to not alter pixels that didn't change from frame to frame. But it clearly updates large swathes of them.
Also, changing the compression mode in the camera from h.264/AVC to H/265.HEVC doesn't fix it.
As far as I know, video compression works on areas, not just pixels. To me, it looks like it's trying to update areas of the photo by moving areas of pixels, instead of just updating them individually. This is accidentally getting more than just the part that's moving, and making things nearby seem to move as well.
For instance, in the video provided in another comment, when the climber swings his legs up a bit, there's a portion of the wall that stretches behind him, before eventually un-stretching back into place. It flows behind the moving limbs. I suspect that if good video were taken of the scene, the leg would also be somewhat distorted while moving, but we can't really tell because it's supposed to be changing, unlike the rocks.
I spent the morning with the Open Camera app, standing in front of the stone wall of my garage and waving my arm slowly, trying to find a setting that didn't cause this effect.
No luck thus far. I can make it slightly less noticeable, or glaringly obvious. But I can't get rid of it.
Please let me know if you can (or better still can't) replicate it. I'm returning the phone tomorrow, but if it's just my device I'd consider buying another one to replace it.
Just purchased a Samsung S10 and trying to switch to Android. The last time I tried taking some picture it interrupted me with some EULA for some additional service I never wanted. UX have gone down the drain on all mobile platforms.
So when are web browsers going to start doing proper color management on CSS colors and untagged images?
I gave up on pestering them about it 10 years ago after they were largely unreceptive about the topic for several years, but it seems like it’s still a complete shitshow.
10–14 years ago I was grumpy because my laptop display had a smaller gamut than sRGB and everything looked bad (undersaturated). Then there were a few years in between where most of the displays I used were close enough to sRGB that missing color management more-or-less worked out. Now many devices have wide-gamut displays which basically make everything on the web look like oversaturated garbage.
Apple had color management more or less figured out on the Mac in the mid 1990s. It is absurd that it is still so hard for software made by gajillion-dollar companies to get the bare basics right >20 years later, especially now that we have superfast GPUs to do compositing in linear space and arbitrarily fancy gamut mapping using floating point arithmetic, brighter and wider-gamut displays, better cameras, ...
To the browser vendors: all untagged content must be assumed to be sRGB. If viewers have wider-gamut displays this content must go through a CMS. If viewers want to view wider-gamut images or other content, this must be opt-in. The current behavior breaks color on the web. (Buy a new phone or computer and suddenly nearly every color relationship you see on the web will be different than the designer’s intention.)
EDIT: That's the desktop - can't speak for the mobile version. I really hope they turn it on by default in the new mobile browser they're building. Also, thanks, I had enabled the color management a long time ago but it apparently was disabled again in a recent upgrade or something.
First of all:
Chrome still has broken color management. DisplayCAL has a way to generate profiles that look like garbage in applications which process color profiles incorrectly, and this happens with Chrome (but not Firefox.).
Besides that, even if it had feature parity with Firefox, we'd still remain stuck in the land of ICC color profiles, and those have a few issues.
I'd love to see web browsers support this modified version of this:
1) Let X = The color profile assigned to CSS #rrggbb color codes.
What is X?
2) Let Y = The color profile assigned to your display.
When X does not equal Y, which option should the browser choose for converting colorspace X to colorspace Y for display purposes?
a) Relative colormetric
b) Absolute colormetric
c) Untranslated integers
d) Other
Then,
3) Let Z = The color profile assigned to CSS HSV/LAB color codes.
What is Z? Is it the same as X?
I don't envy browser developers any aspect of this problem. If they do it right, no one will notice care. If they do it wrong, the Internet will burn them alive. I can't blame them all for being scared, but I hope that now that we've finally exited the "wild west" of "My display could have any ICC profile under the sun" and are instead approaching "My display is either sRGB or Display P3" that they will, at the very least, decide what to do and then do it and make us all adapt.
ps. If you answer question 1 with "X has no assigned color profile", then here's two extra credit questions for you:
4) Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)?
5) What is the correct CSS declaration to specify P3(r=1.0,g=0.0,b=0.0)?
pps. It looks like the CSS working groups are being pushed by both Microsoft and Apple to solve this problem, so eventually they will clearly all standardize on some way to specify colors in non-sRGB, and likely default unspecified colors to sRGB. To which I have to say, "Finally", because maybe then the one outlier will finally align with what I think is right. This is a hard problem, don't get me wrong, it's just frustrating having waited a decade for them to solve this and it's still not solved.
ppps. The answer to all of the above questions can likely be found here, once they exit the draft stage someday. The above is all designed to convey the problem in a nutshell to people who aren't familiar with the core problem. If you truly understand and care about this stuff, here you go:
“Absolute colorimetric” makes no sense in this context. So the answer is always “perceptual” or “relative colorimetric”. But that alone doesn’t really tell you what to do. A rendering intent is not a gamut mapping algorithm, and there are many possible gamut mapping algorithms.
Here’s a 300 page monograph discussing more or less the state of the art 10 years ago, https://amzn.co/0470030321
But here’s the thing... it doesn’t really matter. Their current choice is to just treat everything untagged as being in the display’s profile and do no color management. This is pretty much the worst possible choice.
The specification is very clear. Untagged colors in CSS/HTML are sRGB. Period. Doesn’t matter if they are specified as RGB or HSL coordinates (P.S. it was a huge mistake to add the latter to the web; HSL/HSV should never be used for any purpose).
Currently most of the browsers flagrantly violate the specification.
The browsers have been doing things wrong since forever. People who know anything about it have been annoyed since forever, but their feedback seems to have very little influence. Everyone else is blissfully ignorant, except for often encountering weird color bugs that they don’t understand the cause of.
> Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)?
It should appear more or less the same on both. The spec explicitly specifies that it is sRGB. Under no circustances should it be naively treated as P3. However some gamut mapping algorithms might make it slightly more colorful when going from sRGB -> P3 (without significantly altering lightness/hue relationships between colors).
> What is the correct CSS declaration to specify P3
This is something to take up with the CSS spec authors. They can add some ability to opt-in to tagging non-sRGB colors. If the spec doesn’t support it, then there is no way.
* * *
Edit: Your linked draft spec clarifies that something like relative colorimetric intent must be used. “Implementations may choose to implement these steps in some other way (for example, using an ICC profile with relative colorimetric rendering intent) provided the results are the same for colors inside the source and destination gamuts.”
So your answer about the untagged #ff0000 is that it should look pretty well identical on both displays.
Glad they are adding some facility for non-sRGB colors to CSS. Of course it wouldn’t be the W3C if they didn’t also add some useless clutter in every new spec. The “HWB” color space? Who comes up with such nonsense?
(Compare to SVG trying to add turtle graphics and Catmull–Rom splines to their path specification mini-format, for basically no reason, in the latest draft spec.)
HWB makes a lot more sense to the average human beings than HSL/LAB. You pick a fully saturated color, and then you darken or lighten it to get the precise shade of that color that you want. It’s a huge win for UI over, say, RGB (100% red and 50% green makes no sense to anyone but designers and lighting technicians). Think of it as a magical shortcut for picking HSL, but instead of picking “orange, mostly saturated, then desaturated” you’re combining those last two into a single triangle picker whose three corners are the Hue, White, and Black.
Concepts of “whiteness” and “blackness” are fine, but this “HWB” is just a trivial rearrangement of RGB, and as such has very little to do with human perception, and much more to do with the specific implementation details of the output medium.
HWB (like RGB and HSL and HSV) does not make sense to “average human beings”. It only makes sense to people who have spent years training on the specifics of RGB displays (e.g. your proposed “lighting technicians”). For everyone else it is a confusing mess which produces bad results which differ significantly from their intentions.
This is neither magical nor a shortcut. It’s a superfluous hassle that anyone who wants to implement the spec needs to implement, debug, and maintain, and anyone reading the markup for arbitrary web pages needs to know about one more weird complication.
If individual web designers want to use this idiosyncratic tool, they are welcome to put it in their page’s javascript, or add it to their CSS pre-processor. But it should not be foisted on the rest of us.
The NCS image at the link you provide above literally shows the exact three-cornered orange-white-black triangle at position -Y10R that is shown in this image, which appears to use the exact hue sequence shown in your wiki link’s animation. I’m confused why you object to it being supported. Is your objection to their use of Hue spectrum positions 0,90,180,270 (R,G,C,M) - as already implemented in CSS today - as the four saturated qualia rather than NCS’s specified four qualia positions of 0,90,180,270 (R,Y,G,B)?
It is emphatically not “literally the exact [...] triangle”.
The NCS is a similar concept, but executed based on a plausible theoretical model and (more or less) sound empirical study of human perceptual response to visual stimuli.
“HWB”, like HSL, is just someone’s trivial half-assed transformation of the RGB cube, completely ignoring more than a century of color science research. It’s what you get when a person off the street were tasked with redefining the NCS, without understanding it. It reminds me of people’s bicycle sketches, http://www.gianlucagimini.it/prototypes/velocipedia.html
Personally I am not the biggest fan of the NCS system for designating colors; I find Munsell-like coordinate systems to work better for me, in practice. But at least it has some kind of theoretical and empirical basis.
CSS, having already standardized on Munsell hue circles (page 5) in the past, appears content to continue forward with them as the hue circle of choice for HWB. While I respect that you would prefer to see them use the NSL hue circle (pages 10-11), it appears that they are unlikely to do so at this time.
One bonus find here is the abstract for the cited Whitfield (1988) paper, where the paper's authors attempted to replicate the assertion that NSL is better than Munsell, and failed:
The study reported here is a replication of experiments cited as support for this claim. Subjects were trained in the NCS using NCS training material and carried out colour‐identification tasks. For comparison, a further subject group was trained in the Munsell system and carried out identical tasks. The results indicated (a) a lower level of accuracy than previously reported for those subjects trained in the NCS and (b) little difference in performance between the NCS‐ and Munsell‐trained groups.
CSS has nothing to do with Munsell hues or NCS hues. I have no idea what you mean by “NSL”.
The “HSL” / “HWB” hue circle is just a trivial transformation of the RGB cube (namely: zigzag along the 6 most colorful edges of the cube at constant speed), designed by non-color-expert computer programmers based on what was convenient to implement on workstation computers from the late 1970s (note: these considerations are not relevant 40 years later), and has almost nothing to do with human perception.
It is nowhere near perceptually uniform (unlike the goals of Munsell hues), and also does not have human-perception-meaningful landmarks like the NCS cardinal directions.
If you follow a circle of constant “W” and “B” in the “HWB” model, at constant speed in terms of “H”, then a typical human observer will see wildly varying “lightness”, “colorfulness”, “saturation”, “whiteness”, “blackness” with respect to their own perception, and will see perceived hue change at highly irregular and unsmooth speed.
And this (read the Appendix on the BACKLIGHT of the Sharp Quattron, and take a look at Figures 1.3, 3.5, 9.2, G.3!):
Note however, that all of this completely ignores the fact that humans seem capable of some form of HDR color fusion via binocular vision, as impressively demonstrated in this paper:
Given that many people seem to report slight differences in monochromatic color differentiating between eyes, we can speculate that binocular vision influences color perception in some way.
But frankly using CIECAM02 or CAM16 (or whatever) vs. CIELAB for doing gamut mapping is a relatively minor improvement in most cases. There can be serious issues when trying to convert RGB images to CMYK or similar for printing, especially hue shifts in the blue–purple region. But for converting colors from sRGB to a wider-gamut display there shouldn’t be any significant issue.
The big problem is that historically most browsers have done no color management of CSS colors. Looks like that is now changing, which is encouraging, whether or not the gamut mapping algorithm they use is state-of-the-art.
> ignores the fact that humans seem capable of some form of HDR color fusion
This seems largely irrelevant to the discussion in this thread.
Nice, thanks for sharing! You seem to work on a lot of stuff I find highly interesting! :) entirely off topic, but, you might find this of interest to your logarithmic spirals work:
>But for converting colors from sRGB to a wider-gamut display there shouldn’t be any significant issue.
I agree, but I'd prefer it if eventually, we treated sRGB colors the same way we treat CGA colors. Especially due to the issues outlined in the other paper I linked. (Namely, that our 'red' subpixels ain't red, they're more orange-red, and that the 'green' ones ain't green either, they're more yellow-green. Really a shame Sharp messed up their tech in that regard by just using a standard back-light, it put a huge blemish in the quite sane idea of having yellow subpixels.)
But, at the moment, we don't even have Chrome properly supporting ICCv4 profiles, so, those dreams of the far future will have to wait.
>This seems largely irrelevant to the discussion in this thread.
>largely
Yes, I agree, I placed it there as a note of caution about:
1. Limitations in the works linked to;
2. The fact that color science doesn't seem to account for stereoblindness and monocular vs. binocular stimulii more often than not;
that's all.
That's also why I linked that PhD dissertation, which also goes beyond CAM16. I in fact neglected to mention some other limitations, namely, that it also doesn't fully factor in:
1. The works on color perception by Brian P. Schmidt¹ et al.: https://bps10.github.io/ (Note: It does factor it in /in part/)
¹ NOT the Brian P. Schmidt who won part of the 2011 Physics Nobel price
Edit: Almost entirely off-topic, but, I try to keep my thematically related Hacker News comments at least indirectly hyperlinked to each other, so, here, another color related comment:
This post’s replies are a joy to read, as someone who’s been finding and reporting bugs in wide color pipelines for over a decade. You all are encountering completely bog standard normal ICC issues with eyes wide open for the first time and it’s given me a lot of hope for the next five years.
App authors and OS builders have refused for a long time to make this a priority - I’m looking at you, Slack - and now finally with both iOS and Android moving forward, I really hope it’ll be enough to finally force them all to suck it up and implement proper ICC handling.
Truly sRGB has been the best and worst thing to happen to color on computers. Unfortunately there's so much misinformation and bad implementations of color out there that I doubt end-users will ever understand or even notice problems as they come up. I'm really hoping that HDR support will be the driving force behind wide-color adoption, since consumers are more likely to notice when HDR isn't working.
After switching to a recent Macbook Pro and making sure it's displaying a wider color gamut (the Android image shows up), I compared the sample images - and didn't see the difference at first.
After reading the description, I can see that the colors are a little brighter.
But, now that I can see it, I can't bring myself to care. I'd rather forget about it. This won't make my life any better. It's just a way to sell more expensive hardware, much like audiophile gear.
It's the law of diminishing return. We went from "absolute shitty" screens to "very good" screens in 40 years, and from then we went from "very good" to "very good but slightly better if you squint your eyes really hard" in 10 years.
It's the same for most consumer tech, and is very noticeable on phones/tablets/laptops. The only thing we can improve on is shaving of .25mm every gen and calling it a revolution. Or adding machine learning + a 8k screen to our smartphones to explain why you need to spend 1000$+ on a 10 core cpu and 8gb of ram.
The complexity skyrockets, the price doubles but the user experience barely changes, and sometimes it's not even a positive change. Because at the end of the day the vast majority of people just want a basic camera, spotify, netflix and google maps.
2011 iMac display I can't see the logo, but if I drag the Chrome tab over to a connected ViewSonic VA2431wm monitor from years ago, the logo shows up. Interesting.
It might be included only in the Android Q update.
Googling around shows that it might be restricted to custom apps only?
"There is one way to bypass this issue, and that is to explicitly tell Chrome to override the default provided system colour profile and just tell it the display is Display P3. This enables colour management in the app, and short of writing a custom application, is the only way to get wide colour gamut content to work on the Pixel 3."
So this is interesting... I did this, and it only shows up in the preview/thumbnail view. Once I click on the thumbnail tile to view the image in full screen, it goes back to flat red with no logo.
I'm not getting that - in Photos, looking at the full size flat-red version, and taking a screenshot, I don't see the logo flash at any time during that process. Nor on the edges when I resize.
Augh. Bizarre. Oh, do you have the "pop-up" overlay with icons for share, filters, etc. visible? (The one which appears when you tap the image.)
On my Pixel 3 XL, the behaviors I described occur, and also the logo is invisible unless the overlay is shown (in which case it's drawn only near the edges, unless you're taking a scree...oh.
I get it.
Image math is getting done internally in a wide gamut. Including alpha blending. But it's converted to sRGB before being displayed.
The things I described all, I suspect, modify the image- mostly by just dimming it, and the resulting dimmed wide color values map to different sRGB colors (where the undimmed colors all map to the same shade of red.)
I have a hunch that the internal management of the image by the application you've described is similar to the case of another comment where the logo could be seen in Windows after saving the file in MS Paint.
it's entirely possible that the preview compresses the color space in just the right way to show the separation. reducing colors can shrink image sizes quite a lot.
as to what's actually happening: not a clue! just pointing out possibilities :)
PNGs are saved as sRGB by default, and so the differences aren't remapped away by the OS like they would be if the PNG was saved with a wider color space.
wait so if you screenshotted that.. what ends up saved in the PNG? Does the image clipboard now automatically have 2 versions of any screenshot; a wide colour version and some sort of normalised 8 bit version?
I'm looking at this from a macbook pro 2015 so I assume no wide colour support (?), yet I see the logo. Which conversion, at which step, caused that effect?
I see the same thing in both Firefox and Safari, on a non-P3 display: the original image is solid red, but the copied image shows the logo. So it looks like a conversion did actually happen at some point.
The transform to display the "solid red" block is actually the post-transformed data. The clipboard (rightfully) is carrying the original source buffer.
The issue would be the mechanics of the copy (attaching metadata) and pasting (interpreting the metadata in conjunction with the source image buffer.)
So technically, no, there's no conversion on the source data, it's the representation in the pasted context that's the issue.
Fyi, never, ever use a monitor/TV in "vivid" setting. It sets the brightness, contrast and backlight settings to absurd values and clips a whole bunch of colors on the low and high luminance ranges resulting in a severely restricted dynamic range. A byproduct of this is that regular images appear super saturated and "vivid". Also, if you have an OLED or Plasma, vivid mode will almost certainly accelerate screen burn-in (I've even seen this happen on LCD TVs).
Actually I'm a hobby photographer, and I generally favor accurate color representation over any other special color modes. I do remember playing around with the settings when I got my phone and I think I just forgot to switch the color mode back to normal from vivid.
On my Mi 8 it works fine in Firefox, the default gallery app doesn't show it at all, and Google Photos shows it in the gallery view but not full screen. Oops...
If you are on a Mac, try changing your color profile in System Preferences | Displays | Color to something like 'Adobe RGB' or 'Display P3'. That allowed me to see the logo, as for a difference in the photos in the original post, not so much...
curiously enough, if I display this logo inside the firefox browser it is invisible (just a red square).
However, donwloading the png file and opening it on any image viewer it shows two different shades of red. I guess firefox is applying a silly color contrast change to its images before displaying them.
Just to add my own observations (Ubuntu Disco, FF 66) - it's also solid red for me in Firefox, but if I download it I can see the Android image in the preview in Gnome's file browser. If I open it up in Ubuntu / Gnome's "Image Viewer" application it's solid red, but works fine in Shotwell.
It's also solid red in GIMP 2.10, which surprised me.
On my Linux desktop, firefox, it's solid red. On my OnePlus 5T phone, it's solid red in Chrome, but an android logo in Firefox.
Ah, if I download the file I see the logo with eom (eye of mate), though it's much less obvious than on the phone.
It seems like others are having similar results. Some image libraries seem to be reducing the color space and changing the values. It could be an issue of P3 aware vs P3 capable. But I’m not entirely sure why it’s so hit or miss.
On my Surface Go, it's solid red in Chrome and (surprisingly) Affinity Photo, but not Paint. I'm surprised that Paint has better support for this than a paid photo editing app.
There is a bug there. You should be seeing a completely red image. Somewhere in your copy/paste step either (a) the color profile is being stripped out, or (b) the software you use to view the image is not properly respecting the color profile.
I believe both A and B are at work; it's probably a direct copy of the input buffer without metadata making B likely impossible, if it were trying at all, which I'll speculate isn't even a possibility.
I’m not sure that clipboard implementations provide ancillary metadata? Nor would it be interpreted given the wild-west application development model where application developers are the folks who would need to implement support?
It is definitely possible to copy/paste images on the Mac while preserving image metadata. That behavior should be the default. If this is broken when copying between two Apple-provided applications then that is definitely a bug.
I am glad to see my desktop machine isn't being left behind with this. In stock LTS Ubuntu the default image viewer shows the Display P3 images as does Firefox. The thumbnail in the file browser also has the logo showing.
Not sure about Chrome as I set the color flags to be sRGB a long time ago as, compared to Firefox, colours in Chrome are unsatisfactory on Linux.
I also tried on a consumer grade laptop that runs the latest (19.04) Ubuntu with one of those glossy screens, definitely not designed for Display P3. This failed in Firefox, Chrome, Gimp but the thumbnail in the file browser came good. How come when the hardware isn't there for it?
It seems like 25% of the colours are missing with a lot of that being green, green being quite an important colour. It must be possible to have some creative fun with this. If you can get images that only kids can see on their phones but adults not see on their boring PCs then you could have some variant of 'satanic backmasking' going on.
'Satanic backmasking' was where you could hear stuff about Satan on Beatles records if you played them backwards, listening whilst stoned. Politicians bothered themselves about young minds being corrupted by such things back in the day.
Maybe DCI-P3 images can court a similar controversy, shame April Fools Day is a lame day of corporate gags where nobody is fooled, otherwise DCI-P3 is ripe for moral panic, terrorising the adults with another thing for them to get their politicians frenzied about.
I hope Chrome gets to do colour a bit better, to Firefox standards. Otherwise we will be with half the world's screens not showing all the colours. Although not the same gap as between colour and monochrome, it is a huge difference to anyone that works with colour and needs subtle colour variations.
Does anyone know of any popular camera image formats (ie not raw) that are actually using more than 8 bits per color?
The blog post mentions "8 bits per color channel is not enough", but as far as I can tell everyone using Display P3 for consumer-grade photos (including the iPhone) is still using 8 bits per color, just over the wider gamut.
It seems weird that this hasn't become a thing with the big marketing push behind HDR10 and others for TV. You might think "backwards compatibility", but Apple was fine making the HEIF break and converting when sharing with incompatible devices.
It's not entirely about bit depth. Think about 1 bit of a given colour light, it can turn on or off, but the bit depth doesn't tell us anything about the colour of the light it is turning on or off.
Encoding in a larger volume colour space may require additional bit depth to prevent posterization, but that's somewhat tangential. The larger issue is the number of vendors and operating systems that can't get it right. Windows is horrific, for example, with Android being at least as bad, as given by the accounts in the comments here.
Are you trying to post the same thing in every top-level thread to get your comment seen? This has nothing to do with what I was asking, which was pretty much "everything about gamut and display aside, what's the deal with bit depth?". Hopefully you can see how your response is a distraction.
Nobody to my knowledge is using more than 8 bits per color for taking photos. Certainly nobody using JPG (which includes wide-gamut JPEGs from DSLRs), and at least right now not even HEIF on iOS is anything but 8 bits. I'm guessing because it hasn't caused much color-banding for the typical use case (photos) anyways.
Sony ARW is 14 bits on the A7 line. Canon 5D Mark IV RAW is 14 bit and so is the Nikon counterpart. Even the cheap Blackmagic Pocket Cinema Camera shoots 12 bit RAW.
Why is this important? Most of these cameras images end up on the web. VP9, HEVC and HEIC all support HDR10 so with the right processing this should come through.
JPEG is actually ~12 bits deep, it's just that all the decoders decode it to 8 bit YCbCr, and on top of that cause extra loss by 8-bit YCbCr->RGB conversion. It's possible to compile libjpeg with a 16-bit color pipeline, but it's a hassle, so nobody does that.
Haven't looked at the image too deeply, but this is likely the rendering intent being set so something other than the colorimetric offerings, such as Perceptual or Saturation. It could also be a poorly encoded image as well.
Looks like iPhone XS already has support for wide gamut. I can see Android logo on red image on Safari as well as Chrome on XS but I can see it bit less bright on sRGB monitors also.
> And have properly set up colour management working, which on Windows is close to zero percent probability.
Maybe surprising to some, but Windows actually supports HDR10 (which includes "wide-gamut" color) better than other OSes. You can, for example, play HDR10 video games with a connected HDR-capable monitor. It might be thanks to MS's Xbox platform.
I am confused about why I can see this screenshot since I am not on a wide gamut monitor. Is firefox doing a weird conversion or the screenshotting tool?
My (probably flawed) understanding was that wide colors means there's more than 8 bits. So stuff that would be say rgb(254.5, 0, 0) would now be distinguishable from rgb(255, 0, 0)? If you screenshotted it back to 8 bit you would just lose the extra bits and I expected to still see a red square? Or is that not how it works?
Yes flawed. If you have a bitmap that's using a wide color space (e. g. P3/OLED) and it has a green (0,1,0) pixel then that's referring to a color than an LCD display cannot possibly show. 0,1,0 on an LCD is a less saturated green. The OS changes color values to try to make things look as much as expected as possible, and that results in color clipping. A screenshot saves images as sRGB and so no remapping is done upon display.
I just set the Chrome flag to force the display profile and was able to see the image on my Pixel 3a. The default profile will not show it.
So Chrome is using the APIs, but actually using that profile is still behind a feature flag, it seems.
Edit: I just tried it in Firefox and the log is much clearer. This makes me think that Firefox is doing something to change the image before displaying it, which is why it "works" there.
A lot of variables involved. For me Win 10 17134, with an NVidia GTX 960, over displayport to Dell U2417H, I can see the two colors in Chrome and Firefox. I can't see the color difference in Microsoft Edge.
The ICC Profile for the monitor was automatically loaded by Windows. Everything is 32 bit.
I think the ICC profile is the only reason I can see it and it isn't a very strong difference on my monitor.
Edit: When I say 32bit, I mean 8 bit per RGB channel/24 bit "True Color"
I really just want Android to stop messing with the camera and let it take pictures. It's getting harder to take a photo without it stripping all the texture from people's faces and blurring out the background, or worse.
Here's a video of me moving around on a static background, taken from a tripod. Evidently bending the fabric of the universe as I move:
https://www.youtube.com/watch?v=qSlgOwm_eXU
That's the stock camera app on my brand new Pixel 3a. Since this was taken, I've been experimenting with every setting possible to try to convince it that I don't want to "pop" or be "motion stabilized" but no, there's nothing that will stop it doing this.
I'm going to have to return the phone.
What you are asking is certainly reasonable but may be technically impossible to achieve. It is probably not android but the camera hardware itself that does a large part of this processing.
The reason that today's cameras on phones look so much better than those of 10 years ago (especially for static photos) is due to advanced methods of image processing. The information available to the image is limited by the diffraction of the lens and by the thermal noise of the captor, and these are two physical constraints that can not be loosened. Thus, any increase of resolution is due to heavy image processing, that denoises and de-blurs the images so that they look as if they were better than they can actually be acquired by this captor. This is an ill posed problem since denoising and deblurring essentially act in opposite directions! The solution to this problem inevitably goes through projecting the low amount of information that you have into an image model of higher resolution. This necessarily leads to artifacts in some cases.
For the case of video, the motion artifacts that you observe in the rocks are often due to video compression and the correction of camera shake. The first is done in hardware so there's not much that you can do about it. The correction of camera shake may have a software part that you may be able to disable. Have you tried different camera apps?
Yeah wow, that's pretty bad. It looks like it thinks you are the thing that should be stationary and it's stabilizing the rocks with you as the reference point. Nice climbing by the way!
In the same vein I wish that Google would just let me view all the photos I had taken on my phone.
I almost exclusively use the "Camera" Album in the Photos app on my Pixel 2, but some update seemed to irreversibly back up and delete most (but not all?) of my photos. Now when trying to view all these backed up photos online (as there doesn't seem to be a way to get them back onto my phone) the feed is polluted with other random images from Whatsapp, etc. with no way to filter any of them out. And now I can't easily show anyone anything I took on my phone from a few months ago!
It's annoying because I quite like the Pixel 2 camera, but definitely agree with you that it should have more "dumb" options.
My guess would be that this is a video compression artifact, not a deliberate image enhancement effect.
Though that doesn't help when you can't adjust the quality.
The odd thing is that a given piece of unrelated rock will be in perfect focus, then suddenly go blurry when I get near it (but not so near as to cast a shadow).
If it were video compression, you'd expect it would try to not alter pixels that didn't change from frame to frame. But it clearly updates large swathes of them.
Also, changing the compression mode in the camera from h.264/AVC to H/265.HEVC doesn't fix it.
As far as I know, video compression works on areas, not just pixels. To me, it looks like it's trying to update areas of the photo by moving areas of pixels, instead of just updating them individually. This is accidentally getting more than just the part that's moving, and making things nearby seem to move as well.
For instance, in the video provided in another comment, when the climber swings his legs up a bit, there's a portion of the wall that stretches behind him, before eventually un-stretching back into place. It flows behind the moving limbs. I suspect that if good video were taken of the scene, the leg would also be somewhat distorted while moving, but we can't really tell because it's supposed to be changing, unlike the rocks.
The 3a supports three video capture modes: UHD 4K (30 fps), HD 1080p, and HD 720p.
It would be useful to know which mode was used and if this occurs in more than one of them.
My armchair guess is that the 3a isn't powerful enough to capture 4K without creating compression artifacts.
But if 1080p is "good enough" I would say that's going to be the 3a's story - just don't use the most taxing settings.
I only tested in 1080p. Most tests were at 30fps but i did a couple at 60fps to verify that that didn’t fix it.
720 would be unacceptable for a camera in 2019, so I didn’t try.
I’ve already initiated the return with google and printed the shipping label. Guess I’m on the market for a new phone if anybody has a suggestion.
Have you tried using a different camera app? e.g. Open Camera
I would recommend the same, although I can imagine it might not properly support the latest Pixel 3A yet.
This is really odd. I am going to run some tests on my own Pixel 3a and see if I can replicate it. Seems stupid.
I spent the morning with the Open Camera app, standing in front of the stone wall of my garage and waving my arm slowly, trying to find a setting that didn't cause this effect.
No luck thus far. I can make it slightly less noticeable, or glaringly obvious. But I can't get rid of it.
Please let me know if you can (or better still can't) replicate it. I'm returning the phone tomorrow, but if it's just my device I'd consider buying another one to replace it.
Just purchased a Samsung S10 and trying to switch to Android. The last time I tried taking some picture it interrupted me with some EULA for some additional service I never wanted. UX have gone down the drain on all mobile platforms.
That's so weird. Do you know if this is unique to the 3a?
I posted this to /r/GooglePixel when I first noticed it, and at least one other person confirmed it was happening with their phone too.
I haven't found anything about anybody having the same issue on a regular Pixel 3.
That is very annoying to watch. What is it trying accomplish?
I watched your video but still couldn't see any particular issue like distortions or apparent problems.
Try full screen on a desktop. Watch the texture on the rock near the left hand and hip.
It’s not really noticeable on a phone unless you zoom in, but impossible to miss on a big screen.
So when are web browsers going to start doing proper color management on CSS colors and untagged images?
I gave up on pestering them about it 10 years ago after they were largely unreceptive about the topic for several years, but it seems like it’s still a complete shitshow.
10–14 years ago I was grumpy because my laptop display had a smaller gamut than sRGB and everything looked bad (undersaturated). Then there were a few years in between where most of the displays I used were close enough to sRGB that missing color management more-or-less worked out. Now many devices have wide-gamut displays which basically make everything on the web look like oversaturated garbage.
Apple had color management more or less figured out on the Mac in the mid 1990s. It is absurd that it is still so hard for software made by gajillion-dollar companies to get the bare basics right >20 years later, especially now that we have superfast GPUs to do compositing in linear space and arbitrarily fancy gamut mapping using floating point arithmetic, brighter and wider-gamut displays, better cameras, ...
To the browser vendors: all untagged content must be assumed to be sRGB. If viewers have wider-gamut displays this content must go through a CMS. If viewers want to view wider-gamut images or other content, this must be opt-in. The current behavior breaks color on the web. (Buy a new phone or computer and suddenly nearly every color relationship you see on the web will be different than the designer’s intention.)
You can enable it in Firefox, but it's not on by default IIRC.
https://cameratico.com/guides/firefox-color-management/
EDIT: That's the desktop - can't speak for the mobile version. I really hope they turn it on by default in the new mobile browser they're building. Also, thanks, I had enabled the color management a long time ago but it apparently was disabled again in a recent upgrade or something.
That only takes us so far.
First of all: Chrome still has broken color management. DisplayCAL has a way to generate profiles that look like garbage in applications which process color profiles incorrectly, and this happens with Chrome (but not Firefox.).
Besides that, even if it had feature parity with Firefox, we'd still remain stuck in the land of ICC color profiles, and those have a few issues.
I'd love to see web browsers support this modified version of this:
https://arxiv.org/abs/1802.06067
For which an implementation exists, here:
https://github.com/nschloe/colorio
…but no operating systems and hence no browsers support it.
Edit:
See also my comment here: https://news.ycombinator.com/item?id=19983604
> I'd love to see web browsers support this modified version of this
I hear you, but at the same time this relevant xkcd comes to mind:
https://xkcd.com/927/
Colorio looks great, thanks for the link! Also has Jzazbz support I see, neat!
1) Let X = The color profile assigned to CSS #rrggbb color codes.
What is X?
2) Let Y = The color profile assigned to your display.
When X does not equal Y, which option should the browser choose for converting colorspace X to colorspace Y for display purposes?
a) Relative colormetric b) Absolute colormetric c) Untranslated integers d) Other
Then,
3) Let Z = The color profile assigned to CSS HSV/LAB color codes.
What is Z? Is it the same as X?
I don't envy browser developers any aspect of this problem. If they do it right, no one will notice care. If they do it wrong, the Internet will burn them alive. I can't blame them all for being scared, but I hope that now that we've finally exited the "wild west" of "My display could have any ICC profile under the sun" and are instead approaching "My display is either sRGB or Display P3" that they will, at the very least, decide what to do and then do it and make us all adapt.
ps. If you answer question 1 with "X has no assigned color profile", then here's two extra credit questions for you:
4) Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)?
5) What is the correct CSS declaration to specify P3(r=1.0,g=0.0,b=0.0)?
pps. It looks like the CSS working groups are being pushed by both Microsoft and Apple to solve this problem, so eventually they will clearly all standardize on some way to specify colors in non-sRGB, and likely default unspecified colors to sRGB. To which I have to say, "Finally", because maybe then the one outlier will finally align with what I think is right. This is a hard problem, don't get me wrong, it's just frustrating having waited a decade for them to solve this and it's still not solved.
ppps. The answer to all of the above questions can likely be found here, once they exit the draft stage someday. The above is all designed to convey the problem in a nutshell to people who aren't familiar with the core problem. If you truly understand and care about this stuff, here you go:
CSS Color Module Level 4, W3C Working Draft, 5 March 2019: https://www.w3.org/TR/css-color-4/#predefined
“Absolute colorimetric” makes no sense in this context. So the answer is always “perceptual” or “relative colorimetric”. But that alone doesn’t really tell you what to do. A rendering intent is not a gamut mapping algorithm, and there are many possible gamut mapping algorithms.
Here’s a 300 page monograph discussing more or less the state of the art 10 years ago, https://amzn.co/0470030321
But here’s the thing... it doesn’t really matter. Their current choice is to just treat everything untagged as being in the display’s profile and do no color management. This is pretty much the worst possible choice.
The specification is very clear. Untagged colors in CSS/HTML are sRGB. Period. Doesn’t matter if they are specified as RGB or HSL coordinates (P.S. it was a huge mistake to add the latter to the web; HSL/HSV should never be used for any purpose).
Currently most of the browsers flagrantly violate the specification.
The browsers have been doing things wrong since forever. People who know anything about it have been annoyed since forever, but their feedback seems to have very little influence. Everyone else is blissfully ignorant, except for often encountering weird color bugs that they don’t understand the cause of.
> Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)?
It should appear more or less the same on both. The spec explicitly specifies that it is sRGB. Under no circustances should it be naively treated as P3. However some gamut mapping algorithms might make it slightly more colorful when going from sRGB -> P3 (without significantly altering lightness/hue relationships between colors).
> What is the correct CSS declaration to specify P3
This is something to take up with the CSS spec authors. They can add some ability to opt-in to tagging non-sRGB colors. If the spec doesn’t support it, then there is no way.
* * *
Edit: Your linked draft spec clarifies that something like relative colorimetric intent must be used. “Implementations may choose to implement these steps in some other way (for example, using an ICC profile with relative colorimetric rendering intent) provided the results are the same for colors inside the source and destination gamuts.”
So your answer about the untagged #ff0000 is that it should look pretty well identical on both displays.
Glad they are adding some facility for non-sRGB colors to CSS. Of course it wouldn’t be the W3C if they didn’t also add some useless clutter in every new spec. The “HWB” color space? Who comes up with such nonsense?
(Compare to SVG trying to add turtle graphics and Catmull–Rom splines to their path specification mini-format, for basically no reason, in the latest draft spec.)
HWB makes a lot more sense to the average human beings than HSL/LAB. You pick a fully saturated color, and then you darken or lighten it to get the precise shade of that color that you want. It’s a huge win for UI over, say, RGB (100% red and 50% green makes no sense to anyone but designers and lighting technicians). Think of it as a magical shortcut for picking HSL, but instead of picking “orange, mostly saturated, then desaturated” you’re combining those last two into a single triangle picker whose three corners are the Hue, White, and Black.
Concepts of “whiteness” and “blackness” are fine, but this “HWB” is just a trivial rearrangement of RGB, and as such has very little to do with human perception, and much more to do with the specific implementation details of the output medium.
HWB (like RGB and HSL and HSV) does not make sense to “average human beings”. It only makes sense to people who have spent years training on the specifics of RGB displays (e.g. your proposed “lighting technicians”). For everyone else it is a confusing mess which produces bad results which differ significantly from their intentions.
If you want a color model related to NCS, specify something which properly follows its principles. https://en.wikipedia.org/wiki/Natural_Color_System
> magical shortcut
This is neither magical nor a shortcut. It’s a superfluous hassle that anyone who wants to implement the spec needs to implement, debug, and maintain, and anyone reading the markup for arbitrary web pages needs to know about one more weird complication.
If individual web designers want to use this idiosyncratic tool, they are welcome to put it in their page’s javascript, or add it to their CSS pre-processor. But it should not be foisted on the rest of us.
The NCS image at the link you provide above literally shows the exact three-cornered orange-white-black triangle at position -Y10R that is shown in this image, which appears to use the exact hue sequence shown in your wiki link’s animation. I’m confused why you object to it being supported. Is your objection to their use of Hue spectrum positions 0,90,180,270 (R,G,C,M) - as already implemented in CSS today - as the four saturated qualia rather than NCS’s specified four qualia positions of 0,90,180,270 (R,Y,G,B)?
HWB: https://commons.wikimedia.org/wiki/File:GTK_color_chooser.pn...
NCS: https://commons.wikimedia.org/wiki/File:Animation_of_the_NCS...
It is emphatically not “literally the exact [...] triangle”.
The NCS is a similar concept, but executed based on a plausible theoretical model and (more or less) sound empirical study of human perceptual response to visual stimuli.
“HWB”, like HSL, is just someone’s trivial half-assed transformation of the RGB cube, completely ignoring more than a century of color science research. It’s what you get when a person off the street were tasked with redefining the NCS, without understanding it. It reminds me of people’s bicycle sketches, http://www.gianlucagimini.it/prototypes/velocipedia.html
Personally I am not the biggest fan of the NCS system for designating colors; I find Munsell-like coordinate systems to work better for me, in practice. But at least it has some kind of theoretical and empirical basis.
This paper from a few years ago compares various mathematical definitions of "hue" that have been popular over the past few decades.
https://pdfs.semanticscholar.org/7833/f96c09a1201f0e7f54e0de...
CSS, having already standardized on Munsell hue circles (page 5) in the past, appears content to continue forward with them as the hue circle of choice for HWB. While I respect that you would prefer to see them use the NSL hue circle (pages 10-11), it appears that they are unlikely to do so at this time.
One bonus find here is the abstract for the cited Whitfield (1988) paper, where the paper's authors attempted to replicate the assertion that NSL is better than Munsell, and failed:
https://onlinelibrary.wiley.com/doi/10.1002/col.5080130210
The study reported here is a replication of experiments cited as support for this claim. Subjects were trained in the NCS using NCS training material and carried out colour‐identification tasks. For comparison, a further subject group was trained in the Munsell system and carried out identical tasks. The results indicated (a) a lower level of accuracy than previously reported for those subjects trained in the NCS and (b) little difference in performance between the NCS‐ and Munsell‐trained groups.
What are you talking about?
CSS has nothing to do with Munsell hues or NCS hues. I have no idea what you mean by “NSL”.
The “HSL” / “HWB” hue circle is just a trivial transformation of the RGB cube (namely: zigzag along the 6 most colorful edges of the cube at constant speed), designed by non-color-expert computer programmers based on what was convenient to implement on workstation computers from the late 1970s (note: these considerations are not relevant 40 years later), and has almost nothing to do with human perception.
It is nowhere near perceptually uniform (unlike the goals of Munsell hues), and also does not have human-perception-meaningful landmarks like the NCS cardinal directions.
If you follow a circle of constant “W” and “B” in the “HWB” model, at constant speed in terms of “H”, then a typical human observer will see wildly varying “lightness”, “colorfulness”, “saturation”, “whiteness”, “blackness” with respect to their own perception, and will see perceived hue change at highly irregular and unsmooth speed.
Y'all might want to read this:
https://arxiv.org/abs/1802.06067
(Implementation: https://github.com/nschloe/colorio )
And this (read the Appendix on the BACKLIGHT of the Sharp Quattron, and take a look at Figures 1.3, 3.5, 9.2, G.3!):
Note however, that all of this completely ignores the fact that humans seem capable of some form of HDR color fusion via binocular vision, as impressively demonstrated in this paper:
http://arxiv.org/abs/1703.04392
Given that many people seem to report slight differences in monochromatic color differentiating between eyes, we can speculate that binocular vision influences color perception in some way.
Edit:
See also my comment here: https://news.ycombinator.com/item?id=19983432
My implementation from a few weeks ago https://observablehq.com/@jrus/cam16
(Make sure you watch for typos in your link.)
But frankly using CIECAM02 or CAM16 (or whatever) vs. CIELAB for doing gamut mapping is a relatively minor improvement in most cases. There can be serious issues when trying to convert RGB images to CMYK or similar for printing, especially hue shifts in the blue–purple region. But for converting colors from sRGB to a wider-gamut display there shouldn’t be any significant issue.
The big problem is that historically most browsers have done no color management of CSS colors. Looks like that is now changing, which is encouraging, whether or not the gamut mapping algorithm they use is state-of-the-art.
> ignores the fact that humans seem capable of some form of HDR color fusion
This seems largely irrelevant to the discussion in this thread.
>My implementation from a few weeks ago >https://observablehq.com/@jrus/cam16
Nice, thanks for sharing! You seem to work on a lot of stuff I find highly interesting! :) entirely off topic, but, you might find this of interest to your logarithmic spirals work:
https://link.springer.com/article/10.1007/s00004-015-0285-1
>But for converting colors from sRGB to a wider-gamut display there shouldn’t be any significant issue.
I agree, but I'd prefer it if eventually, we treated sRGB colors the same way we treat CGA colors. Especially due to the issues outlined in the other paper I linked. (Namely, that our 'red' subpixels ain't red, they're more orange-red, and that the 'green' ones ain't green either, they're more yellow-green. Really a shame Sharp messed up their tech in that regard by just using a standard back-light, it put a huge blemish in the quite sane idea of having yellow subpixels.)
But, at the moment, we don't even have Chrome properly supporting ICCv4 profiles, so, those dreams of the far future will have to wait.
>This seems largely irrelevant to the discussion in this thread.
>largely
Yes, I agree, I placed it there as a note of caution about:
1. Limitations in the works linked to;
2. The fact that color science doesn't seem to account for stereoblindness and monocular vs. binocular stimulii more often than not;
that's all.
That's also why I linked that PhD dissertation, which also goes beyond CAM16. I in fact neglected to mention some other limitations, namely, that it also doesn't fully factor in:
1. The works on color perception by Brian P. Schmidt¹ et al.: https://bps10.github.io/ (Note: It does factor it in /in part/)
2. More esoterically (by which I DON'T mean pseudoscientific.) the ones noticed by John Medeiros: https://www.youtube.com/watch?v=4Oj0hweYE00
¹ NOT the Brian P. Schmidt who won part of the 2011 Physics Nobel price
Edit: Almost entirely off-topic, but, I try to keep my thematically related Hacker News comments at least indirectly hyperlinked to each other, so, here, another color related comment:
https://news.ycombinator.com/item?id=20008969
NSL is a typo for NCS.
This post’s replies are a joy to read, as someone who’s been finding and reporting bugs in wide color pipelines for over a decade. You all are encountering completely bog standard normal ICC issues with eyes wide open for the first time and it’s given me a lot of hope for the next five years.
App authors and OS builders have refused for a long time to make this a priority - I’m looking at you, Slack - and now finally with both iOS and Android moving forward, I really hope it’ll be enough to finally force them all to suck it up and implement proper ICC handling.
Truly sRGB has been the best and worst thing to happen to color on computers. Unfortunately there's so much misinformation and bad implementations of color out there that I doubt end-users will ever understand or even notice problems as they come up. I'm really hoping that HDR support will be the driving force behind wide-color adoption, since consumers are more likely to notice when HDR isn't working.
After switching to a recent Macbook Pro and making sure it's displaying a wider color gamut (the Android image shows up), I compared the sample images - and didn't see the difference at first.
After reading the description, I can see that the colors are a little brighter.
But, now that I can see it, I can't bring myself to care. I'd rather forget about it. This won't make my life any better. It's just a way to sell more expensive hardware, much like audiophile gear.
It's the law of diminishing return. We went from "absolute shitty" screens to "very good" screens in 40 years, and from then we went from "very good" to "very good but slightly better if you squint your eyes really hard" in 10 years.
It's the same for most consumer tech, and is very noticeable on phones/tablets/laptops. The only thing we can improve on is shaving of .25mm every gen and calling it a revolution. Or adding machine learning + a 8k screen to our smartphones to explain why you need to spend 1000$+ on a 10 core cpu and 8gb of ram.
The complexity skyrockets, the price doubles but the user experience barely changes, and sometimes it's not even a positive change. Because at the end of the day the vast majority of people just want a basic camera, spotify, netflix and google maps.
That android logo is a cool use of Wide Gamut and an easy test on a display.
https://2.bp.blogspot.com/-LqRniYeVeEk/XOLYEiOcKCI/AAAAAAAAJ...
If on a Pixel 3 or Samsung Galaxy S10 or another P3 capable display, it's a faint-but-visible red logo. Otherwise it's just solid red.
Edit: If not on Android Q, try using Firefox.
There seem to be some odd behavior depending on the software and this may not be always consistent.
2011 iMac display I can't see the logo, but if I drag the Chrome tab over to a connected ViewSonic VA2431wm monitor from years ago, the logo shows up. Interesting.
2011 iMac doesn’t have a P3 display iirc, but ViewSonic certainly had models that could back then.
I'm on a Pixel 3. It's just solid red - no faint logo.
Odd. I'm on an iPhone XS and it's working for me.
It might be included only in the Android Q update.
Googling around shows that it might be restricted to custom apps only?
"There is one way to bypass this issue, and that is to explicitly tell Chrome to override the default provided system colour profile and just tell it the display is Display P3. This enables colour management in the app, and short of writing a custom application, is the only way to get wide colour gamut content to work on the Pixel 3."
https://www.anandtech.com/show/13474/the-google-pixel-3-revi...
Save it to your device, and open it from the Photos app. Chrome doesn't seem to like wide color, but Photos does.
So this is interesting... I did this, and it only shows up in the preview/thumbnail view. Once I click on the thumbnail tile to view the image in full screen, it goes back to flat red with no logo.
Okay, some sort of curse is in play here.
Take a screenshot of the full-screen image. Do you see the logo flash?
Zoom in to the image. Do you see the logo appear, but only near the edges of the display?
Computers!
I'm not getting that - in Photos, looking at the full size flat-red version, and taking a screenshot, I don't see the logo flash at any time during that process. Nor on the edges when I resize.
Augh. Bizarre. Oh, do you have the "pop-up" overlay with icons for share, filters, etc. visible? (The one which appears when you tap the image.)
On my Pixel 3 XL, the behaviors I described occur, and also the logo is invisible unless the overlay is shown (in which case it's drawn only near the edges, unless you're taking a scree...oh.
I get it.
Image math is getting done internally in a wide gamut. Including alpha blending. But it's converted to sRGB before being displayed.
The things I described all, I suspect, modify the image- mostly by just dimming it, and the resulting dimmed wide color values map to different sRGB colors (where the undimmed colors all map to the same shade of red.)
I have a hunch that the internal management of the image by the application you've described is similar to the case of another comment where the logo could be seen in Windows after saving the file in MS Paint.
it's entirely possible that the preview compresses the color space in just the right way to show the separation. reducing colors can shrink image sizes quite a lot.
as to what's actually happening: not a clue! just pointing out possibilities :)
worked on my pixel 2 by setting the chrome flag to force the profile
Copying the image into Microsoft Paint shows the logo too.
If anyone is curious: https://i.imgur.com/IGTAWZF.png
Why is it that you can see it if you screenshot it?
The steps I took were: Right click on the image and selected copy. Paste it into Paint (which showed the logo).
I then saved it as a PNG (still showing the logo in Windows image viewer) and uploaded to Imgur. I assume pasting it into paint compressed the colors?
I saved it as a PNG and uploaded it. I don't know the technical details behind this but I'm assuming Paint compressed the colors.
PNGs are saved as sRGB by default, and so the differences aren't remapped away by the OS like they would be if the PNG was saved with a wider color space.
wait so if you screenshotted that.. what ends up saved in the PNG? Does the image clipboard now automatically have 2 versions of any screenshot; a wide colour version and some sort of normalised 8 bit version?
I'm looking at this from a macbook pro 2015 so I assume no wide colour support (?), yet I see the logo. Which conversion, at which step, caused that effect?
2015 MacBooks are not Display P3. What browser are you using, as that is incorrect behaviour.
The clipboard here is probably copying the image buffer in the untransformed state, and pasting it into MSPaint would dump those values incorrectly.
I see the same thing in both Firefox and Safari, on a non-P3 display: the original image is solid red, but the copied image shows the logo. So it looks like a conversion did actually happen at some point.
The transform to display the "solid red" block is actually the post-transformed data. The clipboard (rightfully) is carrying the original source buffer.
The issue would be the mechanics of the copy (attaching metadata) and pasting (interpreting the metadata in conjunction with the source image buffer.)
So technically, no, there's no conversion on the source data, it's the representation in the pasted context that's the issue.
My P30 Pro is listed as being wide color gamut capable : https://consumer.huawei.com/latin-en/phones/p30-pro/specs/
Yet I cannot get the android logo to display on Chrome or when the picture is downloaded and viewed on the default photo viewer.
Oh well maybe a future update will solve this issue. :p
Okay I just set the color mode from "vivid" to "normal" and now I can see the logo. Cool!
Fyi, never, ever use a monitor/TV in "vivid" setting. It sets the brightness, contrast and backlight settings to absurd values and clips a whole bunch of colors on the low and high luminance ranges resulting in a severely restricted dynamic range. A byproduct of this is that regular images appear super saturated and "vivid". Also, if you have an OLED or Plasma, vivid mode will almost certainly accelerate screen burn-in (I've even seen this happen on LCD TVs).
Thanks for the tip friend!
Actually I'm a hobby photographer, and I generally favor accurate color representation over any other special color modes. I do remember playing around with the settings when I got my phone and I think I just forgot to switch the color mode back to normal from vivid.
On my Mi 8 it works fine in Firefox, the default gallery app doesn't show it at all, and Google Photos shows it in the gallery view but not full screen. Oops...
If you are on a Mac, try changing your color profile in System Preferences | Displays | Color to something like 'Adobe RGB' or 'Display P3'. That allowed me to see the logo, as for a difference in the photos in the original post, not so much...
This test suggests that FF on Android doesn't properly work with color profiles: https://photographylife.com/is-your-browser-color-managed (the images are identical for me in FF on desktop, but not on the phone).
Which would mean that the red logo is just a result of mismapped colors.
I was pretty surprised to see the logo on a phone from 2011 with a rather meh screen…
Weird. I have a Pixel 3 XL, running Android P. I can see the Android logo in Firefox, but not in Chrome or Google Photos.
I tried setting the flag (chrome ://flags/#force-color-profile) and choosing P3, but I still see just a red square in Chrome.
EDIT: muro's tip (open in photos (menu -> device folders)) worked. Not sure why opening the same image from the Photos home screen doesn't work.
curiously enough, if I display this logo inside the firefox browser it is invisible (just a red square).
However, donwloading the png file and opening it on any image viewer it shows two different shades of red. I guess firefox is applying a silly color contrast change to its images before displaying them.
Just to add my own observations (Ubuntu Disco, FF 66) - it's also solid red for me in Firefox, but if I download it I can see the Android image in the preview in Gnome's file browser. If I open it up in Ubuntu / Gnome's "Image Viewer" application it's solid red, but works fine in Shotwell.
It's also solid red in GIMP 2.10, which surprised me.
On my Linux desktop, firefox, it's solid red. On my OnePlus 5T phone, it's solid red in Chrome, but an android logo in Firefox. Ah, if I download the file I see the logo with eom (eye of mate), though it's much less obvious than on the phone.
Moto G6+ with Firefox here, can clearly see the android logo. Not sure that this test is unequivocal.
It seems like others are having similar results. Some image libraries seem to be reducing the color space and changing the values. It could be an issue of P3 aware vs P3 capable. But I’m not entirely sure why it’s so hit or miss.
W10, on left ile is opened in IrfanView, right in latest Vivaldi: https://i.imgur.com/s8O5arl.jpg
On my Surface Go, it's solid red in Chrome and (surprisingly) Affinity Photo, but not Paint. I'm surprised that Paint has better support for this than a paid photo editing app.
I can't see any logo on a pixel 3 xl in chrome.
Edit: answered below - download to device, open in photos (menu -> device folders)
2015 MBP, Chrome/Safari will show a completely red image, copying it over to iMessage gives the red Android logo.
There is a bug there. You should be seeing a completely red image. Somewhere in your copy/paste step either (a) the color profile is being stripped out, or (b) the software you use to view the image is not properly respecting the color profile.
I believe both A and B are at work; it's probably a direct copy of the input buffer without metadata making B likely impossible, if it were trying at all, which I'll speculate isn't even a possibility.
Copying an image from one application to another should not strip image metadata. If it does that is a bug.
I’m not sure that clipboard implementations provide ancillary metadata? Nor would it be interpreted given the wild-west application development model where application developers are the folks who would need to implement support?
It is definitely possible to copy/paste images on the Mac while preserving image metadata. That behavior should be the default. If this is broken when copying between two Apple-provided applications then that is definitely a bug.
Good tip about FF, on my Pixel 2 Chrome shows just the plain red square, while FF reveals the Android logo.
Interestingly, on an OSX laptop, Chrome does not display it on one monitor but does on the other. Firefox displays it on both.
tl;dr: (╯°□°）╯︵ ┻━┻ color is hard.
I am glad to see my desktop machine isn't being left behind with this. In stock LTS Ubuntu the default image viewer shows the Display P3 images as does Firefox. The thumbnail in the file browser also has the logo showing.
Not sure about Chrome as I set the color flags to be sRGB a long time ago as, compared to Firefox, colours in Chrome are unsatisfactory on Linux.
I also tried on a consumer grade laptop that runs the latest (19.04) Ubuntu with one of those glossy screens, definitely not designed for Display P3. This failed in Firefox, Chrome, Gimp but the thumbnail in the file browser came good. How come when the hardware isn't there for it?
It seems like 25% of the colours are missing with a lot of that being green, green being quite an important colour. It must be possible to have some creative fun with this. If you can get images that only kids can see on their phones but adults not see on their boring PCs then you could have some variant of 'satanic backmasking' going on.
'Satanic backmasking' was where you could hear stuff about Satan on Beatles records if you played them backwards, listening whilst stoned. Politicians bothered themselves about young minds being corrupted by such things back in the day.
Maybe DCI-P3 images can court a similar controversy, shame April Fools Day is a lame day of corporate gags where nobody is fooled, otherwise DCI-P3 is ripe for moral panic, terrorising the adults with another thing for them to get their politicians frenzied about.
I hope Chrome gets to do colour a bit better, to Firefox standards. Otherwise we will be with half the world's screens not showing all the colours. Although not the same gap as between colour and monochrome, it is a huge difference to anyone that works with colour and needs subtle colour variations.
LG V35.
Chrome displays a red square, Firefox displays the wide gamut Android logo. Good job, Google.
Does anyone know of any popular camera image formats (ie not raw) that are actually using more than 8 bits per color?
The blog post mentions "8 bits per color channel is not enough", but as far as I can tell everyone using Display P3 for consumer-grade photos (including the iPhone) is still using 8 bits per color, just over the wider gamut.
It seems weird that this hasn't become a thing with the big marketing push behind HDR10 and others for TV. You might think "backwards compatibility", but Apple was fine making the HEIF break and converting when sharing with incompatible devices.
It's not entirely about bit depth. Think about 1 bit of a given colour light, it can turn on or off, but the bit depth doesn't tell us anything about the colour of the light it is turning on or off.
Encoding in a larger volume colour space may require additional bit depth to prevent posterization, but that's somewhat tangential. The larger issue is the number of vendors and operating systems that can't get it right. Windows is horrific, for example, with Android being at least as bad, as given by the accounts in the comments here.
> It's not entirely about bit depth
Are you trying to post the same thing in every top-level thread to get your comment seen? This has nothing to do with what I was asking, which was pretty much "everything about gamut and display aside, what's the deal with bit depth?". Hopefully you can see how your response is a distraction.
Nobody to my knowledge is using more than 8 bits per color for taking photos. Certainly nobody using JPG (which includes wide-gamut JPEGs from DSLRs), and at least right now not even HEIF on iOS is anything but 8 bits. I'm guessing because it hasn't caused much color-banding for the typical use case (photos) anyways.
Sony ARW is 14 bits on the A7 line. Canon 5D Mark IV RAW is 14 bit and so is the Nikon counterpart. Even the cheap Blackmagic Pocket Cinema Camera shoots 12 bit RAW.
Why is this important? Most of these cameras images end up on the web. VP9, HEVC and HEIC all support HDR10 so with the right processing this should come through.
JPEG is actually ~12 bits deep, it's just that all the decoders decode it to 8 bit YCbCr, and on top of that cause extra loss by 8-bit YCbCr->RGB conversion. It's possible to compile libjpeg with a 16-bit color pipeline, but it's a hassle, so nobody does that.
There are not two but three cases for the red logo:
1. You have no color management: you see the logo, but it is desaturated
2. You have a working CMS and standard gamut: no logo
3. You have a working CMS and wide gamut: logo is correct
#1 is true because the image has different values. #2 maps all the colors to the monitor's gamut and so you can't see anything on a standard display.
They say that an S10 should see it but my S10 with up to date Google Chrome doesn't show the android logo in the red image.
Funny enough I can see it just fine on my Macbook Pro running the latest Firefox stable.
On my S10e it indeed doesn't work on Chrome, but it does work on Firefox.
I'm on an up-to-date Pixel 3 in a 'vanilla' state using Chrome, and it does not work for me as well.
On my S10+ it works on Firefox but not Chrome or Samsung's browser.
Is it just me, or do the cloud images look different even without a wide color gamut display (I have a MacBook Pro from 2015).
Correct.
Haven't looked at the image too deeply, but this is likely the rendering intent being set so something other than the colorimetric offerings, such as Perceptual or Saturation. It could also be a poorly encoded image as well.
Deeper inspection reveals that both are tagged sRGB, which indicates they are for demonstrative purposes only.
Looks like iPhone XS already has support for wide gamut. I can see Android logo on red image on Safari as well as Chrome on XS but I can see it bit less bright on sRGB monitors also.
https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-re...
Proper wide-gamut colorspace support has been around on macOS since 2015: https://webkit.org/blog/6682/improving-color-on-the-web/
You can force enable wide color support in Chrome via a flag (assuming your display supports wider gamuts, of course).
See chrome://flags/#force-color-profile
I'm amused that chrome on Win10 does not pass their simple red logo test.
You must have a wide-color-gamut compatible monitor in order for the test to even be possible. Most laptops and desktops do not.
Safari on my iPhone X passes.
And have properly set up colour management working, which on Windows is close to zero percent probability.
This also ignores the shortcuts that Chrome and other browsers have taken on their road to colour management.
> And have properly set up colour management working, which on Windows is close to zero percent probability.
Maybe surprising to some, but Windows actually supports HDR10 (which includes "wide-gamut" color) better than other OSes. You can, for example, play HDR10 video games with a connected HDR-capable monitor. It might be thanks to MS's Xbox platform.
Chrome vs Firefox on the Pixel 2 https://i.imgur.com/kwirB6C.png
I am confused about why I can see this screenshot since I am not on a wide gamut monitor. Is firefox doing a weird conversion or the screenshotting tool?
My (probably flawed) understanding was that wide colors means there's more than 8 bits. So stuff that would be say rgb(254.5, 0, 0) would now be distinguishable from rgb(255, 0, 0)? If you screenshotted it back to 8 bit you would just lose the extra bits and I expected to still see a red square? Or is that not how it works?
Yes flawed. If you have a bitmap that's using a wide color space (e. g. P3/OLED) and it has a green (0,1,0) pixel then that's referring to a color than an LCD display cannot possibly show. 0,1,0 on an LCD is a less saturated green. The OS changes color values to try to make things look as much as expected as possible, and that results in color clipping. A screenshot saves images as sRGB and so no remapping is done upon display.
Firefox on a Galaxy S8 works. I wonder what the difference could be between two browsers on the same phone?
That's what the article is about: Apps need to use Android APIs correctly to display color accurately.
So Google Chrome running on Google Android doesn't use the correct Android APIs but Firefox does? Why is Chrome "the standard" again?
I just set the Chrome flag to force the display profile and was able to see the image on my Pixel 3a. The default profile will not show it.
So Chrome is using the APIs, but actually using that profile is still behind a feature flag, it seems.
Edit: I just tried it in Firefox and the log is much clearer. This makes me think that Firefox is doing something to change the image before displaying it, which is why it "works" there.
On Chrome, the image was incredibly faint.
> Why is Chrome "the standard" again?
It has no adblocker.
A lot of variables involved. For me Win 10 17134, with an NVidia GTX 960, over displayport to Dell U2417H, I can see the two colors in Chrome and Firefox. I can't see the color difference in Microsoft Edge. The ICC Profile for the monitor was automatically loaded by Windows. Everything is 32 bit.
I think the ICC profile is the only reason I can see it and it isn't a very strong difference on my monitor.
Edit: When I say 32bit, I mean 8 bit per RGB channel/24 bit "True Color"
Do you have a HDR display? Have you enabled Wide Colour Gamut?
So this red Android logo works on my moto x4 running Pie in Firefox, but not in Chrome. Uhhh.
Yeah my moto g4+ with Firefox shows the Android as well, heh