HDR -> SDR conversion
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.
Re: HDR -> SDR conversion
Thanks for your comment, Dion. I would clarify that I am not seeking perfection.
Re: HDR -> SDR conversion
I find that I need sat=1.33 to match the madVR result for the red dress scene you are focused on. Here are my settings:
dghdrtosdr(sat=1.33,light=500,tm=0.9,roll=0.5)
Comparing this to madVR, I see no significant difference and nothing that motivates me to change anything. If you disagree please offer some objective evidence. Keep in mind that we will never achieve bit-for-bit identity.
Re: HDR -> SDR conversion
Yes it does blend better, but then the color is not quite right.
It's more orange with saturation instead of a dark purplish red like it is already without adjusting saturation.
Made this to show more clearly.
1.7 is without saturation adjustment.
To me, there's a definite desaturation or hue change in the areas pointed by arrows and contained in lines drawn.
The arm isn't as purple, the bottom of the dress isn't as red, the background isn't as purple.
Some areas like the waist line looks fine, so it's like the darker red hue isn't on the entirety of the dress and just some parts.
It's also pretty clear to see where the red hue ends and desaturated/lower hue begins.
It's more orange with saturation instead of a dark purplish red like it is already without adjusting saturation.
Made this to show more clearly.
1.7 is without saturation adjustment.
To me, there's a definite desaturation or hue change in the areas pointed by arrows and contained in lines drawn.
The arm isn't as purple, the bottom of the dress isn't as red, the background isn't as purple.
Some areas like the waist line looks fine, so it's like the darker red hue isn't on the entirety of the dress and just some parts.
It's also pretty clear to see where the red hue ends and desaturated/lower hue begins.
Re: HDR -> SDR conversion
It is what it is. There is no way to argue that one is correct and the others are wrong, just as Dion pointed out.
Re: HDR -> SDR conversion
Which is closer to the HDR or SDR (blu ray) source
V1.4, V1.7, MadVR?
No source so it can't be determined
This is starting to be a discussion of which looks better to me on this particular sample
I believe the idea was to have a solution that was good overall with the flexibility to be adjusted for certain cases
No offense meant to anyone, but lets get real
MadVR is good but I don't believe it is perfect either
V1.4, V1.7, MadVR?
No source so it can't be determined
This is starting to be a discussion of which looks better to me on this particular sample
I believe the idea was to have a solution that was good overall with the flexibility to be adjusted for certain cases
No offense meant to anyone, but lets get real
MadVR is good but I don't believe it is perfect either