(Re-)Gamma LUT in nvdisp

Hi,

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.

For testing we use this RGB24 image:

Every channel (R, G & B) shows the same gray level profile:
profile_1_red

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.
1_red_profile3

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?

Any help is appreciated!

Best regards
Bruno

Sorry for the late response, is this still an issue to support? Thanks

Hi,

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.

Hi,

@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:
profile_1_red

  • 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:
1_red_profile3
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?

Best regards
Bruno

Hi,

My suggestion is you should file topics separately if they are different issue.

For example, headless issue is different from X11 case, then you should file a topic says drmsink is not able to switch between full /limited range.

As for current issue, please help confirm if my understanding to the situation is correct or not

  1. You are using full range mode in X11.

  2. You see color bias between the screen capture result with the original raw picture. Which is similar to Full range RGB strange behavior on Nvidia Jetson AGX Xavier Developer Kit

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.

Hi @WayneWWW ,

understood. I will post separate topics for the other issues and will keep that in mind for future posts/issues.

Yes, you have a correct understanding of the situation.

Unfortunately, we do not have any Jeton Xavier devices :-/

Do you have any documentation regarding the interpretation of the values of the LUT? Are they floating point values encoded into HEX values?

Best regards
Bruno

Sorry that we don’t have document for this. Only the TX2 TRM for now.

Hi @WayneWWW ,

alright. No problem. I will try to extract the information from Code and TRM. Thanks for the support!

Update:

Disabling the CMU with the command from Full range RGB strange behavior on Nvidia Jetson AGX Xavier Developer Kit

echo 0 | sudo tee /sys/class/graphics/fb0/device/cmu_enable

eliminated all errors except the gray value with index 0 (black). See this post for comparison with CMU enabled.
1_red_CRlim_LUTorig_cmu0_fud0

Eliminating this single error was achieved by adjusting the default_srgb_regamma_lut[] on empirical basis.

Best regards
Bruno

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.