HDR -> SDR conversion
Re: HDR -> SDR conversion
C'mon Narkyy, I asked you before to explain and not just say "some issues".
And you know I need the script and a source sample to do anything.
And you know I need the script and a source sample to do anything.
Re: HDR -> SDR conversion
My bad, I thought it was obvious, the lighting is all weird on the window side.
The plain white looks like saturation was applied to it and luminance dropped completely.
Sample: https://mega.nz/#!sVtAnAIQ!lOOwvKGOWy-l ... Y9LyzWQmLk
Script
The plain white looks like saturation was applied to it and luminance dropped completely.
Sample: https://mega.nz/#!sVtAnAIQ!lOOwvKGOWy-l ... Y9LyzWQmLk
Script
FFVideoSource("sample.mkv", colorspace="YUV420P10")
ConvertBits(16).DGHDRtoSDR(impl="255", light=150, peak=2)
Re: HDR -> SDR conversion
Thanks. Will look into it.
EDIT: 1.5 temporarily withdrawn.
EDIT: 1.5 temporarily withdrawn.
Re: HDR -> SDR conversion
I've redesigned my gamut mapping and tonemapping. Here is what I am getting for the problematic Narkyy scene with dghdrtosdr(light=150). This is using simple Reinhard tonemapping. I may bring back Mobius but it is currently not behaving as expected. The result looks good to me. Highlights are handled well and artifacting is gone. I have to regression test it on all my other HDR streams.
EDIT: The new method does not require the sat=0.8 tweak but I posted this shot before realizing that and default 0.8 was used. So it may look a bit desaturated.
EDIT: The new method does not require the sat=0.8 tweak but I posted this shot before realizing that and default 0.8 was used. So it may look a bit desaturated.
Re: HDR -> SDR conversion
Neat, bright spots look softer too.
Re: HDR -> SDR conversion
Glad you like it. Actually there is now a tonemapping strength option that allows you to select along a continuum of hard hightlights and soft highlights. This sample is the softest. If you want a little more dazzle from the brights, you can decrease the strength.
Thanks for this sample, Narkyy. It is now one of my go-to HDR torture tests.
Thanks for this sample, Narkyy. It is now one of my go-to HDR torture tests.
Re: HDR -> SDR conversion
Here's 1.5 with the patented Rocky the Squirrel gamut mapping:
http://rationalqm.us/misc/DGHDRtoSDR_1.5.rar
Hammer it with your torture scenes!
http://rationalqm.us/misc/DGHDRtoSDR_1.5.rar
Hammer it with your torture scenes!
Re: HDR -> SDR conversion
It looks much better at handling highlights, plus the "tm" parameter is great.
Noticed some differences with v1.4 again, at this point I compare against madVR but it's getting harder to tell which is supposed to be "correct"
Screenshots in order: v1.4 light=250, v1.5 light=250 tm=0.90, madVR 250 nits
The hue shift seems to be fixed in this sample so that's good. Looking at the red lamps at the top, 1.4 is definitely shifted to the right and looks wider.
The middle of the lights isn't red but it's hard to tell if it's supposed to be, at least from the untonemapped source.
There's a spot of light orange in the sky instead of white, which looks like saturation applied there. There's definitely some banding there in the source itself so that might be the cause?
Otherwise some colors are different, like the blue wavy line at the front of the boat is a bit darker. Not sure if it's a lack of saturation or too much saturation though.
The orange and red stripes in the flag are less saturated as well.
Sample URL: https://mega.nz/#!gZF2FS6a!V4e1acBSNx74 ... tfMlZdTkBc
I'll test other samples where I saw issues before and report back.
Thank you
Edit:
So after some other samples, there's definitely a desaturation of red/orange happening, compared to v1.4 and madVR.
I'm not sure about other colors yet
From another sample, which reveals the same white spot in deep red lights, as well as desaturation and some fine detail smoothing on the left side (our left) of the face that's probably caused by lower gamma/contrast.
Screenshot is from frame 129.
v1.4 has the colors proper, but hue shift all over the place.
In order: v1.4 light=150 peak=2.0, light=150 tm=0.90, madVR 130 nits
Sample #2: https://mega.nz/#!5A8FHJJI!t9NhrAw64prb ... pCKsq0QESU
If you compare with madVR at the edge of red light on the face (especially on the nose), you can see the clipping of color whereas madVR has a roll off to lower saturation.
That might be the same issue as in the bright spots on the metal.
Re: HDR -> SDR conversion
Thanks a million, Narkyy, I'll study it tomorrow as it's getting late here.
Re: HDR -> SDR conversion
Tried the latest version with the same sample I uploaded earlier.
I think the screenshot is pretty much self-explanatory.
Edit:
I also notice the desaturation in version 1.5 (the first 3 sets of screenshots - sample 1). In the 4th set (sample 2), the sky has some strange artifact (?!).
I used Mobius to take screenshots in version 1.4
v1.4 -- v1.5
1st
2nd
3rd
4th
Samples
I think the screenshot is pretty much self-explanatory.
Edit:
I also notice the desaturation in version 1.5 (the first 3 sets of screenshots - sample 1). In the 4th set (sample 2), the sky has some strange artifact (?!).
I used Mobius to take screenshots in version 1.4
v1.4 -- v1.5
1st
2nd
3rd
4th
Samples
Code: Select all
https://mega.nz/#F!BwtXQC4A!r8wPHGJDE4ftwkpzudoVow
Re: HDR -> SDR conversion
I don't do self-explanatory. What is your point?
Re: HDR -> SDR conversion
Re: HDR -> SDR conversion
Ouch. The new method of gamut mapping does constant hue and luminance, but it apparently desaturates too much to pull colors into gamut. I'll continue tweaking to find a reasonable compromise between desaturation and hue shifts.
Thank you for your test results.
Thank you for your test results.
Re: HDR -> SDR conversion
I just made a momentous discovery! With a very simple change to the current design the following is now produced for dmcs's torture frame (light=300). Note the lack of any artifacting or hue change. I have to regression test it with my other samples; if everything is copacetic I'll give you a release.
Hope springs eternal!
Hope springs eternal!
Re: HDR -> SDR conversion
DGHDRtoSDR 1.6:
http://rationalqm.us/misc/DGHDRtoSDR_1.6.rar
Looks pretty good to me. Still ~110fps with i7-7700K + 1080 Ti. Now, splash cold water in my face.
The design is ridiculously simple. I'd be embarrassed to disclose it.
http://rationalqm.us/misc/DGHDRtoSDR_1.6.rar
Looks pretty good to me. Still ~110fps with i7-7700K + 1080 Ti. Now, splash cold water in my face.
The design is ridiculously simple. I'd be embarrassed to disclose it.
Re: HDR -> SDR conversion
Thank you so much for this.
Re: HDR -> SDR conversion
You're most welcome. But I have to say...without dmcs, Narkyy, gonca, and others providing samples and doing testing none of this would be possible. So I am truly indebted to you.
Onward and upward!
Gonna take a timeout to do a little physics now...unless something terrible comes to light with DGHDRtoSDR 1.6.
Onward and upward!
Gonna take a timeout to do a little physics now...unless something terrible comes to light with DGHDRtoSDR 1.6.
Re: HDR -> SDR conversion
I have one question: Does 1.6 resolve the desaturation issue in 1.5? Or should I adjust the "sat" parameter manually?
Thank you.
Thank you.
Re: HDR -> SDR conversion
There should be no desaturation, but you are welcome to boost saturation if you like it that way.
In build 1.5, out-of-gamut (OOG) colors were desaturated (in CIELAB with constant hue and luminance) to put them in gamut, so if the frame has lots of OOG pixels then the overall impression is loss of saturation. Build 1.6 removes that mechanism and works completely differently, that's all I'll say.
Hopefully, we are providing some amusement and distraction for video zealots suffering from the absence of another well-known forum that has been down for quite a while now.
In build 1.5, out-of-gamut (OOG) colors were desaturated (in CIELAB with constant hue and luminance) to put them in gamut, so if the frame has lots of OOG pixels then the overall impression is loss of saturation. Build 1.6 removes that mechanism and works completely differently, that's all I'll say.
Hopefully, we are providing some amusement and distraction for video zealots suffering from the absence of another well-known forum that has been down for quite a while now.
Re: HDR -> SDR conversion
It looks good for the most parts and the results are pretty good
Though now I'm mostly picking at small imperfections I can notice against other algorithms.
I used the madVR settings people seem to agree on for default, somewhere in this discussion: https://www.avsforum.com/forum/24-digit ... st56500902
Screenshots in order: v1.6 light=200 tm=0.90 | HDRTools | madVR 0.92.14 | madVR latest test build
Same sample as earlier, frame 129: https://mega.nz/#!5A8FHJJI!t9NhrAw64prb ... pCKsq0QESU
Numbered the issues I noticed to explain, circled in the first screenshot.
1- The vivid/deep red/purple isn't blending in with the lighter colored skin at the bottom of the neck so it looks weird.
The same thing happens on the forehead, and on the edge of the red hue on the right, next to the ear.
It might blend in better if the left side of the face was more red, like it is on HDRTools and madVR.
2- The bright points there are spot on, a bit softer but a lower "tm" parameter would fix that.
However the saturation (or hue ?) seems a little low. Again, that might be the same saturation issue as on the left side of the face mentioned before, since it's reflecting white light.
3- The left side of the face is less red as mentioned, but it's also a bit smoother compared to madVR.
The fine details seem smoothed out on the cheek.
That might be caused by the Reinhard contrast or gamma but I'm not sure.
Otherwise on the right side of the nose, the red spot under the eye looks as good as latest test build of madVR, so that's very nice.
That's all for now, thank you again
Re: HDR -> SDR conversion
You're welcome and thank you, Narkky, I'll come back to this stuff in a few days.
I do make some tradeoffs for speed and to handle a wide range of scenes decently without massive tweaking, but I'm always willing to try to further improve things.
I do make some tradeoffs for speed and to handle a wide range of scenes decently without massive tweaking, but I'm always willing to try to further improve things.
Re: HDR -> SDR conversion
Narkyy, may I ask you some things?
1. How do you run and obtain snapshots from madVR? I have never run madVR in any way.
2. Is it possible to embed madVR processing in an Avisynth script somehow?
3. How fast is madVR (max frame rate)?
Thank you.
1. How do you run and obtain snapshots from madVR? I have never run madVR in any way.
2. Is it possible to embed madVR processing in an Avisynth script somehow?
3. How fast is madVR (max frame rate)?
Thank you.
Re: HDR -> SDR conversion
Unfortunately madVR is closed source, though I think madshi had intentions to make plugins from the algorithms like SSIM downscaler, tonemapping.
It runs as a rendering engine for media players like MPC-BE, so it does much more than tonemapping but there's nothing for AviSynth so it's a totally different thing.
I just have MPC-BE playing a file, and do the screenshots with that.
It's probably much slower than CUDA, but it's hard to tell exactly because the OSD shows rendering times for everything combined, not just the tonemapping part.
I usually get 15-20ms frame rendering times tonemapping a 2160p clip, so at least 50 fps?
It runs as a rendering engine for media players like MPC-BE, so it does much more than tonemapping but there's nothing for AviSynth so it's a totally different thing.
I just have MPC-BE playing a file, and do the screenshots with that.
It's probably much slower than CUDA, but it's hard to tell exactly because the OSD shows rendering times for everything combined, not just the tonemapping part.
I usually get 15-20ms frame rendering times tonemapping a 2160p clip, so at least 50 fps?
Re: HDR -> SDR conversion
Thanks, Narkky!