2018-05-21, 14:32
It is not broken. It is the beginning of something that can be improved. This is the dev section of the forum. Behave like a dev or get lost.
2018-05-21, 16:16
I'm going to chime in whenever anyone does something that goes against all common sense. You can call it whatever you want: broken, non-broken or something that needs improving - but I think you should at least make it a non-default option, not force it to users by being non defeatable.
Converting from an absolute eotf to a relative eotf where the brightness could be anything from 80 to 500nits requires that you can configure the tone mapping. There is no one size fits all that works for all.
Consider that the tone mapping only works with rec.709 primaries makes it essentially useless since all movies use the DCI gamut. The tone mapping needs to be a product of proper color management, it can't be just "tone mapping".
So, at least make the tone mapping defeatable so that we at least can use a proper 3DLUT to convert HDR to SDR. (If we do that now, we get the non defeatable tone mapping on top of that - is that really something you want?)
Converting from an absolute eotf to a relative eotf where the brightness could be anything from 80 to 500nits requires that you can configure the tone mapping. There is no one size fits all that works for all.
Consider that the tone mapping only works with rec.709 primaries makes it essentially useless since all movies use the DCI gamut. The tone mapping needs to be a product of proper color management, it can't be just "tone mapping".
So, at least make the tone mapping defeatable so that we at least can use a proper 3DLUT to convert HDR to SDR. (If we do that now, we get the non defeatable tone mapping on top of that - is that really something you want?)
2018-05-21, 18:03
I'll await your pull request that adds the missing behaviour.
2018-05-21, 18:15
(2018-05-21, 16:16)Soli Wrote: Consider that the tone mapping only works with rec.709 primaries makes it essentially useless since all movies use the DCI gamut.You are wrong here. We convert from whatever the source primaries are to SRGB, which is the only destination color space Linux is currently aware of.
True that there is no one-fits-all and it would be better if this was configurable. Also true that there is only a very small group of users who use 3dlut. Hence the current situation is an improvement for the majority and I'll do all but remove what we currently have.
If you are unhappy, submit your code for review.
2018-07-24, 06:03
The source primaries for sRGB and and Rec.709 are the same. The conversion coefficients for Rec.2020/HDR YPP to RGB conversion values are given, and the resulting RGB values are in the context of rec.2020/HDR primaries no matter what colorspace Kodi or OS is aware of. *Then* you tone and gamut map these values into the context of Rec.709 RGB values which ideally would take into account the transfer function of your display is, or even sRGB since this uses a fixed transfer funtion. It's just math, Kodi or the OS doesn't need to be "aware" of the color space as such.
I'm sorry. I can't submit a PR. I'm not a coder. But all I'm asking is to be able to turn off the tone mapping. (You can even leave it on as default). Maybe the tone mapping will get better in time, but please don't enforce the tone mapping for all users.
I'm sorry. I can't submit a PR. I'm not a coder. But all I'm asking is to be able to turn off the tone mapping. (You can even leave it on as default). Maybe the tone mapping will get better in time, but please don't enforce the tone mapping for all users.
2018-10-08, 19:47
Can I get this straight @FernetMenta ? You are saying you have some software tone mapping in Kodi Leia. But presumably that can only work where you are decoding in software. If you are passing the demux to a hardware decoder like the AML one, your tone mapping will be irrelevant?
2018-10-10, 13:28
(2018-10-08, 19:47)graham-h Wrote: Can I get this straight @FernetMenta ? You are saying you have some software tone mapping in Kodi Leia. But presumably that can only work where you are decoding in software. If you are passing the demux to a hardware decoder like the AML one, your tone mapping will be irrelevant?Wrong. We have ton mapping for Windows and OpenGL. hw decoders like DXV2 (win), vaapi, vdpau, or vtb - that interact with OpenGL - work fine.
2018-11-17, 23:29
Dear Friends
It would be great to have functionality of madVR for HDR to SDR on Kodi too. I used madshi madVR for a long time with very good results. I own NVIDIA SHIELD with Kodi and lots backups of my UHD physical discs. I also have got SDR projector and all movies looks washed outlet of colors. To have a good result there should be disabled Mediacodec and Mediacodec Surface in Kodi settings to have a proper conversion, but playback isn't smooth, it's very choppy.
Nobody can resolve this issue so far, sadly...
Sincerely
It would be great to have functionality of madVR for HDR to SDR on Kodi too. I used madshi madVR for a long time with very good results. I own NVIDIA SHIELD with Kodi and lots backups of my UHD physical discs. I also have got SDR projector and all movies looks washed outlet of colors. To have a good result there should be disabled Mediacodec and Mediacodec Surface in Kodi settings to have a proper conversion, but playback isn't smooth, it's very choppy.
Nobody can resolve this issue so far, sadly...
Sincerely
2018-12-16, 18:19
I don't think the Shield supports HDR to SDR. But Linux and Windows already do. I can barely run madVR's tone mapping on a GTX 1050Ti. That kind of processing wouldn't work for Kodi. The existing tone mapping in Kodi probably already does a reasonable job. You just need to use a supported platform.
