Live HDR+ and Dual Exposure Controls on Pixel 4 and 4a
ai.googleblog.com
ai.googleblog.com
I am very impressed with the photo AI work people have been doing. Very concrete feature for people to use.
I wish at least 12bit (ideally 14 or 16bit) compressed image formats (like HEIF) took over jpeg on cameras. It's great to have raw as an option, but can we please just get rid of 8bit jpg as the default
While it is the job of the photographer, these days, to collapse the dynamic range enough to get it onto a screen, there is a huge depth of experience awaiting us the day that our displays reach parity with our sensors.
The bit depth of a photo or display device is not the same as the dynamic range at which that photo is displayed. With traditional SDR image formats, on some screens a "0" pixel will be displayed at about 1 nit brightness, and a "255" pixel will be displayed at about 100 nits. But on other screens, the same pixel will be shown at 500 nits or more. Thus with SDR images, the luminance range depends on the characteristics of the display device in use, and not the fact that it's only an "8 bit" photo. "8 bit" ≠ "8 stops". On the other hand, on displays with very high peak brightness, you may get banding even with images that are properly dithered to take advantage of the full capabilities of the 8 bit range.
The point of 10 bit and higher is that you can accurately capture all the details in between a very dark portion of an image and a very bright one without banding. The point of the new HDR standards (which are just now being introduced to images) is that luma is now on an absolute scale, so that you are no longer dependent on the characteristics of the individual display. (You have to have both together for either to be very useful.) But whether you're working with SDR or HDR, 8 bit or 10 bit, fundamentally the question of how many stops you can get (the display's true contrast) is a question of what the display is capable of reproducing, not the underlying technology you're working with.
It isn't the maximal intensity that matters, (to the extent that the viewer's eye can adapt to the differences in intensity between displays), but rather the number of subdivisions available between peak intensity and darkness.
Totally agreed that improved bit-depth improves gradations/banding. An N+1-bit display has N bits between half-intensity and full intensity, twice as many bits as an N-bit display has.
Another way to see that this matters is that imaging sensors are generally linear in their response to impinging light. The optimal way to display the output from a 14-bit sensor is a 14-bit (or higher) display.
That's not what a nit is. A nit is a measurement of absolute brightness. You can have 256 gradations (8 bits) on a 100 nit display. You can have 1024 gradations (10 bits). You could have 65536. What's being measured here are two different things. Imagine I have a flashlight with adjustable brightness: if I turn it all the way up, that's what we're measuring when we talk about the nits of a display with with all white pixels. The bit depth is how many gradations the flashlight can display between full brightness and no light at all. So in fact a 100 nit display can have any bit depth. A stop is not a nit is not bit depth.
(This is a simplification that is only completely accurate for SDR screens with sRGB gamut. With HDR and tagged images, part of the range created by the extra bit depth is for "impossible" values, stuff that is too bright or colorful for the screen to display, and has to be tonemapped by the display into the possible range.)
http://www.color.org/WP40-Black_Point_Compensation_2010-07-2...
We agree that bit-depth is independent of maximum light output. Where we appear to disagree is on the meaning of an ideal bit, in particular whether or not it is acceptable for the (gamma-corrected) intensity difference between pixel-value 0 and pixel-value 1 to be greater than the base intensity of the display at pixel-value 0. I believe that I'm arguing for the concept depicted in Figure 3 of the document above (relative colorimetric), while you are arguing for the concept in Figure 4 (black-point compensation).
There is an important pragmatism to your approach -- high contrast ratios are technically difficult, while higher-resolution gradations sitting atop a pedestal of minimum intensity may be more technically-feasible. Increased subdivisions between minimum intensity and maximum intensity do reduce banding, as you suggest. Such a rendering choice can portray the content of an image at the expense of the creator's intended contrast.
A linear display output with no offset will yield an intensity proportional to the intensity value assigned to that pixel. Higher bit-depth does not make for greater intensity, but rather more gradations between maximum intensity and zero.
As a scientist or as an artist, when specifying pixel values I expect the intensity, on a calibrated display, to reproduce a calibrated fraction of the maximum light intensity. It is helpful to understand that not all systems render with this intent.
In the original reply, the thought-experiment display had a minimum brightness of 1 nit and a maximum brightness of 100 nits and 255 brightness levels between them. That spans a factor of 2^6.7. The discrepancy between our opinions represents differences in a choice of rendering intent. If I had to specify the rendering strategy for portraying 8-bit pixel values on such a display, it would have less contrast in the shadows than the highlights but equal contrast in the highlights when compared with an 8-bit display with a minimum brightness of 0.4 nits and a maximum brightness of 100 nits (which is capable of 2^8 dynamic range). Your strategy would yield uniform contrast spanning the shadows and highlights, but less contrast on the 1-100 nit display than the 0.4-100 nit display.
In that situation, I suspect that most people would prefer your black-point compensated rendering strategy, as the shadows would not be crushed. I simply wouldn't market/sell it as a true 8-bit display, though I understand why a manufacturer would choose to do so.
Thank you -- I learned something useful.
Can you tell me how I'd enable this on an Android 9 device? I've looked everywhere, even in the developer options, but I can't find it.
The Play store claims that my device is incompatible with the official Google camera app. https://play.google.com/store/apps/details?id=com.google.and...
But iPhones have defaulted to using HEIF for years now I think, and no browser (even Safari) supports the format yet, so...
Interestingly, the final rendering in the Pixel 3 looks better to my eyes.
But it's definitely a great tool. See this HDR photo I made years ago:
Same here.
https://forum.xda-developers.com/apps/google-camera-mods/gca...
And the sad fact of the matter is that computational photography on phones, especially when it comes to HDR, makes it absolutely no hassle to obtain exceptionally good HDR captures 80+% of the time. I've literally taken back to back comparison shots of my son on a bright sunny day on a boat when on the ocean and my smartphone picture (S9+) was far superior to my DSLR image, even after trying to capture details from highlights/shadows in postprocessing.
Phones these days can perform a lot of neat tricks to reduce noise, capture large dynamic ranges and compress it all into a pleasing HDR image in fractions of seconds that lets you achieve great HDR images even with moving subjects (something notoriously hard with a DSLR).
Not that DSLRs don't have a whole host of other advantages when it comes to image quality and depth-of-focus, etc, but HDR is not one of them. It is almost the sole reason why I've been reaching for my DSLR less and less when on vacation.
Together with the phone always being in my pocket, while a DSLR is bulky, I've gone completely with the phone. I just wish the computational photography developers and the camera engineers would come together and make something that uses the far superior hardware of the DSLR combined with the far superior software originally designed for phones.
Capture RAW+JPEG of a scene with dark shadows and bright highlights, the camera clearly isn't using a linear transfer function to get from RAW to JPEG. With something like a D7200 you can literally have the sun in your picture and still get both detail in the sunstar and the clouds, while also having detail in the sun's shade, with an out-of-camera JPEG.
To simplify I'll pick a grayscale image so with 8bits you would only have 0-255 as pixel values for the intensity.
With 12 bits you'll have 4096, and so forth.
What cellphone HDR usually does is take the image at a high exposure and a low exposure and combine the result. (Also the sensors inside the cellphone are also more than 8bit)
Even if you take a 12 bit photo if it's overexposed you can't do much. All you get is more play but it doesn't solve the fundamental problem of too much light hitting the sensor, or vice versa if the image is underexposed.
Now there are more advanced camera sensors that let you set the exposure time (or usually the ISO (which just translates to gain) at specific horizontal points of the sensor so that you can get even better images in one frame.
This is correct, they seem to be mistaken. I've seen this mistake many times in this thread. I wrote a comment in reply to one of them explaining in some detail what the point of higher bit depths and "HDR" (as a set of technology standards) is: https://news.ycombinator.com/item?id=24044818
I'm aware of the difference between bracketed HDR and what these cameras do, but that's besides the point. If you capture RAW+JPEG it's pretty obvious that the camera is not using a flat curve, but that it is quite clearly doing something similar to tone mapping around highlights and shadows, and it's not fixed either, but slightly different for each shot.