HDR tone mapping for flatbuffers #215
Conversation
chbartsch
changed the title
|
Hi |
|
awawa-dev
force-pushed
the
flatbuffers-with-tone-mapping
branch
from
8e9e5f1
to
88054d0
Compare
|
I fixed the commit tree. Should be OK now. I need apply some other minor fixes from my branch (missing include on macos, unnecessary activation of HDR if its disable for flatbuffers, move translation items on the end of file for automatic google translator) and test it on other systems. |
awawa-dev
force-pushed
the
flatbuffers-with-tone-mapping
branch
from
f4f39d7
to
37a5b38
Compare
awawa-dev
force-pushed
the
flatbuffers-with-tone-mapping
branch
from
410aeda
to
8b72ac1
Compare
Hey, thanks for fixing the stuff! I was kind of aware of the global HDR switching flatbuffers HDR regardless of it's HDR setting. I was just not sure how this is or should be handled with USB grabber. Maybe introduce a seperate JSON-API-Endpoint for flatbuffers HDR? |
|
Oh, just realized that you already merged it.. :) |
|
Yes, it's merged. Already tested it and works fine - thank you. Global HDR switch activate/disactivate flatbuffer tone mapping now but only when the flatbuffer's tone mapping option is enabled. |
|
Very nice! Thanks!! |
|
Hi @chbartsch Since HyperHDR can run now on LG webOS with the minimal setup and with the latest commit it also support Unix Domain Socket (QLocalSocket), could you consider to implement local socket in your unicapture branch? The performance should be great and there is no need for direct connection between HyperHDR and local libraries. |
|
Hi @awawa-dev, first things first: 'unicapture' is not my branch but Infowski's (openlgtv discord). I just added some small parts into it. Then I made a branch for the HyperHDR-Auto-Switching which is based on unicapture. Regardless, I could setup another branch and try to support unix sockets. Do you plan to integrate building of HyperHDR for LG into github CI? |
|
Thank you @chbartsch for the clarification. |
|
I used this NDK: https://github.com/webosbrew/meta-lg-webos-ndk and build it on Linux using vscode: https://github.com/webosbrew/meta-lg-webos-ndk#vs-code But how did you build HyperHDR for webOS then? |
|
I didn't build it myself ;) For HyperHDR you will probably need this: https://github.com/openlgtv/buildroot-nc4/releases (arm-webos-linux-gnueabi_sdk-buildroot.tar.gz ) I thing I've got it now, can be use for building of HyperHDR & your branch. Will prepare github CI script for the branch. |
|
OK, unicapture migrated to the new toolchain. Must test it later: |
|
Very nice. Maybe I will find time over the weekend to try building hyperhdr for webOS. |
No luck unfortunately. I'm able to build capturing-webos with this SDK but not HyperHDR. Have you managed to do so? Any advise on how to? |
How do you invoke cmake to configure build of HyperHDR and what's in the problematic output? |
$ cmake -DCMAKE_TOOLCHAIN_FILE=/opt/arm-webos-linux-gnueabi_sdk-buildroot/share/buildroot/toolchainfile.cmake -DCMAKE_BUILD_TYPE=Release ..
-- CMake Version: 3.16.3
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Check for working C compiler: /opt/arm-webos-linux-gnueabi_sdk-buildroot/bin/arm-webos-linux-gnueabi-gcc
-- Check for working C compiler: /opt/arm-webos-linux-gnueabi_sdk-buildroot/bin/arm-webos-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/arm-webos-linux-gnueabi_sdk-buildroot/bin/arm-webos-linux-gnueabi-g++
-- Check for working CXX compiler: /opt/arm-webos-linux-gnueabi_sdk-buildroot/bin/arm-webos-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at CMakeLists.txt:28 (message):
Found CCache but env settings: CCACHE_DIR is not set. Skipping.
-- QT version 6 not found. Searching for QT version 5 instead.
-- Found Qt Version: 5.15.2
-- Debian version:
-- PLATFORM is not defined, evaluated platform: rpi
-- PLATFORM: rpi
CMake Error at CMakeLists.txt:158 (message):
GLdispatch library not found. Install libglvnd-dev
-- Configuring incomplete, errors occurred!I already don't know what |
|
PLATFORM is OK. But probably it won't compile anyway if you build it on x64 because of flatbuffer compiler, unless you build it for x64 manually. It's recommend to build it in the modified HyperHDR github action (one of matrix is using QEMU docker aarch64 image so it avoids that problem). Other options to consider: -DENABLE_V4L2=OFF -DENABLE_SOUNDCAPLINUX=OFF -DENABLE_SPIDEV=OFF -DENABLE_BOBLIGHT=OFF -DENABLE_AVAHI=OFF that line (CMakeLists.txt:158) can be commented out or you can change PLATFORM to linux (but then it's neccesery to SET ( DEFAULT_X11 OFF ) in line 79 |
|
I've managed to compile it also on x64. You also need to set CMAKE_TOOLCHAIN_FILE for your path and install flatbuffers compiler on your host (sudo apt install flatbuffers-compiler) That's all.
After the weekend of piccap testing I have seriously doubts: the performance(lag) in significant worse than setup based on fast USB grabber. The LED is behind the LEDs about 0.5 second despite using low res setting (180x90 which results in "pixelize" visible during motion on LEDs, I have 96LEDs/meter strip). Both LG and Rpi were connected using LAN cables so it's rather capturing problem/characteristic. Only libdile_vt worked and despite promised 60FPS I only received 30FPS. But I think colors reproduction with LUT table (was updated today again, there were too much red for my taste) is great. |
Ah OK, I would have though using a toolchain would defeat the need of compiling on the target platform. But wait, is the image |
I'm somewhat confused about the setups your are talking about/comparing here. So USB Grabber is faster then piccap in your case? I only see a tiny lag in my setup. But this is with "external" HyperHDR and WLED via Wifi at the moment. So i think the tiny lag I'm seeing is mostly from the Wifi connection to the WLED device. Then you say "LG and Rpi". What is the Rpi actually doing here after HyperHDR runs on the TV? |
|
With Ezcap 321 I don't have any lag (confirmed by capturing tv/led reaction using high-framerate recording using phone). With piccap the lag is very annoying on C9. Maybe because I've got reference from other fast system and I'm sensitive to this delay. Since my LED strip is not capable to be driven remotly (I'm not using WLED or something similar) the piccap was tested using classic configuration: piccap on LG and flatbuffer client on Rpi. Because only cable connection was used for such low resolution I doubt it's a communication problem. Maybe it's specific for C9, who knows. After I committed latest changes, it took me also some time to gather all necessary libraries to run HyperHDR (compiled on x64) on webOS. But hey, seems it's working: |
|
FYI, modified the backend and unix domain socket works just fine now. |
|
Hi awawa, in the meantime I was able to build HyperHDR for WebOS. Just had to use the libs (QT stuff and so on) provided by https://www.dropbox.com/s/zdxchc7uobf9j3g/HYPERHDR%26backendsHDR_ENG.pdf?dl=0 package. Since the install packages above still use Flatbuffers and your backend repo seams to be gone: Is the unix socket approach dead now? |
|
Hi HyperHDR can run without some of the libraries from the collection and without some quirks (it's made for Hyperion) but its not a big problem. I've archived the patches with modified backend using local sockets, it was tested and it's working (at least mainline, unicaptures could not be tested because it refused to screencapture a valid frame but it's the same socket routine) and can be provided but as I remarked I prefer it to be maintain outside the HyperHDR. |
|
OK, thanks for the clarification. There are more people on the openlgtv discord having problems with latest unicapture on C9 TVs I think. But if you're happy with your USB-capture setup so be it. ;) I don't think unix socket will do much (if any) to the latency so it's not super urgent to me at the moment. I'm currently occupied with other projects - maybe will come back to it later.. |
* intermediate state * loading lut table works * introduced flatbuffers tone mapping setting * set tone mapping with global switch * cleanup * account for OS dependent LUT file paths * cleanup * rebased * fixes * fix flatbuffer server activation Co-authored-by: Awawa <mail4awawa@gmail.com>
Windows/Unix domain sockets offer much higher performance than TCP, can be used by external grabbers Local server name is: hyperhdr-domain awawa-dev#215 (comment)
Summary
Introduces HDR tone mapping for flatbuffers input.
In some cases (depending on TV modell / capturing library in use) PicCap (Hyperion Sender App on LG TVs) is sending dim/pale images when HDR/Dolby Vision content is playing. Tone mapping helps to get this image data back to "normal".
What kind of change does this PR introduce? (check at least one)
If changing the UI of web configuration, please provide the before/after screenshot:
Before:
After:
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing setups:
The PR fulfills these requirements:
Fixes: #xxx[,#xxx], where "xxx" is the issue number)If adding a new feature, the PR's description includes:
PLEASE DON'T FORGET TO ADD YOUR CHANGES TO CHANGELOG.MD
To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.
Other information: