awawa-dev / HyperHDR

Highly optimized open source ambient lighting implementation based on modern digital video and audio stream analysis for Windows, macOS and Linux (x86 and Raspberry Pi / ARM).
http://www.hyperhdr.eu/
MIT License
973 stars 105 forks source link

HDR to SDR tone mapping via protocol buffers #263

Closed flos06 closed 2 years ago

flos06 commented 2 years ago

Feature request

HDR to SDR tone mapping is available via flatbuffers. I would like to use it via proto buffers

What problem does this feature solve?

My grabber can only use proto buffers

What does the proposed API look like?

How should this be implemented in your opinion?

Are you willing to work on this yourself?

I would love to if I knew how

awawa-dev commented 2 years ago

I see that hyperion-android-grabber developers successfully defend themselves against flatbuffer implementation ;) And it would require a lot less of work than duplicating behavior of flatbuffer (it supports hdr tone mapping) in HyperHDR. Personally I'm not interested in supporting Hyperion's apps but I think it wouldn't be a great challenge to swap protobuf for flatbuffers in that app. Both are well supported by Google. Protobuf currently is on its way out and probably it will be removed in the next version.

flos06 commented 2 years ago

I see that hyperion-android-grabber developers successfully defend themselves against flatbuffer implementation ;) And it would require a lot less of work than duplicating behavior of flatbuffer (it supports hdr tone mapping) in HyperHDR. Personally I'm not interested in supporting Hyperion's apps but I think it wouldn't be a great challenge to swap protobuf for flatbuffers in that app. Both are well supported by Google. Protobuf currently is on its way out and probably it will be removed in the next version.

Yes I have indeed asked over there if they would be willing to implement flatbuffers. I would like to give it a shot myself, but unfortunately I only have a very rudimentary understanding of programming and 0 experience with either flatbuffers or protobuffers. I can change the scheme around but thats about it. I'll try to read up about both to see if I can maybe hack something together myself. But I'm not giving myself a lot of chance unfortunately. Anyways. Thanks for your amazing work and for your reply.

awawa-dev commented 2 years ago

I found a fairly simple workaround how to redirect protocol buffers stream to flatbuffer instance for HDR tone mapping. Flatbuffer server and its HDR tone mapping option must be enabled for this to work. Let me know if it works also on your system.

flos06 commented 2 years ago

I will try this tomorrow! Thanks for your effort!

flos06 commented 2 years ago

I can confirm this works on my system! Thank you very much for implementing this. One more question. Am I correct in understanding it works for HDR10 but not for Dolby Vision? (I don't really mind just wondering if I have to take it into account when choosing a video source)

awawa-dev commented 2 years ago

HDR10 for sure. Are you able to capture Dolby Vision? Support for proper capturing this format is almost none and I've heard just about one limited success (captured image far from perfect) which used TV apis but it's not available anymore because of newer TV firmware. Even HDFury diva handles LLDV.

flos06 commented 2 years ago

I mean it captures an image. However the colors are inaccurate. I.e. Red becomes purple. It was the same for HDR10 prior to your latest commit which fixed the inaccuracies with HDR10, but not for DV.

awawa-dev commented 2 years ago

If the DV image is all purple (common effect) then it's not properly captured and damaged. Otherwise you can experiment with creating your own LUT table to fix colors.

flos06 commented 2 years ago

It's not all purple, but there is a lot of purple. Probably not properly captured. I'm happy with HDR10 though :) Would HDR10+ give the same issues as DV?

awawa-dev commented 2 years ago

Didn't tested HDR10+. Probably the image won't be distorted like DV but there is new dynamic scene luminescence that could be used and in that case it may affect the capturing quality.

awawa-dev commented 2 years ago

Hi @flos06 Could you test the version from the latest build? Installers are here: https://github.com/awawa-dev/HyperHDR/actions/runs/2387646416 I migrated from protobuf libraries to nanopb and that little library handles now the protobuffer stream. Tested with DirectX Screen Grabber and it works for proto after the migration. So it leaves only hyperion-android-grabber for testing. If everything will be OK then protobuf server could stay in HyperHDR as nanopb is much nicer and lightweight.

flos06 commented 2 years ago

Hi, I will have time to test sometime this week and will let you know the result :)

flos06 commented 2 years ago

Unfortunately at the moment my LEDS do not light up at all. Doesn't seem to be a power supply issue so it may be that my LED strip has died. Trying to figure it out. But will not be able to test for a while if the LED's are actually dead.

HyperHDR does seem to detect the LED device so im unsure if that means the LED's are still working but simply not receiving input

awawa-dev commented 2 years ago

No problem. I've managed to already test it using one old Android device.

flos06 commented 2 years ago

a bit late, but I can confirm this works thanks :)