HDR -> SDR conversion
Re: HDR -> SDR tonemapping
In the manual of the version 1.4 says that the "gamma" parameter has a default value of 1.42. Could this be a typo?
Re: HDR -> SDR tonemapping
Hi,
I am having an issue with highlight being overblown in this particular scene.
If I set light=500, it seems to alleviate the problem, although not entirely. However, every thing else will be too dark. And adjusting gamma brings back the issue.
HDR No tonemapping
![Image](https://malzo.com/i/2018/07/02/xBG.md.png)
Mobius, light=160
![Image](https://malzo.com/i/2018/07/02/xBC.md.png)
Mobius, light=250
![Image](https://malzo.com/i/2018/07/02/xBQ.md.png)
Mobius, light=500
![Image](https://malzo.com/i/2018/07/02/xBJ.md.png)
SDR
![Image](https://malzo.com/i/2018/07/02/xBX.md.png)
Sample:
https://mega.nz/#!8IggFAqb!LOTOfwBozW-E ... LF5Z-VaeHU
I am having an issue with highlight being overblown in this particular scene.
If I set light=500, it seems to alleviate the problem, although not entirely. However, every thing else will be too dark. And adjusting gamma brings back the issue.
HDR No tonemapping
![Image](https://malzo.com/i/2018/07/02/xBG.md.png)
Mobius, light=160
![Image](https://malzo.com/i/2018/07/02/xBC.md.png)
Mobius, light=250
![Image](https://malzo.com/i/2018/07/02/xBQ.md.png)
Mobius, light=500
![Image](https://malzo.com/i/2018/07/02/xBJ.md.png)
SDR
![Image](https://malzo.com/i/2018/07/02/xBX.md.png)
Sample:
https://mega.nz/#!8IggFAqb!LOTOfwBozW-E ... LF5Z-VaeHU
Re: HDR -> SDR tonemapping
I'll investigate. Thank you for the report and the sample, dmcs.
Re: HDR -> SDR tonemapping
@dmcs
Your SDR screenshot appears to have some heavy tonemapping that I cannot obtain from the algorithms I have tried. Maybe it is just lower gamma for the scene. It also probably uses a compression gamut mapping rather than a clipping one, see below.
I have double checked my gamut mapping. It is standard 2020->709 with clipping. In say frame 24 of your sample, the only clipped colors are in the middle of the bright area. So that SDR shot appears to be made with compression gamut mapping together with gamma reduction.
Lowering gamma does help with DGHDRtoSDR to restore the darks for that scene, but I assume when you say "brings back the issue", you mean the clipping of the bright spot, such that it shows a clear outline of a brighter area. Is that correct? If so, I can implement a compression style gamut mapping. I believe madVR moved from clipping to compression after similar observations. My simple idea is to convert to Lab and then compress the L before converting back to linear RGB with 709 coefficients. But there are many ways to go.
https://pdfs.semanticscholar.org/fd0d/4 ... 194c01.pdf
I'll drop madshi a line to ask what he is doing in this regard. How does madVR do with this scene?
Your SDR screenshot appears to have some heavy tonemapping that I cannot obtain from the algorithms I have tried. Maybe it is just lower gamma for the scene. It also probably uses a compression gamut mapping rather than a clipping one, see below.
I have double checked my gamut mapping. It is standard 2020->709 with clipping. In say frame 24 of your sample, the only clipped colors are in the middle of the bright area. So that SDR shot appears to be made with compression gamut mapping together with gamma reduction.
Lowering gamma does help with DGHDRtoSDR to restore the darks for that scene, but I assume when you say "brings back the issue", you mean the clipping of the bright spot, such that it shows a clear outline of a brighter area. Is that correct? If so, I can implement a compression style gamut mapping. I believe madVR moved from clipping to compression after similar observations. My simple idea is to convert to Lab and then compress the L before converting back to linear RGB with 709 coefficients. But there are many ways to go.
https://pdfs.semanticscholar.org/fd0d/4 ... 194c01.pdf
I'll drop madshi a line to ask what he is doing in this regard. How does madVR do with this scene?
Re: HDR -> SDR tonemapping
Old versions of madVR used to have a similar issue, fixed a while ago though.
Took a screenshot from v.0.92.14 but madshi has been working on proper colors in highlights in the last few test builds, still waiting on a final decision.
There's definitely some desaturation happening, in the past you could adjust % brightness & saturation.
Hopefully these help
DGHDRtoSDR looks closest to color corrected, though with blocking.
Took a screenshot from v.0.92.14 but madshi has been working on proper colors in highlights in the last few test builds, still waiting on a final decision.
There's definitely some desaturation happening, in the past you could adjust % brightness & saturation.
Hopefully these help
DGHDRtoSDR looks closest to color corrected, though with blocking.
Re: HDR -> SDR tonemapping
Super helpful, Narkyy, thank you! I've dropped a line to madshi. Hopefully he can share some insights. Meanwhile I am implementing a "hue/lightness-preserving chroma mapping" algorithm in CIELAB (not the lightness mapping I suggested in my previous post). There are hundreds of ways to go with this. ![Wow :wow:](./images/smilies/icon_eek2.gif)
If you look carefully at the original HDR version, you can see there is a subtle contour in the bright area, but it is greatly amplified by clipping.
The problem with hue preservation is that CIELAB is not a perfect perceptually linear space. But nobody knows a perfect perceptually linear space, so we are in the realm of heuristics and time-complexity tradeoffs. I'm hopeful we can find a reasonable algorithm that works well for most scenes, and whose performance dominates when parallelized with CUDA.
![Wow :wow:](./images/smilies/icon_eek2.gif)
If you look carefully at the original HDR version, you can see there is a subtle contour in the bright area, but it is greatly amplified by clipping.
The problem with hue preservation is that CIELAB is not a perfect perceptually linear space. But nobody knows a perfect perceptually linear space, so we are in the realm of heuristics and time-complexity tradeoffs. I'm hopeful we can find a reasonable algorithm that works well for most scenes, and whose performance dominates when parallelized with CUDA.
Re: HDR -> SDR tonemapping
Yes. That was what I meant. Can't thank you enough for your time & the work you've done.admin wrote: ↑Fri Jul 06, 2018 2:08 pmLowering gamma does help with DGHDRtoSDR to restore the darks for that scene, but I assume when you say "brings back the issue", you mean the clipping of the bright spot, such that it shows a clear outline of a brighter area. Is that correct? If so, I can implement a compression style gamut mapping. I believe madVR moved from clipping to compression after similar observations. My simple idea is to convert to Lab and then compress the L before converting back to linear RGB with 709 coefficients. But there are many ways to go.
![grateful :salute:](./images/smilies/icon_salute.gif)
![grateful :salute:](./images/smilies/icon_salute.gif)
Re: HDR -> SDR tonemapping
You're welcome. We'll get this sorted out.
Re: HDR -> SDR tonemapping
I'm not sure if it's what you mean as clipping, but on the edges going from very bright light to green it looks like squares instead of a smooth transition/gradient.
Mostly noticeable at lower light like the light=160 screenshot, the one at 500 looks good.
Mostly noticeable at lower light like the light=160 screenshot, the one at 500 looks good.
Re: HDR -> SDR tonemapping
OK, thank you. We could call it contouring. The thing is, though, if you take the HDR screenshot and tweak levels (or brightness/contrast) on it, you can see these same contours. So what is so wrong about my rendering? And does it really make a big deal of difference for unusual scenes like this?
I tried gamut mapping it by compressing the saturation rather than just clipping the RGB and it made no noticeable difference. The clipped (out of gamut) area is actually a smaller ellipse within the bigger bright ellipse. This inner contour is not noticeable within the bigger bright ellipse (I see it only by changing out of gamut colors to full red), and so changes to its mapping won't affect the bigger bright contour. And that bright contour is present in the HDR as I said. I'm thinking for dmcs this may be more a matter of the lightness levels than contouring.
@dmcs
Can you please provide a bigger source video sample that includes extra "normal" scenes around the one you gave. I am trying to determine the correct light level to use. The metadata says light=1000 but that makes things too dark. I can give you my FTP details if needed.
I tried gamut mapping it by compressing the saturation rather than just clipping the RGB and it made no noticeable difference. The clipped (out of gamut) area is actually a smaller ellipse within the bigger bright ellipse. This inner contour is not noticeable within the bigger bright ellipse (I see it only by changing out of gamut colors to full red), and so changes to its mapping won't affect the bigger bright contour. And that bright contour is present in the HDR as I said. I'm thinking for dmcs this may be more a matter of the lightness levels than contouring.
@dmcs
Can you please provide a bigger source video sample that includes extra "normal" scenes around the one you gave. I am trying to determine the correct light level to use. The metadata says light=1000 but that makes things too dark. I can give you my FTP details if needed.
Re: HDR -> SDR tonemapping
I guess it's the same issue as this post viewtopic.php?f=14&t=617&start=320#p8494
Looks good only at high nits, but increasing that affects the whole frame.
Another comparison with peak=3 and HDRTools
Though like said before HDRTools is more complicated to understand what's being done.
Also metadata from HDR streams usually only determines the peak nits the highlights should be clipped at, I think.
Which is why it looks too dark.
For example: Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
However there's also MaxFALL (Max Frame-Average Light Level) but it's not always specified in the stream metadata.
Looks good only at high nits, but increasing that affects the whole frame.
Another comparison with peak=3 and HDRTools
Though like said before HDRTools is more complicated to understand what's being done.
Also metadata from HDR streams usually only determines the peak nits the highlights should be clipped at, I think.
Which is why it looks too dark.
For example: Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
However there's also MaxFALL (Max Frame-Average Light Level) but it's not always specified in the stream metadata.
Re: HDR -> SDR tonemapping
I really need a bigger source sample from dmcs. There's no way to make good decisions based on a few frames of a very unusual scene.
Your screenshots are not labeled so I cannot tell what they are (what is 2.png, what is 3.png?). That makes them useless.![Wink ;)](./images/smilies/icon_e_wink.gif)
Your screenshots are not labeled so I cannot tell what they are (what is 2.png, what is 3.png?). That makes them useless.
![Wink ;)](./images/smilies/icon_e_wink.gif)
Re: HDR -> SDR tonemapping
In order: peak=3, HDRTools tonemap
Regarding dmcs' issue, I guess peak=2 would fix the overblown highlight. That's usually a value that works well.
I just derailed from the initial problem with the "contouring" issue, sorry for that.
Regarding dmcs' issue, I guess peak=2 would fix the overblown highlight. That's usually a value that works well.
I just derailed from the initial problem with the "contouring" issue, sorry for that.
Re: HDR -> SDR tonemapping
I still don't get it. Can you give the script for each screenshot.
I'm not conceding that my rendering is "overblown". How do you define that and how do you determine if something is overblown?
I do prefer to stick with one sample until we reach some closure and not confuse it with others.
Re: HDR -> SDR tonemapping
I'm guessing he's comparing with the SDR version (from a SDR mastered Bluray).
The center of the highlight (luma around 235) is wider with default settings, so "overblown".
Either that or 235 is too high? I don't know.
Mobius' peak setting does help because it doesn't affect the overall brightness, just highlights.
SDR
![Image](https://malzo.com/i/2018/07/02/xBX.md.png)
DGHDRtoSDR(impl="255", tm="mobius", light=160)
DGHDRtoSDR(impl="255", tm="mobius", light=160, peak=2.0)
The center of the highlight (luma around 235) is wider with default settings, so "overblown".
Either that or 235 is too high? I don't know.
Mobius' peak setting does help because it doesn't affect the overall brightness, just highlights.
SDR
![Image](https://malzo.com/i/2018/07/02/xBX.md.png)
DGHDRtoSDR(impl="255", tm="mobius", light=160)
DGHDRtoSDR(impl="255", tm="mobius", light=160, peak=2.0)
Re: HDR -> SDR tonemapping
light = 160 is way too low, in my opinion. Don't blame me for blown out areas with that light setting.
I'm going to wait for dmcs to tell me what he thinks is wrong and why. I do not see anything wrong with my rendering (light = 500 + default mobius).
Here is the HDR screenshot naively sharpened:
The contours are there in the source. I'm not interested in duplicating some random SDR conversion of which we know nothing. I only want my rendering to be decent across all scenes and videos.
I'm going to wait for dmcs to tell me what he thinks is wrong and why. I do not see anything wrong with my rendering (light = 500 + default mobius).
Here is the HDR screenshot naively sharpened:
The contours are there in the source. I'm not interested in duplicating some random SDR conversion of which we know nothing. I only want my rendering to be decent across all scenes and videos.
Re: HDR -> SDR tonemapping
Hi,
I hope a 3 minute sample would suffice. Let me know.
I think I've jumped into the "overblown" conclusion too early. My apology. Here are some screenshots that I took, using Mobius, with light=250 and 500 respectively (other parameters are set at default) and madVR.
In order: HDR no tonemapping -- light=250 -- light=500 -- madVR
At light=500, the scene with the turntable looks fine, smooth transition from the brightest center outwards. But then the other scene looks really dark.
For light=250, the results are reverse. In the scene with the turntable, there appears to be a teal blocky boundary (aliasing artifact?) along the contour of the brightest area.
I hope a 3 minute sample would suffice. Let me know.
Code: Select all
https://mega.nz/#!oYNFQaTS!fruexcgJYX_BtlfXzTnDEhjgibgdHoqhT0762v_l7Kg
In order: HDR no tonemapping -- light=250 -- light=500 -- madVR
![Image](https://malzo.com/i/2018/07/08/xqz.th.png)
![Image](https://malzo.com/i/2018/07/08/xqj.th.png)
![Image](https://malzo.com/i/2018/07/08/xqi.th.png)
![Image](https://malzo.com/i/2018/07/08/xqN.th.png)
![Image](https://malzo.com/i/2018/07/08/xq4.th.png)
![Image](https://malzo.com/i/2018/07/08/xqg.th.png)
![Image](https://malzo.com/i/2018/07/08/xq0.th.png)
![Image](https://malzo.com/i/2018/07/08/xqK.th.png)
At light=500, the scene with the turntable looks fine, smooth transition from the brightest center outwards. But then the other scene looks really dark.
For light=250, the results are reverse. In the scene with the turntable, there appears to be a teal blocky boundary (aliasing artifact?) along the contour of the brightest area.
Re: HDR -> SDR tonemapping
3 minutes is great, dmcs. Thanks for the sample. Investigating...
Maybe we need something like madVR's adaptive light setting.
Maybe we need something like madVR's adaptive light setting.
Re: HDR -> SDR tonemapping
@dmcs
Can you tell me how that bigger sample came to be? Is it from a UHD bluray? How was it processed? If it is from a UHD bluray, it would be much better for me to get the m2ts file. One problem with the mkv is that we don't know for sure all the metadata is being preserved.
Can you tell me how that bigger sample came to be? Is it from a UHD bluray? How was it processed? If it is from a UHD bluray, it would be much better for me to get the m2ts file. One problem with the mkv is that we don't know for sure all the metadata is being preserved.
Re: HDR -> SDR tonemapping
Bingo! Pretty sure I've found the problem. I was clipping the out-of-gamut RGB before applying the tonemapping. Duh. Of course we should do it after, because the tonemapping is going to pull lots of super-bright pixels into gamut. After changing this I get good results even with light as bright as light=100. By good I mean the bright blob at frame 2676 does not expand and completely lose its detail. The mobius settings for it are trans=0.8, peak=5.0. They won't help you though until I release the fixed version. I will do that after a little more experimentation.
I said this in reply to Narkyy:
"light = 160 is way too low, in my opinion. Don't blame me for blown out areas with that light setting."
Eating humble pie as Narkyy was right to choose that light level. We can go even brighter without blowing out the highlights with the change described above.
I said this in reply to Narkyy:
"light = 160 is way too low, in my opinion. Don't blame me for blown out areas with that light setting."
Eating humble pie as Narkyy was right to choose that light level. We can go even brighter without blowing out the highlights with the change described above.
Re: HDR -> SDR tonemapping
Yeah, I used MKVToolNix to trim the file from the UHD remux. The mediainfo from the m2ts file and the mkv one are identical.admin wrote: ↑Mon Jul 09, 2018 9:45 am@dmcs
Can you tell me how that bigger sample came to be? Is it from a UHD bluray? How was it processed? If it is from a UHD bluray, it would be much better for me to get the m2ts file. One problem with the mkv is that we don't know for sure all the metadata is being preserved.
m2ts: https://p.teknik.io/Me5TA
mkv: https://p.teknik.io/LU6MD
And boy, am I glad to hear you're figuring things out.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Edit: The only metadata missing from mkv is the Dolby Vision. It's not supported by matroska yet.
Re: HDR -> SDR tonemapping
Now I've figured out the cause of the blockiness compared to the original and madVR. I was always clipping R/G/B < 0.0 to 0.0. I need to tonemap them back into 709 range also instead of just clipping them.
@dmcs
Is this sample known to be Dolby Vision?
@dmcs
Is this sample known to be Dolby Vision?