with overstepping I mean these little red dots in the histogram (dont know the english translation):
I don't think those change, but the code is a bit convoluted so I wouldn't guarantee it. It looks to me like they depend on the top/bottom 3 bins of the RGB histogram (which is calculated even if not shown).
Ok, at this point I wanted to discuss my current UniWB flow but I just read your edit:
Well, if my idea makes any sense at all, it would need quite a bit of work that I'm not likely to have time for.
This sounds very interesting. How do you think are you able to manage the reverse transformation? What I thought is that the conversion from RAW to JPEG is something magic from Canon.
The idea is
* PROPCASE_WB_ADJ value represents the white balance adjustment. I forgot about this, but it is used in the DNG code for AsShotNeutral which according to the DNG spec "specifies the selected white balance at time of capture, encoded as the coordinates of a perfectly neutral color in linear reference space values." This sounds quite related to what you are trying to do. See dng.c starting at line 477 and the DNG spec for how it is used. Note DNG only uses the first 3 of 7 values, I don't know the meaning of the others.
* The white balance adjustment applied going from sensor to the display should be equivalent.
* With both of these, you should be able to do the process in reverse, taking a white balanced YUV value from the display, and giving you what the value would have been if you had no white balance.
* However, the sensor to live display transformation is lossy, so you won't be able to reverse it perfectly.
Another idea occured to me:
When you manage to reverse histograms information - do you think it is also possible that Zebra relies on that reversed information?
Maybe. If (not when!) this can be done with histogram, then you could do the same with the values used for zebra. Whether this is useful depends on how much information is lost. If the value raw value is clipped before it gets to the live display, you will never get the original value back. Since zebra only looks at extremes, this might be a problem.
Since the WP_ADJ propcase is 28 bytes, you obviously can't watch more than the first value in the propcase viewer. In chdkptp, you can examine it like this:
con> !s,v=con:execwait('props=require"propcase"; return get_prop_str(props.WB_ADJ,28)');b=lbuf.new(v);return b:get_i32(0,7)
