HDR -> SDR conversion
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!
Re: HDR -> SDR conversion
In honor of this new version some images
No torture tests, just some "normal, generic" frames to see how it looks in general
Settings are default
First sdr version, then hdr
Thanks for your efforts
No torture tests, just some "normal, generic" frames to see how it looks in general
Settings are default
First sdr version, then hdr
Thanks for your efforts
Re: HDR -> SDR conversion
You're welcome, gonca, and thank you for the test shots.
Re: HDR -> SDR conversion
Looks like that confirms what I noticed, reds aren't as saturated/deep as they should be.
Even 1.4 was better I think, though it has a ton of hue shifts.
I tried increasing saturation but it didn't get as deep of a red hue.
In order: v1.4 light=200 peak=2.0 | v1.6 light=200 tm=0.90 | madVR latest test build
Screenshot is frame 99.
Another sample with more obvious differences, for good luck: https://mega.nz/#!VBsygYaI!2l_qaVWLkFgD ... Bd4nrLPjA8
No hurry though, it's already great
Even 1.4 was better I think, though it has a ton of hue shifts.
I tried increasing saturation but it didn't get as deep of a red hue.
In order: v1.4 light=200 peak=2.0 | v1.6 light=200 tm=0.90 | madVR latest test build
Screenshot is frame 99.
Another sample with more obvious differences, for good luck: https://mega.nz/#!VBsygYaI!2l_qaVWLkFgD ... Bd4nrLPjA8
No hurry though, it's already great
Re: HDR -> SDR conversion
I confirm the reported desaturation and have found a simple way to avoid it. Just have to regression test it on all my samples then I'll give y'all a build. While still not counting chickens, I think y'all will be very happy with it.
@gonca
Can I please have the source sample for that shot of the blonde girl with colored streaks? Thank you.
@gonca
Can I please have the source sample for that shot of the blonde girl with colored streaks? Thank you.
Re: HDR -> SDR conversion
Here is build 1.7. It adds a new parameter 'roll' that controls the retention of saturation and contrast. Please see the user document for details. With roll=0.5 (default), the desaturation is cured. The default for light was changed to 300 to compensate for the greater brightness of roll=0.5. If you set roll=1.0 it will be equivalent to build 1.6. As always, your feedback will be greatly appreciated.
http://rationalqm.us/misc/DGHDRtoSDR_1.7.rar
I'm really happy with this build and I hope y'all are too. I'm amazed that such a simple algorithm could perform so well. You would be truly shocked at how simple it is! Don't forget, Einstein said: make things as simple as possible but no simpler. It seems that, thanks in large part to your testing, samples, and advice, we've hit a pretty good sweet spot in that regard. Now, bring on the cold water.
http://rationalqm.us/misc/DGHDRtoSDR_1.7.rar
I'm really happy with this build and I hope y'all are too. I'm amazed that such a simple algorithm could perform so well. You would be truly shocked at how simple it is! Don't forget, Einstein said: make things as simple as possible but no simpler. It seems that, thanks in large part to your testing, samples, and advice, we've hit a pretty good sweet spot in that regard. Now, bring on the cold water.
Re: HDR -> SDR conversion
I assume you means the clip (dumb question, long day at work )Can I please have the source sample for that shot of the blonde girl with colored streaks? Thank you.
I will prep it and upload it
Do you want it on your FTP server or my file sharing account?
Re: HDR -> SDR conversion
v1.7 and roll doesn't seem to have the desired effect..
The colors don't seem to be changing, it's just getting brighter.
Since switching to Reinhard, the contrast has been off as well. Everything looks duller, more grey.
Order: v1.4 | v1.7 light=500 roll=0.5 | madVR
The circled parts on the dress aren't as red as they're supposed to be, like 1.4 and madVR.
The wall is going grey instead of keeping the red color.
v1.4 had it right except for the highlight issues and random hue shifts.
Basically the whole contrast of dark/bright is low so everything looks boring is what I assume.
The colors don't seem to be changing, it's just getting brighter.
Since switching to Reinhard, the contrast has been off as well. Everything looks duller, more grey.
Order: v1.4 | v1.7 light=500 roll=0.5 | madVR
The circled parts on the dress aren't as red as they're supposed to be, like 1.4 and madVR.
The wall is going grey instead of keeping the red color.
v1.4 had it right except for the highlight issues and random hue shifts.
Basically the whole contrast of dark/bright is low so everything looks boring is what I assume.
Re: HDR -> SDR conversion
I'll look into it. It can be hard to distinguish brightness from saturation differences. I'll break on strategic pixels and get an objective comparison of 1.4 versus 1.7.
BTW, why do you find the sat adjustment not helpful?
Re: HDR -> SDR conversion
Are you planning on bringing back Mobius in future builds?
Re: HDR -> SDR conversion
It's not that the sat parameter isn't good, it's just not enough to get colors close to v1.4 and madVR even with sat=1.25.
Also the issue seems to affect only red, the rest looks just as good.
So I'm thinking it's more related to the new Reinhard contrast and the hue on red areas rather than just saturation.
Re: HDR -> SDR conversion
You should have the clip now
Re: HDR -> SDR conversion
You guys are trying to solve a tonemapping problem that cannot be solved. We cannot see what an UHD clip is suppose to look like because we don't have the proper display for it. What we have is a glimpse of it atm.
Should just include all the tonemapping algorithms in the dll and let people choose what they want to use.. Cause there is no "CORRECT" answer or pick one for your liking and be done with it. Since tonemapping is done on a per display bases.. I think just including a bunch the best option.
Either way your work on this is incredible.. More then I have seen from anyone including the madVR guy.
Should just include all the tonemapping algorithms in the dll and let people choose what they want to use.. Cause there is no "CORRECT" answer or pick one for your liking and be done with it. Since tonemapping is done on a per display bases.. I think just including a bunch the best option.
Either way your work on this is incredible.. More then I have seen from anyone including the madVR guy.