I currently only have SDR displays but want to futureproof by getting 4k versions of movies from here on out. But my Rpi3 and Odroid N2+ can't do acceptable tonemapping from those versions to my SDR displays.
The Windows version of Kodi offers ACES Filmic and Hable tonemapping which look great to me.
Are there any small standalone devices that can do this? Apparently no ARM device can.
ARM devices can do ACES Filmic and Hable tonemapping, it's just that nobody got round to doing it for v19, it's now been recently added to the code for v20.
Wow that is fantastic news! Is this something I could kludge into my 19.3 Correlec myself?
No the only way to try it now is to find somewhere building from our Master branch to provide v20 test builds. Alternatively as you're a CE user, then perhaps you can ask on their forums if someone would be willing to backport it to v19, it was added in
https://github.com/xbmc/xbmc/pull/20157 if anyone wants to take a look at what's needed.
Thank you so much, I'll give it a shot!
Could this be a viable (and easier) alternative to using madVR and projectors? Was considering getting into madVR, but felt it might be too technical for me to figure out.
It sounds like the OpenGLES support doesn't help out those of us in Coreelec with for example Odroid devices. I'm being told the tonemapping can only be applied with hardware acceleration (amcodec) disabled, and then playback becomes a slideshow.
So I'm back to the original thread question, what is the cheapest device that can use these tonemapping methods? Or can anything short of a PC?
Ah right, I'd forgot that Coreelec haven't made the move to modern methods yet and are still supporting the legacy amcodec only. The RPi4 may possible do it? but haven't got one myself so can't be sure, you could perhaps ask on the RPi support forum if that's a device that would interest you.
As you well may know that's a compromise assumed by the team. You can't have it all. In CoreELEC HDR/HDR10 has been working for more than two years, that's something Kodi in more "modern" methods wasn't capable for a long time. Tonemapping is hit and miss and is always messing with the original picture in a way that we can agree is not always correct. The reality is that HDR is for HDR capable TV's, other than that is a waste of "expensive" storage space.
CoreELEC tries to offer the best Kodi experience and frankly excels in that. Respect and be respected.
Previous HDR>SDR tonemapping methods, including Coreelec's, were not really worth the effort. No one wants to watch a washed out picture with no color. But the new versions, Hable and ACES Filmic, have results that are essentially indistinguishable from native SDR content and I find it hard to believe anyone would even be able to tell which was tonemapped and which was native, much less say the tonemapped one was a "waste".
Storage space is not that expensive and certainly less expensive than replacing every TV (plus projector) in the house with HDR displays, or buying two versions of all media.
And to top it off, much media benefits from HEVC even without HDR, less banding, more grain retention, more transparent to the source overall, but generally you can't get HEVC that isn't HDR.
Coreelec is great, which is why I use it, and would be even better if there is a way to make this work. If there is any device close in price to Odroid N2+ that *will* use Kodi's new tonemapping, I'll be making the switch though.
(2021-11-06, 02:30)vascobraga Wrote: [ -> ]The reality is that HDR is for HDR capable TV's, other than that is a waste of "expensive" storage space.
That's just wrong.
Consider a household that has multiple TV's where the main TV is HDR capable but some of the other TV's may not be. So in a setup with devices running Kodi connected to each TV and media stored on a NAS, then it's much much effiecient to store a single copy suitable for the most capable display on the NAS. So in this case a HDR copy of a movie for the HDR display, then have any Kodi tone map for any SDR displays in the bedroom for example, otherwise you'd need to store both a HDR & SDR copy which would eat up a lot more disk space on the NAS.
(2021-11-06, 13:44)jjd-uk Wrote: [ -> ] (2021-11-06, 02:30)vascobraga Wrote: [ -> ]The reality is that HDR is for HDR capable TV's, other than that is a waste of "expensive" storage space.
That's just wrong.
Consider a household that has multiple TV's where the main TV is HDR capable but some of the other TV's may not be. So in a setup with devices running Kodi connected to each TV and media stored on a NAS, then it's much much effiecient to store a single copy suitable for the most capable display on the NAS. So in this case a HDR copy of a movie for the HDR display, then have any Kodi tone map for any SDR displays in the bedroom for example, otherwise you'd need to store both a HDR & SDR copy which would eat up a lot more disk space on the NAS.
I know, of course, but then you have to factor in the available bandwidth for those other devices.
But that's another question. My main goal is to watch HDR stuff in HDR TV's, for casual movie/tv series watching I tend to use ISA addons like Netflix, HBO and Disney plus.
Quote:Ah right, I'd forgot that Coreelec haven't made the move to modern methods yet and are still supporting the legacy amcodec only.
As a bit of follow-up, this is NOT a Coreelec specific issue:
I installed a Kodi Nexus Android nightly on Amazon Fire 4k, and as with Coreelec on Odroid N2+, tonemapping is only selectable/applicable if all hardware acceleration is turned off in Settings>Player, and then of course 4k playback is a slideshow (the tonemapping is also completely screwed up, whereas it is correct on Coreelec).
Same goes with Libreelec Nexus nightly on Rpi3, all hardware acceleration must be turned off to use tonemapping.
So now I'm curious who/what benefits from the addition of the OpenGLES tonemapping support, if tonemapping is available only in software-only mode on all the devices that use GLES, and none of those are powerful enough to do it in software? Is something not working as it should, or is this just being implemented for as-yet-unreleased GLES devices that are powerful enough?
Well, the silence is revealing.
ARM devices can do ACES Filmic and Hable tonemapping, it’s just that nobody got round to doing it for v19, it’s now been recently added to the code for v20