CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: Bernd R on 27 / April / 2011, 05:24:09
-
I do some tests and see that when rgb zebra is switch in menu on, it show better overexpose if only 1 color is overexpose.for example i get blue overexpose often before all channels are overepose
But sometimes only green blue and black is not good visible on display in bright sun.so best for me is to use red on normal mode but see overexpose correct without rgb zebra.
red as overexpose is good see on bright sun.
Can this fix ?
-
I would expect the regular zebra to be more accurate, since it's based on the Y component of the original YUV buffer. If regular zebra says there is no over exposure but RGB does, it's probably an artifact of the conversion.
If you want accuracy, you would need to calibrate it with actual images (assuming there is a stable relationship between the viewport and raw, which I'm not sure is established.)
-
I would expect the regular zebra to be more accurate, since it's based on the Y component of the original YUV buffer. If regular zebra says there is no over exposure but RGB does, it's probably an artifact of the conversion.
If you want accuracy, you would need to calibrate it with actual images (assuming there is a stable relationship between the viewport and raw, which I'm not sure is established.)
I look into source of it, and it look for me as for non rgb zebra only the y color is used.I guess conf.zebra_multichannel is the variable of GUI setting "rgb zebra"
as far i understand yuv its possible that y have a low value and only together with the U and v value it reach a high value.
yy = img_buf[v+1];
if (conf.zebra_multichannel) {
uu = (signed char)img_buf[v];
vv = (signed char)img_buf[v+2];
sel=0;
if (!((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f)) {
if (clip8(((yy<<12) + vv*5743 + 2048)>>12)>over) sel = 4; // R
if (clip8(((yy<<12) - uu*1411 - vv*2925 + 2048)>>12)>over) sel |= 2; // G
if (clip8(((yy<<12) + uu*7258 + 2048)>>12)>over) sel |= 1; // B
}
buf[s]=buf[s+1]=cls[sel];
}
else if (((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f)) buf[s]=COLOR_TRANSPARENT;
else buf[s]=(yy>over)?cl_over:(yy<conf.zebra_under)?cl_under:COLOR_TRANSPARENT;
maybe code can enhance that for normal mode
if (clip8(((yy<<12) + vv*5743 + 2048)>>12)>over) sel = 4; // R
if (clip8(((yy<<12) - uu*1411 - vv*2925 + 2048)>>12)>over) sel = 4; // R
if (clip8(((yy<<12) + uu*7258 + 2048)>>12)>over) sel = 4; // R
I have not test if that work ?
-
as far i understand yuv its possible that y have a low value and only together with the U and v value it reach a high value.
Y is luminance, so that would correspond to a dark scene, wouldn't it ? read posts from a1ex
The whole zebra process should be considered as a general guide, not something exact. Have you calibrated what is "over-exposed" in zebra with what comes out as white level in the raw ?
If not, there is no point in fiddling with the zebra code.
-
Just implemented this in Magic Lantern. It shows clipped channels with the opposite color (e.g. clipped R shown as cyan, clipped blue shown as yellow...)
There are situations where certain channels (R, G or B) clip at low luma values (even 70%), and it's not an error in conversion, but it's due to over-saturation. RGB zebras can show this situation, but Y zebras can't.
https://bitbucket.org/hudson/magic-lantern/changeset/2d833487906d
When you are shooting RAW, RGB zebras may not make sense; they need calibration, as reyalp pointed out.
-
Here are pictures of colors that have Y 0 or Y0.5
http://en.wikipedia.org/wiki/YUV (http://en.wikipedia.org/wiki/YUV)
this i see too when i shoot flowers which are very red blue etc.zebra show no overexpose, RAW is then too overexpose.
I see that my camera have not much gain available in RAW.
I guess because of noise, the camera expose upto 4096 or short before and set this as full bright.
I can in RAW only reach more details in black range.but then noise is more.so i use rgb zebra.
>Just implemented this in Magic Lantern. It shows clipped channels with the opposite color (e.g. clipped >R shown as cyan, clipped blue shown as yellow...)
Problem on new cameras is that they have not much colors available that stay constant and the display can bad see on sunlight.
I do the next shooting with rgb zebra and all overexpose is show as red, and see if results get better.
-
A bit of math (reversed from firmware by AJ, http://magiclantern.wikia.com/wiki/ASM_Zedbra (http://magiclantern.wikia.com/wiki/ASM_Zedbra) ):
R = Y + 1.403V'
G = Y - 0.344U' - 0.714V'
B = Y + 1.770U'
Y is uint8, U and V are int8. You can saturate red channel with V=127, i.e. at Y=77 (only 30% brightness). Blue is even easier to saturate, and green is a bit harder.
-
I found that on most Canon cameras that the R channel is too high from the factory, so I use a "Custom Colors" setting of R -2, G 0, B 0. I also set contrast and sharpness at -2. Low contrast to make sure the JPG output will contain the full dynamic range of the RAW sensor data, and low sharpening because I can do that better on the computer than the camera can. Once the camera has created harsh sharpening halos they can't be removed in editing.
The problem with the R channel being too high can cause problems when using any of the RGB histogram or zebra modes.
But there's always been a problem with the RGB Zebra mode. You have to set the OverExposure Threshold to 32 when using RGB Zebra in order to get it to display the C, Y, and M regions when when the B+G, R+G, and R+B channels (respectively) are blown out. I never use RGB Zebra because of this problem it has always had. Until this is fixed RGB Zebra really isn't all that useful for much of anything.
To see for yourself, load up a Granger Chart on your monitor (has all possible colors and luminance values displayed in even graduations). Then set your camera to RGB Zebra mode and set your camera's exposure settings so the lighter colors are all blown-out. You will only see the C, Y, and M areas fully appear when you set the zebra OverExposure Threshold to 32. Lower values than that and those regions of channel-combos that are blown out diminish greatly, where they completely disappear at OverExposure Threshold values of about 12 or less.
If you don't have a Granger Chart for testing (or know how to easily make one with your favorite editor) here's a downsized one you can use.
http://farm6.static.flickr.com/5307/5673254230_96f2049213_b.jpg (http://farm6.static.flickr.com/5307/5673254230_96f2049213_b.jpg)
-
@a1ex
>R = Y + 1.403V'
>G = Y - 0.344U' - 0.714V'
>B = Y + 1.770U'
can you please make out of your values code that can work in chdk ?.I look in your source, but i do not understand how i need change chdk so it get working.
the granger chart is a good test and it show that rgb zebra show 25 units too early overexpose in colors.so the chdk values of rgb seem not best possible and i like to try your values.
if you can add code so it work in integer, i can test if it work better.
thats the original rgb code
if (clip8(((yy<<12) + vv*5743 + 2048)>>12)>over) sel = 4; // R
if (clip8(((yy<<12) - uu*1411 - vv*2925 + 2048)>>12)>over) sel |= 4; // G
if (clip8(((yy<<12) + uu*7258 + 2048)>>12)>over) sel |= 4; // B
When i capture a image with rgb zebra and exposure correct on zebra, image look correct in jpg.but can be a little more erxposure get.In default zebra i get no overexpose warning in colors, and later colors are overexpose.RAW look a little less overexpose, but its still overexpose in colors.
I notice the Canon zebra show show too only Y value.
@newbietoobie
>The problem with the R channel being too high can cause problems when using any of the RGB >histogram or zebra modes.
On Ixus 1000 red channel is too a little higher.problem i have that this camera have no option to reduce sharpen
if this is possible i can avoid most times to use raw.
On this camera happen on hair for example that some hairs are shapren some hairs are more blur as RAW or contain blocks.superfine jpg save do not help, so i guess its depend on denoise
-
Bonjour,
I don't know why you are expecting precise zebra but ...
Current zebra is based on the viewport and is compute like the following integer formulas :
img = vid_get_viewport_live_fb ( );
triplets_in_bytes = 3 * ( buffer_width * ( row_offset + row ) + ( col_offset + col ) );
yc = img [ triplets_in_bytes + 1 ] * 4096;
cb = ( signed char ) img [ triplets_in_bytes ];
cr = ( signed char ) img [ triplets_in_bytes + 2 ];
red = clip ( ( yc + ( 5742 * cr ) + 2048 ) / 4096 );
green = clip ( ( yc - ( 1410 * cb + 2925 * cr ) + 2048 ) / 4096 );
blue = clip ( ( yc + ( 7258 * cb ) + 2048 ) / 4096 );
Note: I low-rounded 5743 and 1411 to 5742 and 1410 for precision purpose :) since rounding is included in "+2048"
These Viewport's YCbCr digital video data are resulting from CCD-to-Video signal process using sensor raw data as input.
RGB data are therefore approximate from YCbCr digital video data that is approximate from raw photo cells that approximate photons counts, due to noise :).
I still don't know why you are expecting precise zebra but ...
P.S.: You are in savana and look at a zebra, garnished with nice black & white stripes. When you shoot it, were the muscle more or less voluminous?
-
Another RGB Zebra oddity:
I don't know when this happened, which build number this transposition of code crept into, but now the RGB Zebra mode displays these colors when the following 2-channels each are blown-out:
R+B = Y
R+G = M
They've been reversed. Since I've not used RGB Zebra due to it failing to display the CYM colors unless the over-exposure threshold is increased far too much, I don't know how long ago the code got switched around like that. It used to be correct. R+B showed M(agenta), and R+G showed Y(ellow).
Since this requires fixing, perhaps someone can fix all the errors this time around? Make it really useful at long last? Would be nice.
-
Bonjour,
I don't know why you are expecting precise zebra but ...
I want photograph hair on sunlight, cosplay with shiny clothes(because it look much better in sun) and only with rgb zebra when no warning is show, i can be sure that the shine parts of hair or clothes is not overexpose.but if it can 10% more exposure is better.so wy not make it better if its possible. and default zebra is not usefull.
zebra should be precise as possible because even the CMOS BSi Sensor have many noise on ISO 125.when the Sensor is as good as a DSLR, then i have no problem to exposure all 2/3 darker to be sure what i want is not overexpose in important parts
when exposure darker as necessary give you much more noise on the small sensor.So when its possible to get better zebra results give better pictures.
thats same important as a casette player need for record a good levelmeter.A CD recorder need not so good levelmeter because have much better dynamic.
maybe you can tell how chdk formula look in float, so i can compare.thats a1ex write
>R = Y + 1.403V'
>G = Y - 0.344U' - 0.714V'
>B = Y + 1.770U'
but chdk add a value of 2048 to all, this mean +0.5 in red and green values.
in red 5742/4096 is 1.401.thats same as a1ex write.but chdk code add 0.5.
R = Y * 1.401 +0.5
-
so why not make it better if its possible. and default zebra is not useful?
zebra should be precise as possible.
So when its possible to get better zebra results give better pictures.
As a general principle, having a CHDK feature that works well is preferable to one that does not.
I like the attitude of Bernd about Zebra and support him. I hope others do too.
Now that Exmem works with 8Meg on my Ixus 95 Ixus 960 and G9, there is a good opportunity to make Zebra fully functional and usable on these and other models (thanks Whim). I am able to test any coding changes by a Dev.
I take the point of Reyalp about calibration and I think that calibration generally (colour, lens distortion, etc) is a potentially useful area for CHDK coding efforts.
Best,
Colin
-
I do more tests and i see the +2048 does not change much.
the rgb zebra view code is correct i think in chdk, the reason that colors get earlier overexpose is the Canon colorboost feature.so it happen that red, green, blue reach 240-250 but white only reach 200-220 max.
My Camera have no setting to reduce color satureation.But i find that when i choose in "my colors" Canon menu the setting N "Neutral reduce Color and Contrast" rgb zebra work perfekt.
white reach 240-250 max and other colors too.still the non rgb mode of zebra is wrong and so overexpose is possible, but in N mode this Problem is not so extreme with overexpose colors
@NewbieToobie
What camera you have ?
I think when you do a testshoot of Granger chart and your Camera have a Option my color N then it work ok in rgb zebra.
If you have a option to reduce saturation, you should reduce it until single color of r g b reach same max level as white.
-
Humm !
I don't know for your cam but mine, when exposed to direct sun, I see an overexposed vertical line on the viewport inline with the sun (ex: when I take a video of a sunrise). Therefore, the zebra is biased by the sensor-to-vide-conversion :(
-
Humm !
I don't know for your cam but mine, when exposed to direct sun, I see an overexposed vertical line on the viewport inline with the sun (ex: when I take a video of a sunrise). Therefore, the zebra is biased by the sensor-to-vide-conversion :(
I of course want not photograph the sun.maybe you do this test.photograph somebody with blond or red hair who stand in the sunlight.the sun is side or behind you, so no photograph direct in sun
with default zebra you see overexpose the shine in hair.with rgb zebra and neutral you get correct expose picture
-
...with default zebra you see overexpose the shine in hair.with rgb zebra and neutral you get correct expose picture
Now, I understand.
I would first suspect the value of "over".
over = 255-conf.zebra_over;
"over" is compared to viewport pixels to signal overexposure. It use the same "over" for "Y" and "RGB".
if (conf.zebra_multichannel)
{
uu = (signed char)img_buf[v];
vv = (signed char)img_buf[v+2];
sel=0;
if (!((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f))
{
if (clip8(((yy<<12) + vv*5742 + 2048)>>12)>over) sel = 4; // R
if (clip8(((yy<<12) - uu*1410 - vv*2925 + 2048)>>12)>over) sel |= 2; // G
if (clip8(((yy<<12) + uu*7258 + 2048)>>12)>over) sel |= 1; // B
}
;
buf[s]=buf[s+1]=cls[sel];
buf[s+2]=buf[s+3]=cls[sel];
}
else if (((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f))
buf[s]=buf[s+1]=COLOR_TRANSPARENT;
else
buf[s]=buf[s+1]=(yy>over)?cl_over:(yy<conf.zebra_under)?cl_under:COLOR_TRANSPARENT;
if (buf[s] != COLOR_TRANSPARENT && !zebra_drawn)
zebra_drawn = 1;
Comparing "Y" values and "RGB" values with "over" don't seam to be equivalent and, may be, it's because the "Y" component don't have the same scale (16-240) than "RGB" components (0-255).
en.wikipedia.org YCbCr (http://en.wikipedia.org/wiki/YCbCr#Name)
Is it sound good?
-
...with default zebra you see overexpose the shine in hair.with rgb zebra and neutral you get correct expose picture
Now, I understand.
I would first suspect the value of "over".
over = 255-conf.zebra_over;
"over" is compared to viewport pixels to signal overexposure. It use the same "over" for "Y" and "RGB".
if (conf.zebra_multichannel)
{
uu = (signed char)img_buf[v];
vv = (signed char)img_buf[v+2];
sel=0;
if (!((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f))
{
if (clip8(((yy<<12) + vv*5742 + 2048)>>12)>over) sel = 4; // R
if (clip8(((yy<<12) - uu*1410 - vv*2925 + 2048)>>12)>over) sel |= 2; // G
if (clip8(((yy<<12) + uu*7258 + 2048)>>12)>over) sel |= 1; // B
}
;
buf[s]=buf[s+1]=cls[sel];
buf[s+2]=buf[s+3]=cls[sel];
}
else if (((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f))
buf[s]=buf[s+1]=COLOR_TRANSPARENT;
else
buf[s]=buf[s+1]=(yy>over)?cl_over:(yy<conf.zebra_under)?cl_under:COLOR_TRANSPARENT;
if (buf[s] != COLOR_TRANSPARENT && !zebra_drawn)
zebra_drawn = 1;
Comparing "Y" values and "RGB" values with "over" don't seam to be equivalent and, may be, it's because the "Y" component don't have the same scale (16-240) than "RGB" components (0-255).
en.wikipedia.org YCbCr (http://en.wikipedia.org/wiki/YCbCr#Name)
Is it sound good?
yes, and its not only the diffrent range.
Maybe you can photograpgh the granger chart that is upload here,and look that no zebra blink in standard zebra.
http://farm6.static.flickr.com/5307/5673254230_96f2049213_b.jpg (http://farm6.static.flickr.com/5307/5673254230_96f2049213_b.jpg)
You can see many light colors are white now, when you look at the jpg image.
now switch to rgb zebra and do same.image is correct exposure, all colors are here.best you use fast ev switch 1/6 EV chdk setting, so you can change ev fast.
when use mycolors neutral, diffrence is not so much.
it seem happen that Y + U + v in term convert to a color, get more than 256.Y only is below 256.so only the RGB zebra show correct.
you can see when photograph on granger chart too.pure red or green or blue colors, contain very low Y.
when you are in standard mode you can enhance ev lots until pure red , or green or blue colors do blink with zebra overexpose warning.
but when you look on image they are large overexpose.sure they are not change to white, but you get texture loss in real world when you use normal zebra.
-
I get a look to your jpg and your explanation. Well, I am not sure that clipping is The problem.
I still think that the color transformation process from RAW color space to YCbCr color space for viewport display already clip things. After that, YCbCr to RGB transform is possibly reclipping too.
I think the issue here is: Y is working with luminosity and RGB is including color and saturation therefore the first transformation (RAW rgb -> YCbCr) has already interpret something. Converting YCbCr to sRGB is reinterpreting also.
http://www.couleur.org/index.php?page=transformations#YCbCr (http://www.couleur.org/index.php?page=transformations#YCbCr)
For example, take a russian site, use google translate to translate it in french and then retranslate it in english. I am not so sure it will be significant (meaningfull) :) May be you will start with a romantic text to finish with a conflictual editorial. :(
May be a RAW-based warning could be more useful. Like percentage of raw cells that is not within a raw range (exponentially corrected). A raw-based zebra could impair performance ?
P.S.: This image (http://en.wikipedia.org/wiki/File:AdditiveColor.svg (http://en.wikipedia.org/wiki/File:AdditiveColor.svg)) will zebra black and white areas in YCbCr and will zebra all the image area in RGB.
-
I get a look to your jpg and your explanation. Well, I am not sure that clipping is The problem.
I still think that the color transformation process from RAW color space to YCbCr color space for viewport display already clip things.
I do some test in windows paint.Here i define a color 0 red 255 green blue.
Now i see a output
brightness 120
saturation 240
tone 80
Is that YUV ?
If so, then if zebra check only y channel, a overexpose can not detect, because brightness is only 120
P.S.: This image (http://en.wikipedia.org/wiki/File:AdditiveColor.svg (http://en.wikipedia.org/wiki/File:AdditiveColor.svg)) will zebra black and white areas in YCbCr and will zebra all the image area in RGB.
You mean with default zebra mode the red green and blue area is not zebra, but in rgb zebra mode it work better ?
this happen with my cam.And thats the reason i think that only use Y channel in zebra is not so good as using u v too, for calculate overexpose
only when i use rgb zebra then pure colors get overexpose.but more clear you can see when you test zebra on a pure color object, because Monitor contain dots, and camera record average thru aliasing filter.
-
brightness 120
saturation 240
tone 80
Is that YUV ?
No, that would be HSV http://en.wikipedia.org/wiki/HSV_color_space (http://en.wikipedia.org/wiki/HSV_color_space)
YUV http://en.wikipedia.org/wiki/YUV (http://en.wikipedia.org/wiki/YUV) (see also http://en.wikipedia.org/wiki/YCbCr (http://en.wikipedia.org/wiki/YCbCr) )
If so, then if zebra check only y channel, a overexpose can not detect, because brightness is only 120
You are making assumptions, the image has undergone many transformations by the time it gets to MS paint ;)
-
What means zebra, or under/over exposure ?
It checks floor and ceiling limits relatively to a color space. If color space is:
- YCbCr (or YUV, likes), Y means luminance and floor/ceiling over CbCr is really interpretative;
- RGB, each tonal component represents additive color model's components. Each includes luminance and saturation of these components. Floor/Ceiling limits, apply to each or combine components are relevant to the luminance/saturation within this tonal component;
- HSL, Hue/Saturation/Lightness, it has the same complexity of interpretation as YCbCr where L is lightness and Hue/Saturation represent tonal and intensity of this tonal component.
- CieLab for LAB Cie color space where L means Lightness and a/b have similar interpretation as UV
- CieXYZ, ...
- ...
Well, the principal question is "What do you want to detect ?", "What do you want to check against what ?"
See, when I look at "Y" zebra on my display, it signals that the luminance is under/over predefined limits. When I set it to something else, I shall interpret zebra upon the selected color space component.
For example, supposed I developed CieLab zebras. "L" refers to lightness similarly to "Y", and a/b refer to signed color components (-127...+127) where I could put -100/+100 as counter-floor/ceiling. But I still have to interpret the meaning of these zebras.
For conclusion, RGB's R G B zebra, like CieLab's a/b, or YCbCr's Cb/Cr, or other color space's color components, are subject to "perceptual/personal" interpretation.
IMHO, the main purpose of zebra, and histogram too, is to display mathematical result from YCbCr viewport datas, refering to spectral information.
-
It seems to me that as a user trying to take raw pictures, you want to know which pixels in the raw will be >= white level or <= black level, or within some arbitrary margin of these.
If you are taking jpeg, the above may be sufficient as well, but that depends on Canons jpeg process.
Any attempt to get this from the viewport data is going to be an approximation. It's not clear to me that you can determine the best approximation without careful experiment. To the best of my knowledge, the transformations form sensor data->viewport YUV and sensor data->jpeg are not well characterized.
-
What means zebra, or under/over exposure ?
Well, the principal question is "What do you want to detect ?", "What do you want to check against what ?"
I want detect if Camera does not overexpose the important objects in red green and blue chaannel.white overexpose is handle with default zebra good.But if you want see if colors are overexpose you need switch to rgb zebra.
So i see default zebra is not usefull
I have find a converter tool that show with a given rgb value the YUV Output
http://web.forret.com/tools/color.asp?R=255&G=80&B=40 (http://web.forret.com/tools/color.asp?R=255&G=80&B=40)
I test
R 255
G 80
B 40
Y is only 50%
so if red channel is overexpose can not detect with Y only.
when use
R 255
G 255
B 40
http://web.forret.com/tools/color.asp?R=255&G=255&B=40 (http://web.forret.com/tools/color.asp?R=255&G=255&B=40)
Y is 90%
90% is a value of 255/100 *90 = 229
So zebra is only show with that color, if overexpose threshhold is set to 26.but then white overexpose is show too early
above colors i get in real world shoots
-
I understand your target.
The question is:
Is sensor data available before shooting in order to read preliminary sensor RGGB data before shooting and therefore create a sampled RAW histogram/zebra display ?
-
I understand your target.
The question is:
Is sensor data available before shooting in order to read preliminary sensor RGGB data before shooting and therefore create a sampled RAW histogram/zebra display ?
I do some testcode for Ixus 1000 that show frequently 4 pixel values as this
pixel pixel
pixel pixel
value of center Pixels( i use the code to find the bayer pattern it use).the RAW buffer is not continues update, the values are only on shoot correct.other time they are always same
But maybe other can test if this work on other Camera better.here is the code
http://chdk.setepontos.com/index.php?topic=5722.msg60215#msg60215 (http://chdk.setepontos.com/index.php?topic=5722.msg60215#msg60215)
So there must be for Ixus 1000 another RAW buffer that is used to calculate the preview.maybe this buffer is smaller, because for zebra is not every pixel need.
But if have yuv zebra only is still good enough to be usefull if in the calc u v is add to Y and then check this value for overexpose in standard zebra mode to.
-
I understand your target.
The question is:
Is sensor data available before shooting in order to read preliminary sensor RGGB data before shooting and therefore create a sampled RAW histogram/zebra display ?
If it is, I don't think anyone has ever found it. I would guess that something down in the hardware creates the YUV live buffer directly.
Thinking about my previous post, the sensor->YUV transformation is not constant. The viewport (and jpeg) both have white balance, the raw data does not. So without additional information, it's impossible to establish an RGB zebra from the viewport that really corresponds to the limits of the raw buffer. Canon "i-constrast" would also confuse things.
If the transformation used for the viewport and jpeg are close (one would hope so), you may still still be able to get a good idea of what will exceed limits in the jpeg, I guess.
-
If it is, I don't think anyone has ever found it. I would guess that something down in the hardware creates the YUV live buffer directly.
Thinking about my previous post, the sensor->YUV transformation is not constant. The viewport (and jpeg) both have white balance, the raw data does not. So without additional information, it's impossible to establish an RGB zebra from the viewport that really corresponds to the limits of the raw buffer. Canon "i-constrast" would also confuse things.
If the transformation used for the viewport and jpeg are close (one would hope so), you may still still be able to get a good idea of what will exceed limits in the jpeg, I guess.
If RAW zebra is possible, it give correct result when you save as RAW.So if it is possible to access RAW data it should only add when RAW is enable.
when RAW zebra show no overexpose, it happen maybe that jpg is overexpose, but the RAW file is ok.
but even if no RAW zebra is possible when in default zebra mode not only use y and calc r g b same as rgb zebra do, zebra is more precise
usefull for me is too, if there is a after shoot zebra view.that show overexpose in RAW buffer.it is possible before RAW save to generate zebra of RAW for the display.and then during RAW save, this zebra can show.
so time of RAW save can be usefull to look for overexpose, and so photographer can see if he better repeat the shoot.
-
Well, I made a little routine to get black and white count for HDR purpose.
http://chdk.setepontos.com/index.php?topic=6379.msg66629#msg66629 (http://chdk.setepontos.com/index.php?topic=6379.msg66629#msg66629)