Improved Image Quality through UniWB - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2]   Go Down

Improved Image Quality through UniWB

  • 15 Replies
  • 7737 Views
*

Offline outslider

  • *****
  • 762
Re: Improved Image Quality through UniWB
« Reply #10 on: 26 / March / 2012, 13:17:42 »
Advertisements
Thanks for the answers and forgive for this offtopic. However it seems to be even related to the topic - live view, histogram and so on;)
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline chdecker

  • *
  • 17
Re: Improved Image Quality through UniWB
« Reply #11 on: 26 / March / 2012, 14:20:53 »
Hi reyalp,

thanks for sharing your histogram settings. Your settings make the histogram really look like Canons, also when using UniWB.

Just a short question about the two oversteppings in the histogram: When I change the type of histogram: are the oversteppings still the same? And a further question: On which information relies the Zebra-functionality - RGB?

I have done some further experiments and results look really promising. The only thing I would like to have is to seperate UniWB measuring from taking the frame with AWB. I would like to use a button, e.g. the Display button, to act like half pressed shutter but with underlying UniWB. Do you think this is possible with CHDK? Can you give me some directions?
Logged
*

Offline reyalp

  • ******
  • 14037
Re: Improved Image Quality through UniWB
« Reply #12 on: 26 / March / 2012, 17:12:58 »
Quote from: chdecker on 26 / March / 2012, 14:20:53
thanks for sharing your histogram settings. Your settings make the histogram really look like Canons, also when using UniWB.
Yes, it appears the canon histogram is based on Y.
Quote
Just a short question about the two oversteppings in the histogram: When I change the type of histogram: are the oversteppings still the same?
I'm not sure what you mean by oversteppings ?
Quote
And a further question: On which information relies the Zebra-functionality - RGB?
The zebra uses the same screen data as histogram. It is uses the Y values directly, unless you select RGB zebra. RGB zebra converts to RGB first, obviously.
Quote
I have done some further experiments and results look really promising. The only thing I would like to have is to seperate UniWB measuring from taking the frame with AWB. I would like to use a button, e.g. the Display button, to act like half pressed shutter but with underlying UniWB. Do you think this is possible with CHDK? Can you give me some directions?
The only way you might be do this without modifying the code is using a script. The whitebalance mode is a propcase http://chdk.wikia.com/wiki/PropertyCase I believe this can be set from script. I don't know whether this would be more convenient than your current method. I'm not actually clear what your current method is actually, if I've understood the uniwb page, it sounds like you would normally just set up the custom whitebalance once.

There is also a propcase which includes the actual whitebalance matrix, but unfortunately this does not seem to be writable, see here http://chdk.setepontos.com/index.php?topic=6765.msg72443#msg72443

edit:
A thought occurred to me - Given that we can read the white balance values (although the exact meaning isn't clear to me), it might be possible to approximate a "raw" histogram by reversing the transformation, so you wouldn't have to do any of this tricking the camera white balance stuff.
« Last Edit: 26 / March / 2012, 22:32:50 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline chdecker

  • *
  • 17
Re: Improved Image Quality through UniWB
« Reply #13 on: 26 / March / 2012, 23:51:27 »
Hi reyalp,

with overstepping I mean these little red dots in the histogram (dont know the english translation):
http://dl.dropbox.com/u/3775756/20120325_192550.jpg

Ok, at this point I wanted to discuss my current UniWB flow but I just read your edit: 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.

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? So the user can select if he wants to display an entire RAW flow (with respect to histogram and zebra) or wants to stick with JPEG data. The big advantage would be to recognize when the sensor really cant manage exposure.

Edit: Had some more thoughts about reversing transformation: When we assume (as stated in the article linked from my OP) that white balancing is just multiplying certain factors to RGB the only thing we need to do is to modify each channel by dividing each value of each channel with this certain factor to get a transformed histogram. Nevertheless, what about those values which are overexposed?
« Last Edit: 27 / March / 2012, 01:06:47 by chdecker »
Logged
*

Offline reyalp

  • ******
  • 14037
Re: Improved Image Quality through UniWB
« Reply #14 on: 27 / March / 2012, 02:14:16 »
Quote from: chdecker on 26 / March / 2012, 23:51:27
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).
Quote
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.
Quote
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.
Quote
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:
Code: [Select]
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)
Logged
Don't forget what the H stands for.
*

Offline chdecker

  • *
  • 17
Re: Improved Image Quality through UniWB
« Reply #15 on: 27 / March / 2012, 15:29:07 »
Quote from: reyalp on 27 / March / 2012, 02:14:16
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.


Quote from: reyalp on 27 / March / 2012, 02:14:16
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.
Quote

This sounds very good and would be exactly what we need to get optimized exposure for the sensor. This would substitute UniWB method and is much more convenient. The only Iam concerned about is clipping values. As you stated by Zebra:
Quote from: reyalp on 27 / March / 2012, 02:14:16
If the value raw value is clipped before it gets to the live display, you will never get the original value back.
It may also a problem to get the orig value back to histogram.


Quote from: reyalp on 27 / March / 2012, 02:14:16
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.

What a pity. IMO you are one of very few developers who could implement that. I propably wont be able to do that coding.  :(
Logged
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics