HDR -> SDR conversion
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
Re: HDR -> SDR conversion
You're right, though not everyone likes using SDR as "source" for HDR tonemapped content.
Neither look like SDR in terms of colors, in scenes where red is prominent.
What's objectively different though, is the level of details retained in those high saturation/hue areas.
They seem to get blurred and grain lost.
![Image](https://thumbs2.imgbox.com/a6/a5/844pV5SO_t.png)
Frame 42.
Sample: https://mega.nz/#!MctgWKRR!5ZaekqyMeKK6 ... R8Rrmxrabk
Also for some odd reason, every time I generate a new frame the detail is shifted above the right eye.
Though I'm not sure it's something possible to improve, thank you![grateful :salute:](./images/smilies/icon_salute.gif)
Neither look like SDR in terms of colors, in scenes where red is prominent.
What's objectively different though, is the level of details retained in those high saturation/hue areas.
They seem to get blurred and grain lost.
![Image](https://thumbs2.imgbox.com/23/8c/xFybhVVG_t.png)
![Image](https://thumbs2.imgbox.com/a6/a5/844pV5SO_t.png)
Frame 42.
Sample: https://mega.nz/#!MctgWKRR!5ZaekqyMeKK6 ... R8Rrmxrabk
Also for some odd reason, every time I generate a new frame the detail is shifted above the right eye.
![Thinking :scratch:](./images/smilies/icon_scratch2.gif)
Though I'm not sure it's something possible to improve, thank you
![grateful :salute:](./images/smilies/icon_salute.gif)
Re: HDR -> SDR conversion
When I refresh in AvsPmod (so it does all the processing again and outputs the same frame), the image isn't identical as it was before.
Which is supposed to be expected?
I just tested it again on madVR and it seems indeed to be caused by the setting "restore details in compressed highlights", which also changes the red to purple in this sample.
No idea what happens behind the option though.
DGHDRtoSDR is still noticeably smoother, especially if you compare the right eye.
And I can't find a setting that makes madVR closer.
Example, in order: v1.7 | madVR | madVR restore details in compressed highlights
![Image](https://thumbs2.imgbox.com/cb/bb/U10p5NrC_t.png)
So v1.7 is actually spot on here, except for the middle of the face where's it's not blending with the colors and clipping is noticeable on the edges.
Tried old DGReinhard/DGHable and HDRTools, all look worse so madVR might just be doing something funky.
The detail is definitely there though.
Which is supposed to be expected?
I just tested it again on madVR and it seems indeed to be caused by the setting "restore details in compressed highlights", which also changes the red to purple in this sample.
No idea what happens behind the option though.
DGHDRtoSDR is still noticeably smoother, especially if you compare the right eye.
And I can't find a setting that makes madVR closer.
Example, in order: v1.7 | madVR | madVR restore details in compressed highlights
![Image](https://thumbs2.imgbox.com/f6/e0/JzQTJCmB_t.png)
![Image](https://thumbs2.imgbox.com/05/56/yyPMY1Dx_t.png)
![Image](https://thumbs2.imgbox.com/cb/bb/U10p5NrC_t.png)
So v1.7 is actually spot on here, except for the middle of the face where's it's not blending with the colors and clipping is noticeable on the edges.
Tried old DGReinhard/DGHable and HDRTools, all look worse so madVR might just be doing something funky.
The detail is definitely there though.
Re: HDR -> SDR conversion
MadVR has a boatload of "picture improvement" features. For an Avisynth filter I prefer to give the plain vanilla SDR conversion and allow the user to do any desired post-processing using Avisynth filters.
I've run DGHDRtoSDR on many of the Masciola test patterns and I don't see any issues other than the slight desaturation that can be easily corrected if desired with the sat parameter. So at this point, I consider that I have met my design goals for this filter and it is ready for serious use.
The current design is actually totally ignorant of the 709 gamut boundary! I am working for fun and learning on a version that explicitly uses the gamut boundaries. Here is a picture of the two gamuts for green. White is the larger 2020 gamut (shown as all white because 2020 colors cannot be displayed on a 709 monitor), green is the 709 gamut. The y axis is lightness and the x axis is saturation. These gamuts were obtained by Monte Carlo sampling of the lightness/saturation space with a fixed hue.
My idea is to do 2D warping to transform the 2020 gamut to the 709 gamut, using a sparse warp representation consisting of a set of corresponding points (vertices and other points on the gamut boundaries). This warping will define the transformation of lightness and saturation for each 2020 color. The hue space will be sampled at (say) 1 degree intervals.
http://groups.csail.mit.edu/graphics/cl ... orph_6.pdf
I've run DGHDRtoSDR on many of the Masciola test patterns and I don't see any issues other than the slight desaturation that can be easily corrected if desired with the sat parameter. So at this point, I consider that I have met my design goals for this filter and it is ready for serious use.
The current design is actually totally ignorant of the 709 gamut boundary! I am working for fun and learning on a version that explicitly uses the gamut boundaries. Here is a picture of the two gamuts for green. White is the larger 2020 gamut (shown as all white because 2020 colors cannot be displayed on a 709 monitor), green is the 709 gamut. The y axis is lightness and the x axis is saturation. These gamuts were obtained by Monte Carlo sampling of the lightness/saturation space with a fixed hue.
My idea is to do 2D warping to transform the 2020 gamut to the 709 gamut, using a sparse warp representation consisting of a set of corresponding points (vertices and other points on the gamut boundaries). This warping will define the transformation of lightness and saturation for each 2020 color. The hue space will be sampled at (say) 1 degree intervals.
http://groups.csail.mit.edu/graphics/cl ... orph_6.pdf
Re: HDR -> SDR conversion
Is it possible to have your plugin not take everything straight to 8bit? Like a bits="10" command or something?
Re: HDR -> SDR conversion
Again, what is the use case? And how would you do things if this change did not exist?
Re: HDR -> SDR conversion
Probably better compression with 10 bit encoders, as plain 8 bit looks worse on my observation. Tested with 16 bit output, 10 bit output and dithered 8 bit output. 16 is bloat, 10 is fine and 8 kind of bit-starved. Well, it's possible to get acceptable results with 8 bit, just need to rise bitrate a bit.
PC: RTX 2070 | Ryzen R9 5950X (no OC) | 64 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Re: HDR -> SDR conversion
Down converting to 8bit causes banding. You can't just up convert back to 10/16 and its fixed.. the data is lost. A plugin would be required to fix the banding.
Can't encode in 10bit basically. Properly.
Re: HDR -> SDR conversion
Again, how would you do things if this change did not exist? Do you have an existing or alternative process?
Look, I don't want to spend time on things and find it is not what you need. You are asking for the filter to just convert from 2020 to 709 and PQ to gamma, and do nothing with the HDR? When you talk about eliminating banding, I think of the extra bits being used for granularity and not for HDR. I have never done any 10-bit encoding so I do not know the use case and/or exactly what you are looking for. This is why I ask for your alternative process.
Look, I don't want to spend time on things and find it is not what you need. You are asking for the filter to just convert from 2020 to 709 and PQ to gamma, and do nothing with the HDR? When you talk about eliminating banding, I think of the extra bits being used for granularity and not for HDR. I have never done any 10-bit encoding so I do not know the use case and/or exactly what you are looking for. This is why I ask for your alternative process.
Re: HDR -> SDR conversion
Here's where I am confused about your request...
The extra two bits can be used to represent a dynamic range increased by 4 times, i.e., we can now represent a ratio between the darkest and lightest 4 times greater. Or we can keep the 8-bit dynamic range and increase the granularity of that range with the extra two bits. If our source is using the bits exclusively for HDR then keeping it as 10 bits doesn't improve the granularity. What is the trade-off on a HDR10 bluray? I have no idea and it's not clear to me at all that retaining 10-bits necessarily means that we retain granularity that would be missed if we output 8 bits.
If you can show an alternative process (that is, one with existing tools) that manifestly reduces banding for a HDR10 bluray rip by retaining 10 bits compared to outputting 8 bits then I would have something to go on in terms of engineering a useful solution for your request.
The extra two bits can be used to represent a dynamic range increased by 4 times, i.e., we can now represent a ratio between the darkest and lightest 4 times greater. Or we can keep the 8-bit dynamic range and increase the granularity of that range with the extra two bits. If our source is using the bits exclusively for HDR then keeping it as 10 bits doesn't improve the granularity. What is the trade-off on a HDR10 bluray? I have no idea and it's not clear to me at all that retaining 10-bits necessarily means that we retain granularity that would be missed if we output 8 bits.
If you can show an alternative process (that is, one with existing tools) that manifestly reduces banding for a HDR10 bluray rip by retaining 10 bits compared to outputting 8 bits then I would have something to go on in terms of engineering a useful solution for your request.
Re: HDR -> SDR conversion
I was under the impression that the DGHDRtoSDR plugin automatically converted everything to 8bit. Is this not true?
Re: HDR -> SDR conversion
![Thinking :scratch:](./images/smilies/icon_scratch2.gif)
If you ever become properly responsive I'll reconsider your request but until then forget it. You could start by demonstrating a HDR10 disk rip that shows banding after converting with DGHDRtoSDR.
Re: HDR -> SDR conversion
I'm in favor of just having the option to output as YUV420P16 too, it might be affecting the sharpness as well, from tests with HDRTools.
Build from latest code change and example script:
I tested with OutputMode=2 and OutputMode=0, so YV12 and YV24 respectively and here are the results.
![Image](https://thumbs2.imgbox.com/b6/13/Pyd8CqDc_t.png)
YV24 is retaining much more details, and I'm thinking this is where DGHDRtoSDR loses them as well.
Though YV12 is still YUV420P16 so I'm not sure how the detail reappears with YUV444P16, since the source is 4:2:0
Build from latest code change and example script:
Specifically this part: ConvertXYZtoYUV(Color=2, OutputMode=2, pColor=1)FFVideoSource("sample5.mkv", colorspace="YUV420P10")
ConvertBits(16).ConvertYUVtoXYZ(Color=0,OutputMode=1).ConvertXYZ_HDRtoSDR(MinMastering=1, MaxMastering=1000,Coeff_X=30, Coeff_Y=30, Coeff_Z=30).ConvertXYZtoYUV(Color=2, OutputMode=2, pColor=1)
I tested with OutputMode=2 and OutputMode=0, so YV12 and YV24 respectively and here are the results.
![Image](https://thumbs2.imgbox.com/e7/96/AQ4H4HFv_t.png)
![Image](https://thumbs2.imgbox.com/b6/13/Pyd8CqDc_t.png)
YV24 is retaining much more details, and I'm thinking this is where DGHDRtoSDR loses them as well.
Though YV12 is still YUV420P16 so I'm not sure how the detail reappears with YUV444P16, since the source is 4:2:0
Re: HDR -> SDR conversion
YV12 is not YUV420P16, though it can be stored that way (8 bits are wasted). The source is 4:2:0 so saving it as 4:4:4 cannot retain extra source detail.
Dion is asking for me to output YUV420P16. I am asking for it to be justified with evidence. Talking about 4:4:4 is not germane to that. Can you output YUV420P16 with 10-bit data from HDRTools?
Dion is asking for me to output YUV420P16. I am asking for it to be justified with evidence. Talking about 4:4:4 is not germane to that. Can you output YUV420P16 with 10-bit data from HDRTools?
Re: HDR -> SDR conversion
In the case of HDRTools, YV12 is YUV420P16. I know it's not usually.
The source is 4:2:0 so I can't grasp how it looks much better when ending in 4:4:4, looks just like madVR but madVR says 4:2:0
As for the banding, I don't think there's a difference between 8 bit and higher as long as there's dithering at the last step.
Compared against everything, banding is just more pronounced with the lighter darks/gamma from DGHDRtoSDR.
The source is 4:2:0 so I can't grasp how it looks much better when ending in 4:4:4, looks just like madVR but madVR says 4:2:0
As for the banding, I don't think there's a difference between 8 bit and higher as long as there's dithering at the last step.
Compared against everything, banding is just more pronounced with the lighter darks/gamma from DGHDRtoSDR.
Re: HDR -> SDR conversion
Where is the evidence of banding? I've asked for evidence and all you guys do is make unsupported claims. Dion just makes useless posts like "I thought this tool outputs 8-bit, am I wrong?"
First you're talking about detail retention now you're talking about banding. Then you talk about 4:4:4 from some other tool. You're starting to irritate me big time.
I hacked a quick version to output the full 10 bits in P16. I open the YV12 and P16 versions in their own VDub2 windows. I see NO difference in detail. I see NO banding in either one. I speculated earlier about the reason but nobody took any notice of it. You seem to have a naive "10-bit good, 8-bit bad" dogma in your heads, and don't think about context.
If you don't substantiate your claims, I'm going to shut down this discussion as it is just FUD at this point. You want to use some other tool, go for it, I don't care. If it's about dithering, then ask for dithering and give a sample that shows that it's needed. Then I will be happy to consider it.
Re: HDR -> SDR conversion
Thought it was common knowledge that banding is caused by the down conversion from a higher bit master to 8bit?
But anyways.. Here is an example of 8bit vs 16bit vs DGHDRtoSDR. I could not use DGHDRtoSDR in this test for 16bit cause I am sure its going straight to 8bit. That is why I asked if that is what your plugin is doing.
8bit vs 16bit vs DGHDRtoSDR
![Image](https://thumbs2.imgbox.com/32/8f/sXKSJUvk_t.png)
![Image](https://thumbs2.imgbox.com/fd/39/LK3MeDx7_t.png)
![Image](https://thumbs2.imgbox.com/73/c5/rPyT4XbJ_t.png)
and for good measure..
16bit to 8bit back to 16bit. Info lost...
![Image](https://thumbs2.imgbox.com/20/47/4FD1WEV7_t.png)
edit: With Narkyy help was able to get HDRTools to work.. It outputs 16bit Tonemapping correctly no banding either.
![Image](https://thumbs2.imgbox.com/c0/c2/9U1BVKKs_t.png)
But anyways.. Here is an example of 8bit vs 16bit vs DGHDRtoSDR. I could not use DGHDRtoSDR in this test for 16bit cause I am sure its going straight to 8bit. That is why I asked if that is what your plugin is doing.
8bit vs 16bit vs DGHDRtoSDR
![Image](https://thumbs2.imgbox.com/32/8f/sXKSJUvk_t.png)
![Image](https://thumbs2.imgbox.com/fd/39/LK3MeDx7_t.png)
![Image](https://thumbs2.imgbox.com/73/c5/rPyT4XbJ_t.png)
and for good measure..
16bit to 8bit back to 16bit. Info lost...
![Image](https://thumbs2.imgbox.com/20/47/4FD1WEV7_t.png)
edit: With Narkyy help was able to get HDRTools to work.. It outputs 16bit Tonemapping correctly no banding either.
![Image](https://thumbs2.imgbox.com/c0/c2/9U1BVKKs_t.png)
Re: HDR -> SDR conversion
Now you're talking, thank you. But I need the source sample and all the scripts to be able to replicate it. What did you use for the first two shots? How did you take the screenshots?
If you give me what I need and the banding is eliminated by outputting 16-bits I'll be happy to add that to the filter. But I have to be able to verify that it is working as intended, and not just blindly release something. So, source sample, scripts, and how did you get the screenshots, please.
If you give me what I need and the banding is eliminated by outputting 16-bits I'll be happy to add that to the filter. But I have to be able to verify that it is working as intended, and not just blindly release something. So, source sample, scripts, and how did you get the screenshots, please.