[HN Gopher] Support HDR images in your app [video]
___________________________________________________________________
Support HDR images in your app [video]
Author : janandonly
Score : 48 points
Date : 2023-10-06 17:49 UTC (5 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| Moldoteck wrote:
| Idk if iphones have this problem, but on Android, insta reels are
| so messed up bc of hdr. I'm watching em at night with low
| brightness and suddenly a hdr video pops out and it brightens my
| eyes to oblivion... And this issue is present for years
| altairprime wrote:
| I tested and it looks like the iPhone lowers the peak nits
| based on the brightness slider, so the HDR reels aren't "max
| phone brightness" bright, like they're trying to be. Dunno how
| that compares, but yes, it's present to some degree. (Low Power
| Mode disables EDR, which works around it, but has other effects
| as well.)
| Night_Thastus wrote:
| HDR is such a clusterf*ck right now.
|
| Especially with monitors. I am so sick of every monitor with Vesa
| HDR-400 claiming they're an "HDR" monitor. I'm sorry, but that
| standard is garbage. It's so bad it's meaningless.
|
| Not only is that a pathetic amount of brightness, but the local
| dimming required is just awful. You can have a screen with a
| whopping 4 zones that react terribly and slap an HDR label on it.
|
| HDR-600 is barely any better, frankly.
| Trigg3r wrote:
| Have had 3 monitors claiming "HDR-400" now; all look equally as
| shit with HDR enabled in Windows & Gaming, first two where
| between PS120 - PS250, third was a "premium" monitor @ PS500.
| Current "HDR" can get te fuck ;)
| formerly_proven wrote:
| Most of these are IPS and struggle reaching contrast ratios
| of 700:1 and black levels darker than noon. Some of the LG
| ones barely manage 500:1 in sRGB mode...
| Trigg3r wrote:
| All 3 have been VA to be fair. I do wonder if have missed a
| trick with IPS but have been lead to believe VA has the
| speed (and HDR as a plus)? that is kind of the point though
| I suppose, buying a "HDR ready screen" - it's been a real
| pain for a few years now from what I have seen >_<
| [deleted]
| Culonavirus wrote:
| The standard may suck due to too few local dimming zones, but
| the "pathetic amount of brightness" is a hard "for you" kind of
| deal. It depends on your use case.
|
| I use an LG OLED TV as a monitor for work (and a game here and
| there), 4k 120Hz and I'm more than happy with the brightness in
| HDR content. In fact, it's kind of just at the edge of being
| too bright for me... given the distance.
| Night_Thastus wrote:
| My complaint about HDR 400 was mostly with LCD monitors, not
| OLEDs. OLEDs may not get bright, but at least they get
| infinite contrast and perfect blacks.
|
| That's a huge improvement compared to a lot of the garbage
| HDR 400 rated LCD monitors.
| crazygringo wrote:
| Not just monitors but video players too.
|
| Trying to play HDR content on a regular SDR screen is a mess.
|
| If you rip an HDR version of a movie:
|
| - VLC does nothing. It shows it as so dark it's unwatchable
|
| - IINA shows it as brightness comparable to an SDR version of
| the movie, but with a weird green tint
|
| - QuickTime is weirdly in-between, brighter than VLC but not as
| bright as an SDR version
|
| - Infuse got fixed this year so that it plays HDR content to
| visually match the SDR version of the same content on a SDR
| screen (the _only_ player I 've found that can on Macs)
|
| And if you want to convert your file in ffmpeg, good luck. I
| still haven't found the magic settings that reverses whatever
| entertainment studios are doing to translate their SDR into
| HDR. (The magic settings that Infuse has somehow figured out.)
| There's no flag or setting for it -- you have to input a bunch
| of custom values.
| lldb wrote:
| mpv with --tone-mapping=bt.2446a (or whichever you like from
| https://mpv.io/manual/stable/#options-tone-mapping), --hdr-
| compute-peak=yes, and --target-peak=SDR monitor nits, does
| the best I've seen yet.
| PaulBGD_ wrote:
| Plex does a fairly good conversion too, iirc using ffmpeg.
| zimpenfish wrote:
| I can't remember where I found this but it's what I've been
| using to downscale and convert the occasional 10bit downloads
| (using the nvenc GPU acceleration.) ffmpeg
| -hide_banner -y -probesize 100M -i "$file" -map 0:v:0 -c:v
| h264_nvenc -x264-params b_pyramid=2:ref=4:vbv-
| maxrate=30000:vbv-bufsize=15000 -refs 4 -crf 17
| -preset:v fast -profile:v high -b_strategy 2 -rc-lookahead
| 900 -level 4.1 -pix_fmt yuv420p -color_range 1 -colorspace 1
| -color_primaries bt709 -color_trc bt709 -subq 10 -vf zscale=t
| in=smpte2084:min=bt2020nc:pin=bt2020:rin=tv:t=smpte2084:m=bt2
| 020nc:p=bt2020:r=tv,zscale=t=linear,format=gbrpf32le,zscale=p
| =bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r
| =tv,format=yuv420p,zscale=s=1280x720 -c:a copy output.mkv
| wilg wrote:
| What's the * stand for?
| clnq wrote:
| Impossible to know.
| Night_Thastus wrote:
| It's a regex wildcard symbol.
| chongli wrote:
| Has anyone actually used a decent HDR display? I'm really
| skeptical of the technology. I really don't want websites and
| videos to be able to display blindingly bright white and other
| pure colours on my screen. I like things to be readable and not
| painful to look at.
| baq wrote:
| Any OLED display since 2015ish. I've got a 2017 LG C7 and it's
| amazing to this day.
| Night_Thastus wrote:
| OLEDs have amazing blacks and great contrast, but they truly
| struggle to get bright. That still isn't solved, at least to
| my satisfaction. They can get bright briefly or in small
| areas of the screen, but tend to crunch the brightness a lot
| otherwise.
| baq wrote:
| Yeah I do pull the curtains down to watch tv during the
| day. Don't care too much since I rarely have time when the
| sun's up. At night it's absolutely stunning when the
| content's right.
| sgt wrote:
| Any new or recent iPhone. When I first got my 14 Pro and
| displayed a photo with HDR I was blown away.
| FL410 wrote:
| Yes. The HDR on a recent Macbook Pro is the real deal, and
| unmistakable when you see it. Same with modern OLED HDR TVs -
| they can get so bright it hurts.
| Night_Thastus wrote:
| What OLEDS have decent brightness? OLEDS really struggle with
| that because of burn in. They can get temporarily bright, or
| bright in tiny zones, but in less than ideal conditions they
| crunch it right down.
| astrange wrote:
| LEDs have separate backlights, which is good for getting
| brighter but bad for contrast because they can't get as
| dark as OLEDs.
|
| I think the reason you don't want to drive OLEDs as hard
| (so there's current limitation/ABL) is more about burn-out
| than burn-in.
| [deleted]
| iteratethis wrote:
| I'm sure you mean LED TVs. OLED TVs are notorious for having
| a limited brightness. Only since 2022 are there some newer
| panels (called OLED.ext) that can do decent HDR.
| cwillu wrote:
| > they can get so bright it hurts.
|
| I regret that hn doesn't have HDR support so as to properly
| emphasize that <em><blink><pain>THIS IS NOT A
| FEATURE.</pain></blink></em>
| mort96 wrote:
| It would have been a pretty nice feature though, if it
| could've been used to uniformly make SDR content brighter,
| to make the laptops more useful in sunlight and with
| sunglasses. Too bad that's not a feature (I'm guessing
| because it wear out the screen or something).
| chongli wrote:
| _sunlight and with sunglasses_
|
| No thank you! If I'm outside enjoying the sun with
| sunglasses on then I have zero interest in using a
| laptop!
| mort96 wrote:
| Sure, but there are also times when the desire to do
| something computery is greater than the desire to be
| outside. In those situations, it's a choice between being
| inside with a computer or being outside with a computer.
| NovemberWhiskey wrote:
| Do you use an OLED iPhone?
| Night_Thastus wrote:
| If you're willing to sacrifice everything else (including
| money), yes, there are some nice HDR displays. Get something
| with HDR1000 standard or above. Get something with FALD and a
| LOT of zones. Make sure to check its color space coverage. Look
| at independent reviews. Be prepared to spend at least a couple
| grand.
|
| But you'll have to turn HDR on and off depending on the content
| you're looking at. If you're looking at SDR content, it will
| look wrong if the display is in HDR mode. That sucks, and I
| hope some day is properly fixed.
|
| OLED is also nice because it has perfect blacks (no local
| dimming needed), but it struggles with brightness, which is the
| other half of HDR. We still haven't figured out how to get
| both.
| astrange wrote:
| You don't have to turn HDR on and off if the OS does color
| management correctly. But of course only Apple platforms do
| this.
| mort96 wrote:
| I think my laptop has a decent HDR display? It's a MacBook Pro
| 14" with "Liquid Retina XDR" as they call it. I think HDR
| content looks more or less ... as intended.
|
| I think it's terrible. The only time I even remember that HDR
| is a thing is when some embedded video in a web page gets much
| brighter than the rest of the screen and the rest of the screen
| looks dim as a result. It's never a "wow that sun looks
| amazing" style experience, it's always a "wow most of my screen
| just got really dark" style experience.
|
| I think maybe HDR has a place in movies and TV shows and even
| maybe YouTube style videos (not that I've experienced that),
| but I think enabling HDR for small video embeds on a web page
| was a terrible decision.
| Night_Thastus wrote:
| It's because trying to view SDR content on an HDR display
| doesn't work. It will look like garbage. You have to turn HDR
| on and off depending on what content you view.
| wlesieutre wrote:
| Have you tried it on a Mac laptop? The OS will
| transparently boost the backlight brightness while shifting
| the white point of the non-HDR content down so that
| everything else on screen is completely unaffected.
|
| It's very different from the experience I've had in Windows
| where if you enable the HDR setting everything looks shitty
| and washed out.
| Toutouxc wrote:
| On Apple displays you don't have to turn HDR on or off,
| it's available all the time. SDR content is displayed as
| usual (exactly like everything looked 10 years ago) and HDR
| content can sit directly next to it and use whatever
| brightness headroom is available for extended dynamic
| range. It's totally seamless and transparent, but the
| experience can make the user think that SDR content is
| getting darker as their eyes adjust to HDR.
| Night_Thastus wrote:
| That must be nice. Hopefully the rest of the world
| catches up to that.
| baq wrote:
| What you've described is absolutely not anywhere close to
| decent.
|
| Right now it's basically OLED in a dark room or don't bother.
| Large TVs can get away with FALD, maybe.
| lexlash wrote:
| For productivity/reading, I want one of the new eInk screens.
| For gaming and video, the HDR OLED displays I have (LG and
| Dell) look incredible. Mixed content looks awful, just like
| mixes of high DPI UIs rendering low DPI websites.
|
| Windows HDR support is a very mixed bag, just like their early
| support for high DPI, and I think that's probably what leads
| some reviewers to dismiss it.
| clnq wrote:
| Windows struggles with HiDPI?
| nchase wrote:
| Naive question: why is this newsworthy? What are the
| implications?
| adzm wrote:
| HDR and higher bit colors are becoming more popular but are
| still very much a mess from the consumer and software developer
| standpoint.
| altairprime wrote:
| The original title referred to Apple's endorsement of an
| upcoming ISO standard that defines how to represent HDR images
| within existing still image file formats such as JPEG-XL and
| HEIF. It turns out that there _isn't_ any such finalized
| standard -- unlike, for example, BT.2020 in the moving image
| file formats space.
|
| So, presumably, the existence of a standard under development
| -- and the endorsement of it by a major manufacturer of cameras
| and displays -- was considered newsworthy by the OP.
| [deleted]
| dang wrote:
| The submitted title was "Apple put their weight behind an open
| HDR standard called "ISO/TS 22028-5"" but that broke the HN
| guideline against editorializing: " _Please use the original
| title, unless it is misleading or linkbait; don 't
| editorialize._" -
| https://news.ycombinator.com/newsguidelines.html
|
| If you want to say what you think is important about an article,
| that's fine, but do it by adding a comment to the thread. Then
| your view will be on a level playing field with everyone else's:
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
| wilg wrote:
| I simply wouldn't have looked at this with the new title. The
| original title was better. The new title deletes the
| interesting insight about the format they are using. Now it
| just looks like a video about general HDR workflow and I don't
| know why it's been posted. The newsworthy element may not be
| the entire link but some element on the page, especially for
| longer form content.
| altairprime wrote:
| Submitting a blog post about this would have been much more
| effective than linking an Apple developer video with a
| modified title. (And, then I wouldn't have had to add quotes
| and context as a comment below.)
| wilg wrote:
| Arguably, everything worked out fine until the title
| changed.
| pvg wrote:
| It didn't - one of the main reasons you can't make up
| your own title is that it acts as a kind of mega-comment
| over everyone else's comments. If you want to just
| comment, write a regular comment. If you want your own
| title with your own commentary, write your own commentary
| and submit it to HN with your title.
|
| What you can't do is use someone else's stuff to make
| your commentary more important.
| wilg wrote:
| Well, it wasn't really commentary though. It was a
| pointer to the interesting information in the link.
| pvg wrote:
| That's commentary/editorializing. Nothing wrong with
| these things, you just don't get to do them in the title
| for the reasons mentioned in the previous comment.
| xd1936 wrote:
| Agreed. Original title was not clickbait or misleading in any
| way.
| pvg wrote:
| "original title" means the original title of the article,
| not the title the submitter originally made up.
| tormeh wrote:
| That's the original title of the submission, though.
| pvg wrote:
| Yes but the guideline about 'original title' doesn't mean
| that. That's the editorialized title, not the original
| title of the thing. What you're suggesting is
| misconstruing the guideline to mean the opposite of what
| it actually means.
| dang wrote:
| A good place to explain why an article is being posted is by
| adding a comment to the thread.
| wilg wrote:
| No it isn't, because you can't see that from the main page
| so there's no reason to look at the link or comments if you
| don't know what is interesting about the post. This rule
| makes sense for editorialized titles, but not as much for
| trying to point to news that is buried in some larger page
| that does not have a useful title.
| ShamelessC wrote:
| Putting a notice either like this or as an indicator on the
| submission would go a long way towards reducing (my)
| frustration with moderation's title edits.
| dang wrote:
| The problem with that is that there are many such notices and
| indicators we might put up about many things. If we did all
| of them, the site would get messier and more annoying and
| nannyish.
|
| It seems generally better (or at least in keeping with HN's
| 'DNA') to err on the side of keeping things minimal and trust
| users to figure them out.
| ShamelessC wrote:
| That's fair. I was thinking something in the realm of a
| bolded asterisk next to the title. Or something similarly
| subtle with an explanation in the rules perhaps. Obviously
| there are users who would meta comment about this each time
| it happened (as is happening currently), so I can
| understand the reluctance.
| [deleted]
| altairprime wrote:
| ISO/TS 22028-5:2023 Photography and graphic technology --
| Extended colour encodings for digital image storage, manipulation
| and interchange -- Part 5: High dynamic range and wide colour
| gamut encoding for still images (HDR/WCG)
|
| https://www.iso.org/standard/81863.html
|
| Note that, in this specification's title, "HDR" refers to
| luminosity ranges that are broader than sRGB supports, and "WCG"
| refers to colorspaces that are broader than sRGB supports.
|
| Apple's video is focused on the HDR component of still images,
| which is relatively new and not yet finalized into any ISO or W3C
| standards.
|
| Support for WCG images is already widespread courtesy of ICC
| profiles, though many holdouts (such as Slack and Discord)
| continue to damage WCG images posted to their services.
|
| Quoting Apple's video transcript at this time index:
|
| https://developer.apple.com/wwdc23/10181?time=205
|
| > _This specification, TS22028-5, provides a structure for
| encoding HDR content into existing still image formats without
| compromising quality._
|
| > _The specification requires Hybrid Log-Gamma, HLG, or
| Perceptual Quantizer, PQ, as the encoding transfer function.
| These are functionally analogous to the gamma curves used in SDR
| images._
|
| > _The color primaries for ISO HDR files are the BT.2020
| primaries_
|
| > _HDR images are required to be 10 bits or more per component.
| This means that some formats, like HEIF, can encode HDR, but some
| others, like traditional JPEG, are not able to be 22028-5
| compliant, as they only support 8 bits per component._
|
| PNG _only_ supports 8-bit or 16-bit, making it quite inefficient
| for 10- and 12-bit HDR. However, JPEG-XL seems to support 10 bits
| or more per component. This may provide supporting context for
| why Apple began supporting a new image format this fall.
|
| > _for required metadata, both traditional ICC profiles and CICP
| tags are valid._
| the8472 wrote:
| Isn't that just BT.2100?
| turnsout wrote:
| Yeah, it does appear to be a reiteration of Rec. 2100 /
| BT.2100. I wonder if it's because this refers to still images
| rather than video?
| altairprime wrote:
| Yes, that's why:
|
| https://stage.color.org/hdr/07-Nicolas_Bonnier.pdf (slide
| "Motivations"):
|
| > _Several attempts to use PQ /HLG and BT.2020 for still
| photography are surfacing_
|
| > _But so far, the digital still imaging industry has not
| settled on a reference HDR /WCG image encoding for
| consumers_
|
| > _The purpose of TS 22028-5 is to provide requirements and
| guidelines for HDR /WCG colour encoding of still images_
|
| And a bit further down, referring specifically to BT.2100:
|
| > _Shall use ITU-R BT.2020 /2100-2 colour primaries_
___________________________________________________________________
(page generated 2023-10-06 23:02 UTC)