I am trying to understand the default_srgb_regamma_lut[] in nvdisp Driver (nvdisp.c).
We have the problem that many pixel values have an error of 1 when we use the HDMI output. But we need to stream bit exact video data. This problem is very similar to Full range RGB strange behavior on Nvidia Jetson AGX Xavier Developer Kit but the solution that worked for them (clear /sys/class/graphics/fb0/device/cmu_enable and set /sys/kernel/debug/tegradc.common/tegra_win.0/degamma/force_user_degamma) leads to even higher errors in our HDMI output frames.
Every channel (R, G & B) shows the same gray level profile:
After adjusting the default_srgb_regamma_lut[] on an empirical basis we eliminated all errors from 207 to 255 but still encounter the errors at the lower gray levels.
Therefore, we need a better understanding of the values in default_srgb_regamma_lut[] to systematically eliminate the remaining errors by adjusting the re-gamma values. Could somebody explain how the hex values in the LUT are interpreted or refer to some documentation?
I just want to clarify what is the exact issue here. It seems you filed some duplicated posts and another one says you still have full range RGB result even after you set it to limited.
Please just give a short description about what is your question/problem here. Is it a color bias or you cannot swtich between full range/limited range?
We don’t guarantee the color shown on the monitor will 100% match the color in the original picture due to the display pipeline has some conversion. You can check the TX2 TRM document for this part.
@kayccc yeah, we are still trying to figure out how the values of default_srgb_regamma_lut[] are interpreted in the driver. Do you have any information/documentation on that? Are the HEX values representing floating point numbers?
@WayneWWW if you are referring to this post, I wanted to share information about my working progress on that color range issue, which I fixed by setting the color range in the configuration file of the X11 window system. I also tried to describe that we encounter a remaining error.
Remaining error after fixing color range issue:
Max. Error = 1
So much for the confusion between this post and the current post. Sorry about that. I hope this helped to clarify my working progress.
Now I will come back to the current issue. Facing the remaining error shown for the red color channel in the image above (error profile for green and blue color channels is identical), we modified the default_srgb_regamma_lut[] and were able to eliminate some of the errors resulting in the following error profile:
This was achieved by adjusting the default_srgb_regamma_lut[] empirically. As one can imagine, this is pretty expensive in labor.
Long story short… To efficiently modify the values of default_srgb_regamma_lut[] we have to understand how the values are interpreted by the DC driver. Can you share some information on how the LUT values are interpreted?
We assume that the HEX values of the LUT represent floating point values and that we encounter the remaining error due to a round-off error when “decoding” the HEX values to floating point.
Another issue is setting the color range in headless mode (X11 window system deactivated). @WayneWWW suggested in this post to use the nvdrmvideosink with set-mode=1 and color-range set to 0 or 1 according to the desired color range. This suggestion didn’t work. There are no changes in the pixel values when switching between the settings nvdrmvideosink set-mode=1 color-range=0 and nvdrmvideosink set-mode=1 color-range=1. When changing the color range in X11 window system the changes are clearly visible and quantifiable when comparing the original frame with the recorded frame. We are recording with Magewell USB Capture HDMI 4K Plus Framegrabber.
Is there another way to set/force the color range in headless mode?
If these are correct, I am just wondering, do you have any Xavier platforms that you can validate the method from above topic is correct for your test pattern?
I am curious about why same LUT table is ok with Xavier but not work on TX2.