Replies: 9 comments 22 replies
-
|
Hi
You are referring to max output value in limited range? But if HyperHDR calibration detects limited scale at the beginning then all value on input will be upscale to full 0-255 range during the calibration process. Shades of gray are about so interesting and the HyperHDR calibration focuses especially on them, because the individual components are equal. If I convert RGB to BT2020 (and vice versa) they remain equal, you can test it here: https://ajalt.github.io/colormath/converter/ However, the graber returns slightly disturbed green channel, these are not any big differences, even more absolute than percentage ones. Just look at the "raw" HDR results for grays captured as SDR, without any transformations and corrections: https://www.hyperhdr.eu/2022/04/usb-grabbers-hdr-to-sdr-quality-test.html Calibration at the very end makes green correction, but only and exclusively to the gray levels with very small margin, which it has every right to do because the evaluation function earlier focused especially on them. I don't know if adding another intermediate level, e.g. between 220 and 255, will change much as we do not directly map these levels but set general parameters of the inverse function and scale. But we can experiment by increasing the number of tested and read colors and even using AI to interpolate the obtained results (I have already seen such an attempt for HyperHDR). |
Beta Was this translation helpful? Give feedback.
-
|
BTW this branch (not merged yet) has a bit better approach for limited colorspace: https://github.com/awawa-dev/HyperHDR/tree/422_limited_calibrator |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for addressing this issue. I've noticed the scaling of values to the maximum, which makes sense given the basic formulas for converting YUV (limited) to RGB. In the added log, you can see the white index value (23), corresponding to the color value 220, 220, 220. With limited range scaling to full, even white seems to get slightly amplified, possibly leading to an overemphasis. This scaling could result in a white value somewhere between the original 219 and 255, hence the idea of adding more values for white balance. Interestingly, the white correction values found in my setup (1.003385, 1.000000, 1.004014) do not alter green, which theoretically makes sense. However, if there's an inherent error in the green channel, perhaps this should be adjusted? The information about the green channel being slightly off from the grabber seems crucial. It could explain the slight overemphasis, especially noticeable in specific shades of blue and sometimes in white or yellow tones. This might be due to the limited to full scaling where RGB values are slightly altered. I'm still trying to fully understand the code, particularly what happens where and when, but maybe an initial RGB channel analysis post-EOTF adjustment could be beneficial. Adjusting the primary colors to minimize delta E, without over- or undersaturation, and then optimizing the rest based on these adjustments might be a way forward. I wonder if a different correction value or weighting for each channel, especially green, might be needed if distribution is detected as incorrect. Regarding the AI-based adjustment you mentioned, is there a link or a branch for that? Also, thanks for the limited colorspace branch. I've merged it, but the score is still higher than for FCC, and I haven't been able to delve into that method yet. I've attached the current calibration log where I've tested using FCC and an HDR signal (not LLDV). I plan to test again by specifically disabling FCC to try this method. I've also temporarily used BT.2020 coefficients in tests to see the score, even though the color conversion would be incorrect with them. Your insights have been incredibly helpful, and I'm eager to explore any further suggestions you might have. Details
05:37:22.439 CALIBRATOR : LutCalibrator.cpp:939:correctionEnd() | Mean error for FCC is: 1868.309269 |
Beta Was this translation helpful? Give feedback.
-
|
Update with Log: Details
16:14:11.029 CALIBRATOR : LutCalibrator.cpp:938:correctionEnd() | Mean error for FCC is: 1868.309269 |
Beta Was this translation helpful? Give feedback.
-
|
Do you use similar settings for GFX as mine in Windows 10? Please send me an email for the firmware. Just replacing EDID is not enough: modified firmware must have proper CRC. |
Beta Was this translation helpful? Give feedback.
-
|
No, I’m currently not using a Windows PC because my graphics card is too old and doesn’t support HDR. Instead, I’m using a Fire TV Cube, as it’s unfortunately the only media box that has a browser capable of accessing the HyperHDR interface for the calibration process. With the Fire TV, I can force the needed HDR/LLDV output (LLDV or HDR depending on the EDID settings of the Diva). Do you know of any other player that can do this? It makes sense about the CRC check. Great, thank you. My email for the firmware: sjunkies.dev => gmail.com |
Beta Was this translation helpful? Give feedback.
-
|
FYI: it seems all new attempts to calibrate limited YUV was a dead-end or just a workaround as it was caused by another ms2130 firmware EDID bug #746 With new firmware no workaround is needed, LUT calibrator detects standard limited range 16-235, firmware bug returned 29-219. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, sorry for only getting back to you now. During the week, I don't always have time, what with work and such things that need to be done ;) Details
tCalibrator.cpp:973:correctionEnd() | Optimal PQ multi => 31.000000, strategy => 0, white index => 23 |
Beta Was this translation helpful? Give feedback.
-
|
Probably no EDID modification (f3 is 'old original' firmware with only replaced EDID, LLDV settings are based on my experience with Ezcoo splitter) will change the proportions of the green channel, because it is not an error. If you look at the calibration results of other grabbers on my blog, they all behave this way. I don't think that the problem is using the wrong Rec to convert YUV to RGB, because the differences are minimal compared to the Rec.601 and Rec.709 standards. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @awawa-dev , after more than two weeks of research, countless tests, and thanks to your amazing tip regarding hue mapping in the BT.2020 documentation, I finally figured out today why the colors are so shifted after conversion!!! Brace yourself: it's the wrong color space transformation matrix in the LUT calibrator from BT.2020 to Rec.709 space! I actually discovered this on the first day, but since you mentioned that the green channel from the grabber could also be defective, I started looking in the wrong place and then came back to it in a roundabout way. It all makes total sense because it's simply the wrong color space being converted to Rec.709. The correct color space that needs to be used is P3-D65, which is currently being "sold" as BT.2020 and is of course covered almost 100% by any current TV, unlike BT.2020. This ultimately explains a lot to me. The BT.2020 color space encompasses a significantly wider color gamut, with corner coordinates, such as those of green (the primary source of the issue), positioned much higher. This naturally defines all color coordinates higher up, leading to their overemphasis when converting back to the smaller Rec.709 color gamut. Thus, all colors that start very far from BT.2020 are not at the correct coordinates because it's actually the P3-D65 color space with the correct color coordinates and with which current HDR / DV content is mastered. This is why possibly other users have also noticed these color shifts through HDR2SDR Tone-Mapping within HyperHDR. Hue mappings and other adjustments unfortunately only led to further shifts of other colors, even with angle calculations of delta h and delta alpha and the color space differences and distortions... Since I can't make a pull request in the project right now, here is the matrix I used. It's a P3-D65 to Rec.709 with Chromatic Adaptation Transform according to CMCCAT2000 and the highest resolution I could get: void LutCalibrator::fromBT2020toBT709(double x, double y, double z, double& r, double& g, double& b)
{
r = 1.224940176280560 * x - 0.224940176280560 * y + 0.0 * z;
g = -0.042056954709688 * x + 1.042056954709689 * y - 0.0 * z;
b = -0.019637554590334 * x - 0.078636045550632 * y + 1.098273600140966 * z;
}Maybe I'm completely off base, and perhaps there's a better matrix than this one, or we need another matrix within the DCI-P3 color space, but with it, I was able to fix my issue and possibly that of other users and maybe yours too :)) |
Beta Was this translation helpful? Give feedback.
-
|
You are correct about your finding and I mentioned earlier about "wrong white point". The problem is that sometimes the white point is standard D65 during HDR calibration :/ and there is no shift towards the green. Currently, I have an alternative calibration almost ready, transferred almost completely to matrix operations in the XYZ space, which is able to detect the correct YUV coef, white point and hrd10/lldv parameters in only one pass. But it won't be included in HyperHDR v20, only in v21: too much good stuff is already in v20 ;) I'll probably post it this week or next. The next thing I'm considering is the calibration of the primaries, theoretically we can also correct them since we know the red, green and blue color values, as long as they do not deviate too much from accepted standards. |
Beta Was this translation helpful? Give feedback.
-
|
Oh Wow, that sounds amazing, and I'm really looking forward to it :)) Thank you! During these tests, I've also noticed a few other things, but it might be because I've tested a lot with (LL)DV content since that's mainly what I watch, less so HDR except for games. I realized with a few test images that I used to run all my calculations and conversions that the actual scope is larger than assumed, at least in my case. This makes total sense, as I don't know how extensively you've tested, but I don't think the test patterns are sufficient in terms of values because they should actually be full 10-bit values. The grabber, which cannot do HDR - so let's assume that anyone using the project does not use a real HDR grabber but the HDR Tone Mapping function ;) then, as with the MS2130, all 10-bit values are truncated/masked to 8 bits. Since I only had images from the preview for testing, which were already RGB images upscaled to the full 0-255 range in the conversion from limited YUYV to RGB, I found much higher values in the images than the ceiling definitions at calibration. I just printed out all high values in a Python script, which, for HDR 10-bit, 1023 is the maximum (Video data range: 4 through 1 019). for x in range(870, 1024, 1):
print(x, (x & 0xFF), (x & 0xFF) * (255/219), (x & 0xFF) / (255/219))Just to have a few values that explain some things... Y can be a maximum of 940 (limited) and is actually reduced to 876 (940 - 64), and U/V a maximum of 960, which converts to around 896, at least if you had the original signal and the 10-bit YUV limited data converted to RGB, but we don't have that, so the limited signal is still there, but with masked values... This led me to realize that the maximum brightness value (already upscaled in my RGB image) must actually be around 200: So, theoretically, the maximum brightness value in the RGB environment should be about 200.274. I also compared all the values back and forth... since the 10-bit fits 4x into 256, the whole cycle repeats, and the values also go up to 255. Every step can be determined by adding 8-bit value + 256, + 512, +768... but that should be obvious ;) Therefore, for me, the maximum brightness value ends up being about, if not exactly, 200 or from the YUV signal at 172 and 192 for U and V, or about 224... So now I'm considering whether the calibration process should use the actual values and colors and maximum values, i.e., up to 940 / 960, etc., to determine floor and ceiling, pure white as 255, and then in the limited range, so 235 (theoretically) which I believe is actually represented by 940 or masked to 172 hence I think the weighting of maximum brightness shifts a bit... theoretically, the bottom 64 values are also black, but due to masking, there are values at the bottom too because from 256 the value starts again at 0.... unfortunately, the values can't be reconstructed, at least I don't know how, but I believe the low ceiling value of about 156 (I think it was about that for me) is too low, as it increases brightness but also leads to further oversaturation / overexposure... a higher value would allow for more nuances, which reduces overall brightness a bit but also minimizes color and brightness peaks - keyword only white areas, yellow is too bright so everything is white etc... because the brightness value is too high.... a higher ceiling value would make the image more balanced... all just theory.... I was able to test this in my setup, but I only have my setup and don't know how it behaves with other grabbers etc. so that's another input from me, noticed during all the tests, which could perhaps be considered/improved in the future... And if I could make a huge request, would it be possible, when creating a screenshot through the UI, which is a copy of the canvas content, to somehow have the option to save the current raw frame image, i.e., the original image captured by the grabber that's just arrived in the system, as a raw file (YUV - in my case) unchanged, and maybe even send it back to the browser/UI as a download or save it somewhere with a timestamp etc. The original data directly from the grabber with the original values helped my tests differently than already modified RGB values etc. If that were possible, it would be amazing. It would have saved me a few nerves to get the raw data, because when HyperHDR is running, v4l2 and the grabber are blocked... In FrameDecoder, I've seen that there are screenshot possibilities, but only for testing and then unfortunately not in RAW format, which is actually available at that point before processing etc. ;) I know it's possible via the command line, that's how I did it last, but when I activate the grabber, the signal is briefly cut and I always have to record several frames at once, then split the total file into individual frames and look for the frame that isn't black, but as soon as the grabber is ready again after the handshake, the image is also recorded... it's surely due to a setup in the chain, but it's annoying when you just want to quickly save a raw frame and if it could be done within HyperHDR via the UI, especially since you can already take screenshots of the preview, just unfortunately no RAW directly from the grabber, it would be very helpful. Maybe even parallel to the RAW, a second one after the HDR Tone Mapping, if HDR Tone Mapping is active. So I think that's all the topics for now... Thanks anyway for everything you've done and considered here so far! |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry that I haven't replied yet, but I also have some observations of my own regarding the work I'm finishing and I still want to check some things first. I'll do it later. I just have a question: have you tested Bradford as an alternative to CMCCAT2000? And did you probably mean P3-DCI and not P3-D65, because the latter overlaps with D65? And then we correct P3-DCI (shifted towards green) to D65. |
Beta Was this translation helpful? Give feedback.
-
|
No worries about the delay in responding, I completely understand the need to finalize and verify your work before sharing. :) No, I haven't tested Bradford, nor was it necessary since the CAT didn't really change the matrix conversion; I just stuck with CMCCAT2000 / CAT02. However, according to the colour-science app I used, Bradford would have been identical when starting from the P3-D65 / P3-Display color space - yes, I meant P3-D65 / P3-Display ;). If P3-DCI is taken as the input color space, the matrix values change depending on the selected CAT. P3-DCI's white point, according to the definition, is at 6300K CCT, which theoretically wouldn't be suitable for home signals:
I've noticed that current content seems to be mastered in the P3 color space, so TVs are likely led to believe they're receiving BT2020 signals when it actually corresponds to the P3 color space. At least that's my theory, since the colors don't match otherwise... Or another theory: the signal is converted by the TV from BT2020 to P3-D65 before further processing, given that the TV covers up to 100% of P3-DCI. I think the whole P3 DCI / D65 / Display etc. is just a matter of terminology... essentially, DCI-P3 is the color space, and D65 / Display or DCI etc. are types with defined white points within that color space. But I'm not a video expert and unfortunately don't know the details of the signal processing chain, so these are just speculations on my part... However, I can certainly try out P3-DCI with CCT at 6300K... it might even explain why I need to lower my color temperature on my LEDs despite having D65, and D65 still appears too cool... hmm, I'll look into this. Please let me know if there's any other way I can assist you. |
Beta Was this translation helpful? Give feedback.
-
|
The video source like movies is another problem (yes, they can use P3 colorspace but there is also P3-D65 variant which uses standard white point and P3 is only a subspace in Rec.2020), but if you take a look at the "normal" D65 it has the same xy coordinates https://en.wikipedia.org/wiki/Illuminant_D65 so theoretically you do not need to apply chromatic adaptation when converting from P3-D65 to standard sRGB using also D65. BTW edid contains information about the display primaries and the white point eg. my PC display is using standard D65. |
Beta Was this translation helpful? Give feedback.
-
|
You're absolutely right, my primary concern was that the original correct color coordinates seem to reside in the P3-D65 / Display color space and through the matrix are converted to the correct positions within Rec.709, as if it were assumed they originally sit in the BT.2020 color space (at least that's the assumption after tests with a BT.2020 to Rec.709 or P3-D65 to Rec.709 conversion). The white point coordinates always sit identically across the board since it's the reference point for the color coordinates and the matrix, to align/shift the colors to the correct positions within the color gamut, at least that's how I've understood it. It's true that the D65 coordinates from P3-D65 to sRGB are identical, which would explain why the matrix doesn't change, no matter which CAT is chosen, because no white point adjustment needs to be made, but rather the colors are just aligned to the correct/closest positions within the new color space/gamut. This also explains why with P3-DCI (white point at 6300K), the matrix changes depending on the CAT...
Thank you for that; I've also noticed that. Essentially, you can get the display primary coordinates through the EDID, which gives you the gamut of the display + white point. However, this unfortunately doesn't reveal the color space in which the source is mastered, which is what the grabber receives. I believe these data are used for LLDV to adjust the image accordingly in the player... it's just partly really confusing, since there are so many definitions and informations for everything nowadays ;) |
Beta Was this translation helpful? Give feedback.
-
|
Another progress. The white color disturbance was a dead end resulting from the search for the optimal scale for the whole, which could have slightly distorted U and V. But now it has to be changed because there is a better method, basically we only need to determine the correct YUV coeff because it has a huge impact on the result. I moved the entire conversion to a new library that supports linear algebra, basically the entire calibrator was rewritten. At the same time, I had to remember a lot of my studies (I studied mathematics/physics/computer graphics/CAD... all in one ;) but it was long time ago) The conversion of the bt2020 signal to bt709 itself is insufficient because there are some color distortions and I don't know for sure whether they result from the Windows mapping method / color profile or maybe the grabber. Or maybe we still missing something in USB grabber processing that is not included in ITU documentation... I'm not sure if Rec.709 OOTF was applied to our signal. The graber usually uses an some internal LUT with which it can process ("correct") colors or to apply EOTF, because even if we capture an SDR signal, we wont receive colors as they were rendered, at least on the MS2130. And even more so on the MS2109 where the saturation/contrast cannot be set in a completely neutral position. Unfortunately, this spoils our HDR to SDR mapping a bit. I think the effect is very good. You can observe island of disturbances here, e.g. for green (238, 0, 0), but this is almost certainly a disturbance introduced by the grabber and we cannot do anything about it. Fortunately, such cases are few and will be averaged when calculating LED colors anyway. We don't fully convert the video material from HDR to SDR to watch it, we only control the lights ;) The log is attached, I think you will find some interesting information here. Additionally, there are now many more test points. LCH mapping is extremely CPU resource expensive, fortunately we now have to do it once for each coef in the case of HDR10. Processing in LCH does not yet support mapping colors outside the sRGB gamut and they are simply cut off at the limits (without projection on Rec.709 gamut), because we will not display them on 8-bit LEDs anyway. But that's how it's always worked. Calibration process is using SRGB space colors encoded by OS into Rec.2020. So theoretically it should be reversible, but this is not entirely the case with grabbers. |
Beta Was this translation helpful? Give feedback.
-
|
BTW I repeated your procedure using current HyperHDR v20 setup. Source amblin logo, used in Firefox to display it in the full mode: No tone mapping: Enable tone mapping: It is much brighter with no dramatic overbalance of green "on the moon". It is possible that some device in your HDMI chain is interfering with the signal e.g. setting a different or dynamic brightness as a reference. |
Beta Was this translation helpful? Give feedback.
-
|
Which reminds me that there is a "famous" bug in MS2130 firmware that may cause the image to appear darker sometimes...so far alternative firmware F3 I tested only with Ezcoo splitter and at least in my case it helped so it is probably EDID configuration issue. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, that's quite the significant progress, and the measurements through the LCH processing look fantastic! Thank you for sharing the status. I'm already excited to take a look at the new library and the calibration with it. ;) The test images with the moon look very promising!!! I also have a small update, not as monumental as yours, but I need to revise my previous statements. I conducted further tests with the MS2130, which I should have done earlier, to figure out how the grabber processes and outputs the incoming HDR/LLDV 10-bit signal. Initially, I mistakenly thought that the 10-bit values were being truncated (masked), assuming the upper limit was at the (masked) 172/192 as assumed. However, it turns out that the grabber actually performs a 10-bit to 8-bit (10 >> 2) bit shift! I tested the YUV values in an HDR signal, especially Y in the nits range of 100 - 10000 nits, and the grabber indeed outputs the exact 8-bit limited value of 235 for 10,000 nits (in my test file, it was 234, but that seems to be a rounding error in the file), thus the inverse pq works correctly with the values returned by the grabber, and you end up with the exact nits values if you start from the 10,000 nits! If you're interested, here are the 8-bit (limited) Y values from the grabber and the corresponding nits values defined from 100 nits: The values fluctuate a bit due to slight rounding of the original 10-bit values, but if you normalize the Y values, i.e., (y - 16) / 219, and put it into the inverse PQ and then calculate * 10000 at the end, you get the correct nits value on the PQ scale up to 10000 nits, as if it were the 10-bit Y value, but you surely know all this already. ;) In essence, I want to work with the original YUV values before they are further processed to RGB... For colors, it's the same, only that the grabber probably converts the incoming YUV values to RGB and then to YUV BT601 or directly uses some kind of LUT/mapping for the output. Here I'm currently testing how I could theoretically get back to the original UV values. For direct comparison, I took a HEVC BaseLayer (BL) from a movie and looked at the original YUV values of a specific frame for comparison with the image and the values from the grabber. The Y value matches exactly, as the BL is designed for 1000 nits, and the maximum value in the original Y = 722 => which in 8-bit is 180 and via inverse PQ approximately 994 nits, so almost 1000 nits! In the end, I didn't understand why an upper limit is defined. Essentially, you're just trying to determine the current maximum value for the nits upper limit, but in reality, this limit doesn't exist, as it would otherwise compress the dynamic range too much or did I simply misunderstand the use of the maximum range (celling / floor) values? Okay, this is basically something different from what you're currently doing. I'm just trying to understand the logic of the original signal and what is passed on by the grabber. But it looks like the values aren't really processed, just "only" bit-shifted from 10 to 8 bits, and the color space encoded to BT601 or just mapped, the rest seems untouched because the grabber probably doesn't recognize the format and thus doesn't apply any (?) Transfer Function: Rec. 709 and also no double limited correction. Maybe this is a wrong approach, but I need to understand and trace the whole process, especially mathematically, for it to make sense to me. Sorry if I digress too much; I suspect you already know all this and are much further along. I'm testing all this via Linux on my Raspberry Pi 4, and HyperHDR uses v4l2 where I unfortunately only have these fixed, unchangeable options with the grabber - or could that even be changed somehow through firmware? These are unfortunately the fixed values of my grabber: Colorspace: sRGB, Transfer Function: Rec. 709, YCbCr/HSV Encoding: ITU-R 601, Quantization: Default (maps to Limited Range), at least with my setup. I'm currently back to the original firmware since I don't have a problem forwarding HDR/LLDV signals to the grabber through the HDFury Diva, and I also feel that the colors are more accurate/detailed again. But that could be an illusion. I've never noticed the firmware bug mentioned, where the image becomes darker, at least not in my setup. If there's a way to force this bug, I could test it at some point. I also have an Ezcoo HDMI 2.1 splitter, but it's currently only in use because of my PS5, as the Diva and my current AV receiver can't do HDMI 2.1... Okay, essentially, what I'm trying to achieve, regardless of the current topic: Since I have HD108 16-bit LEDs, I'm reluctant to reduce the processing to 8 bits only to upscale these data back to 16 bits. I've already made my own calibration adjustments within the LEDDevice for my LEDs, which work for my setup, but the input values are all based on 8-bit values and are already RGB, which have been partially processed. Since my calibration of HD108 LEDs produces a linear output, I don't need a gamma correction (values are set to 1.0), resulting in more accurate and detailed colors. Previously, I had APA102s, which I also operated with linear RGB values, which were adjusted by an sRGB to Linear function, as the grabber delivers SDR data in the sRGB color space. I've also integrated a CIELUV calculation so that my final RGB values are scaled according to the brightness of the L value so that the brightness conforms to the CIELuv standard. Would it be possible to pass through the original YUV values of the grabber all the way to the LED Device process so I can process them there? Not every grabber now outputs YUV, but I would like the option of which input values are processed and passed on when, how, and where.... okay, I know that's wishful thinking, and I know that it's also not the correct processing path/process in the project, especially not in the final LEDDevice, but HyperHDR is unfortunately completely designed for 8-bit values, allowing me only direct testing in the LED Device without currently having to make extreme modifications throughout the entire project from the grabber process to the LED Device, as it's only for my specific adjustments and tests. I don't know what can be done with your new library, but I would wish that the input signal (YUV) is processed and passed through as normalized double values in the 0-1 range, Color corrections, like temperature, saturation, etc., actually also all occur on linear color values. That is, options should be integrated so that the input signal is normalized and then, depending on the grabber and input signal, linearized, and in the end, if required by the LED Device, gamma corrected. This way, one would be completely independent of the final target range, which then has to be scaled directly in the LED Device to 255 or, as in my case, 65535, or further processing with the linear values, etc. The only thing then is the ImageToLED mapping per LED, which could probably work more flexibly with 0-1 values? This worked, in my opinion, and according to my perception, better than through the integrated gamma correction... ;) So, you might understand what I'm getting at... in the end, I want to achieve as detailed color processing as possible without values being clipped/clamped etc., so often. Maybe that's all too much overhead, and my perfectionism is driving me to get the best out of the system. |
Beta Was this translation helpful? Give feedback.
-
|
Generally, I prefer to work with linear RGB than YUV (more specifically than YCrCb, because YUV is a different scale/format in addition to those unfortunate YUV coeffs so its useless) and in the documentation regarding e.g. Rec.2020 they also use RGB. As for the transition from 8-bit scale to 16-bits , there are 3 problems: 8-bit video sources, 8-bit LED color processing, 8-bit LEDs. When it comes to the former, only DirectX11 and newer offer a larger scale. There are also light sources that offer something more than 8 bits, e.g. HD108 and probably also Philips Hue. And we won't do anything about it. However, between the video source and the LEDs there is the HyperHDR image-to-color processing you mentioned and LED drivers. It shouldn't be difficult to change it. Also 8-bits ColorRgb is used in the signal/slots but they can be overloaded to use new type e.g. ColorRgb48. Or the base ColorRgb can be extended to 16 bits but the problem is Image also uses ColorRgb so maybe it's time to separate these structures. LED drivers must also be aware of this in order to use it. When it comes to calculating the brightness for which the HDR stream was calibrated |
Beta Was this translation helpful? Give feedback.
-
|
Hi |
Beta Was this translation helpful? Give feedback.
-
|
Hi, sorry for the late reply and thank you for the information and great news on this topic as well as P010! Unfortunately, I’ll only be able to take a closer look at it during my Christmas vacation, but I’m already very excited and thrilled about the incredible progress you’ve made here—hats off to you! I really appreciate the fantastic work and will give feedback as soon as I find time to test it. I also have a few requests for considerations/improvements—apologies if this is misplaced here; I'll try to submit these as official requests if I get the time, but perhaps you could already take them into account if possible; that would be fantastic! 😊
I realize these are quite a few points, but if these could be achieved, it would truly be the holy grail for current HDR data and could even cover future 10-bit, 12-bit, or higher formats. Many thanks for all the work and energy you put into this project! 😊 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @SJunkies
Sure, BGR3 will be added soon. My P010 patch kernel is platform/distro independed so it should work for your RPi4/Ubuntu just like it works for me with RPi OS and with my PC running Ubuntu 24.04. All you need is rather modern Kernel, Ubuntu 22.04 kernel is too old.
It is on my calendar but it will be divided into several stages, most of them will probably appear rather in HyperHDR 22.
Hyperion has integrated dominant color (most common) for the area which simply ignores the rest of colors. I think that's not what k-means clustering is about and will probably end in chaos/blinking when the area has large color spread because the "dominant/winner" in such a scattered population can change significantly every frame.
Currently flatbuffers has been extended with NV12 (receive only). P010 is almost identical, only the data quantum is 16 bits instead of 8. However, what discourages me is the situation with P010, which is not supported by default on Linux and I haven't even tested it on macOS. After implementing point two from the list, it shouldn't be difficult, however.
Thank you ❤️ |
Beta Was this translation helpful? Give feedback.
-
You're welcome! 😉 Happy to share ideas and suggestions!
Great to hear that BGR3 will be added soon! My RPi4 is also running Ubuntu 24.04, so I hope it’ll be possible to get your P010 patch working. ;)
Happy to hear that! When HyperHDR 22 is ready, I’ll be here and ready to test it out! 😊
You're right; I found this section in the code, and it does look like clustering with a k-means approach is being used, which is why I was a bit confused: How would an ideal solution for k-mean clustering from your perspective look? 😉
Okay, NV12 support sounds great! The main issue for me at the moment is that there’s no HyperHDR addon for CoreELEC/Kodi that I can simply install via the repository. I need to be able to send data directly from the Amlogic grabber on the Ugoos via flatbuffer (or something even faster, if possible) so the original image data (raw) is preserved without being packed into any other format—putting the 10-bit issue aside for now. I don’t think I can compile HyperHDR directly on the Ugoos with CoreELEC, so NV12 usage isn’t possible without the latest HyperHDR version. Any tips on how to proceed?
❤️ |
Beta Was this translation helpful? Give feedback.
-
I have a plugin for CoreELEC in one of my repo but without Amlogic grabber yet. Currently the problem for HyperHDR to officially appear in CoreELEC is the installer size (LUT) but watch out: this will change soon 😉 Someone would have to pull the whole process in CoreELEC, Qt would also have to be upgraded to 5.15. I don't have the resources for that anymore but I can help if necessary. |
Beta Was this translation helpful? Give feedback.
-
Hey @awawa-dev,
I've reached a point where I'm unsure how to proceed and desperately need some guidance. I'm experiencing an issue with the HDR2SDR conversion process where there's an excessive amount of green being introduced into the overall image. This becomes especially problematic during color correction for LEDs, as it shifts the other colors too much, and there's a global lack of green, which otherwise seems about right. The issue is particularly noticeable in the blue color range, which ends up looking too green or turquoise, instead of the intended blue.
I'm not sure if I can fully convey the technicalities here, but the problem isn't with the LEDs themselves. It's the color conversion process. The converted image from HDR to SDR already has incorrect colors. Adjustments like gamma corrections during the LUT calibration process or color / color temperature tweaks specifically for the LEDs haven't solved the issue. The balance and weighting of the colors seem off, with green either being overrepresented or another component lacking.
Importantly, this green tint issue is exclusive to the HDR2SDR converted image and not present in the normal SDR (YUV) signal, where everything seems perfectly balanced.
My setup involves a Raspberry Pi 4 with an MS2130, connected via USB 3.0 and using YUV Limited to receive the pale/washed-out HDR signal. I've used both your MS2130 LUT and one created with your LUT Calibration Tool. It's important to note that your LUT is designed for the FULL YUV range, which causes my LEDs to light up even when the image is black, as my signal is limited (black having the values 16,16,16). Therefore, I had to create my own LUT to accommodate this difference. The input is from an Oppo player, and the signal is processed either through LLDV or HDR from a Diva (I don't use the Diva's HDR2SDR - I'll explain why below). Regardless of whether the LUT is created with an LLDV or HDR signal, the excessive green issue persists. I'm wondering if this is a technical problem with the formulas or just the limitations of color reversion due to lacking color information/metadata, especially since it's in 8-bit instead of 10/12-bit.
I've attached three screenshots for reference: one without HDR2SDR active, one showing the conversion result (note the excessive green on the moon, making it look turquoise rather than blue), and a third showing the ideal result as seen on my TV.
I hope I'm not infringing on any copyright laws with these screenshots, which are from the opening logos of movies like 'Ready Player One' and 'Jurassic World 2'. If this is an issue, please inform me, and I will remove the screenshots or provide them through an appropriate channel.
without HDR2SDR:
with HDR2SDR:
optimal results:
Additionally, I'm curious if others in the community have faced similar issues, particularly with different capture devices like the Elgato HD60X or similar.
Regarding why I'm not using the Diva's HDR2SDR conversion: While many aspects of the Diva's color accuracy are satisfactory, its profiles for HDR2SDR conversion are not quite right. Your HDR2SDR conversion, despite the pale/washed-out colors, produces a much better image, except for the green/turquoise issue. It's frustrating, but true. HDFury's technical support hasn't planned any further LUT/profile adjustments, even after I explained the problem. For instance, the color red (like in PS5's Diablo IV) turns more orange than a rich, dark red, as compared to the direct TV signal. HDFury's team insists their profiles are optimal and won't be altered.
Any insights, suggestions, or explanations would be greatly appreciated. I'm seeking a solution or at least an understanding of this color conversion challenge. If more information is needed, please let me know. I'm looking forward to any assistance or advice the community can offer.
Thank you in advance!
Edit: I suspect the issue might be related to the white balance adjustment and/or the scale factor in the EOTF function. It’s possible that each RGB channel might require its own specific weighting, similar to the coefficients, but I’m not entirely certain. Additionally, in addressing the potential white balance issue, a detailed examination of the gray levels in the upper range, especially around values 220,220,220 to 255,255,255, could be useful. My white balance index is set at the value of 220,220,220, and the next available value is directly 255,255,255, with no intermediate options. This gap suggests that adjusting to a higher value might be limited in scope. However, exploring the possibility of implementing finer gradations or increments between these two values, if feasible, could potentially offer a more precise solution for balancing the colors. These are just my assumptions based on what I’ve observed and considered so far.
Beta Was this translation helpful? Give feedback.
All reactions