PhilM hat geschrieben: ↑Do 24 Jan 2019 16:53Could you explain the calculation of the Mean, Std deviation and Median at the bottom of the histogram panel ?
Mean: sum of all pixel values / number of pixels
Std deviation: square root of ((sum of squares of all pixel values / number of pixels) - square of mean)
Median: if all pixel values are sorted ascending, the median is the pixel value in the middle of the resulting list
Martin
"Value" is the V number of HSV ?
Correct ?
See my attached picture : big gray rectangle RGB 128,128,128 (Picture info panel V=128)
Small red rectangle RGB 83,0,0 (Picture info panel V=83)
Small green rectangle RGB 0,173,0 (Picture info panel V=173)
That results in a mean value of 80.21 displayed in the histogram panel .
The calculated mean is smaller than all 3 colors of the picture !
As the two small rectangles have the number of pixels, I would have expected Mean = 128
Median shows 70.
I would have expected 128
Did I miss something ?
Thanks
Philippe
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
I did a pixel count of the image, using an histogram correction layer.
And I found a bunch of black pixels at the extreme left of the histogram. Although there is no black area in the image.
0/292 842
83/73 128
128/344796
173/73 292
The 292842 black "pixels" pull the mean down to 80 ...
I noticed that the number of black pixels is 2 times the total of the red and green pixels.
PhilM hat geschrieben: ↑Do 24 Jan 2019 21:58
It seems you are calculating the mean of all channels instead of the mean of the pixel value.
We don't use HSV data, but merge the single channel data (R, G, B) in order to get the same results as other applications. We did succeed with the mean and the standard deviation, but the median is a bit different.
I think it might be worth remembering here that a lot of statistics in common use only really apply to normal distributions ie distributions with the so called bell shaped curve, and most histograms make it clear the pixels are not normally distributed. The essence of a normal distribution is that it is both symmetrical and crucially predictable, eg 95% of the values lie within the range -2xSD to +2 x SD.
When the distribution is not normally distributed, common statistics can be misleading, and some (like the SD) effectively become meaningless. We all know how a few very high earners (so not a normal distribution) can cause average earnings to be misleadingly high (better here to use median not mean earnings) and there are far too many cases in the medical literature of researchers who should know better reporting results like mean haemoglobin 10 (SD 5) which means some of their patients had a haemoglobin of zero.
It is also sometimes as well to ask what are we actually measuring? With a variable like height it is easy enough, but with other things - like pixel values - it gets more complicated. Are we using the 0-255 value from HSV? The sum of RGB? Some other number? See the above discussion for further, err, clarification.
It was these considerations that I had in mind earlier when favouring the use of the median to determine the midpoint/line of the underwater sections, as it is the simplest most transparent least corruptible measure which can be used to divide the shape into two halves each containing an equal number of pixels where each half has it's own unique colour, the midpoint/line being the line where moving it one pixel either way changes the median from being the value of one side to the value of the other side.
More opportunities for further and better confusion: consider a 3x3 grid of nine RGB not grey scale pixels. Eight of the pixels are very dark grey (RGB 1,1,1) and one of the pixels is white (255,255,255). Which measure (statistic) best describes the 'average'?
Ordinary mean (arithmetic, sum RGB then add RGB sums and divide by n (9) and then by 3 to get RGB values): 29,29,29 => pretty meaningless
Median: 1,1,1 => not too bad, eight of the nine pixels are this colour
Geometric mean (sum RGB, multiply RGB sums and take the nth (9th) root and then divide by three to get RGB values): 2,2,2 => better, but...
I was thinking about 2 things:
-A small vector layer with the adjustmoent "channel mixer" to swap red and green. With that you could fill the whole water in red and turn it green with the overlay. Other ways, like a hole in the black hull to peek at underlying colors, are just as easy.
-An "average" filter would return a neutral color when read and green fill equal areas. So with adjusting levels and full saturation you could tell by the color when both areas have the same size.
But there's no "average" adjustment, and placeholders don't update in real time.
But maybe the simple box blur ("soften") can do if the picture is small enough?
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
Hoogo - the average filter is an interesting idea, another way to access the mean - only as you found it isn't actually a filter, it's just 'Calculate average' and it applies the average to the selected areas on the layer immediately. But it might be useful if used with the history stack (try one adjustment, do the average and read colour, back again and re-adjust and re-average etc) - no, that doesn't work (anterograde history gets obliterated, so have to redo the 'Calculate average'). It also, as you note, needs the colour set up so there average is neutral. Colour position markers do update in real time, so there is less clicking to do.
cathodeRay hat geschrieben: ↑Di 22 Jan 2019 21:40
Phil - yes, that seems to work. See the image below. 127.99 was the closest I could get - if I changed another 1 pixel band it went over 128 by more than 0.01, to 128.03, so 127.99 was the closest I could get to 128.00.
- Using more extreme gray values allows better checking of the result. You could for example use 16 and 240 for the two areas.
- If the layer move tool is the active tool, you can use the arrow keys to move the clipping layer by one screen pixel. So zooming in allows subpixel movement.
- If you set the antialiasing of the layer mask to "Always" (in the Layer Attributes), it will use a higher rendering quality.
This way I have been able to get a precise 128 with my sample document.
Martin - that all makes complete sense as a way of refining the process, but I still find I can't hit 128 exactly, even with very high zoom levels. I wonder if this is because although we can 'see' sub-pixels, they don't really exist (at 100% zoom), and furthermore (because of the nature of pixels, as discrete entities) its hit and miss as to whether we can ever hit a mid point. Consider the case of a 1 x 9 pixel line: the mid point is 4.5 pixels, but 4.5 can't exist, so the dividing line has got to be between either pixel 4 and 5 or 5 and 6.
That said, I think the accuracy I am already able to get (within a fraction of 1%) is good enough, and probably less than other inaccuracies eg the real yacht's lines are traced digitally by hand from old drawings that were themselves not always 100% perfect, and the old time way of doing the test for the mid-line (balancing a stiff paper cut-out of the section on a knife edge) was itself prone to minor errors eg marking the paper where the knife edge had been, and even the width of the pencil line itself. The digital method also makes it very easy to be sure the line is perpendicular to the waterline, which matters because what we are really interested in is the centre of buoyancy. If the paper method produced a line that was not exactly at 90 degrees to the waterline, then, depending on where the measurement was taken, another source of error could creep in (the line would still pass through the centre of balance/buoyancy, but the line's distance from say the centreline would vary with height, and would only be accurate at the (unknown) vertical height of the centre of buoyancy, which was not determined according to surviving written descriptions of the old time methods).
One of the useful things about doing this digitally is we can always go back and recheck if need be, whereas in the old days the paper cut-outs would probably have been discarded once they had been used.
For anyone who wants to research the method further, it's usual name is Turner's Metacentric Shelf theory. Rear Admiral Turner, as he became, was primarily interested in designing balanced model yachts, but his thinking became incorporated into full size yacht design for a while, notably by Harrison Butler, and his book 'Cruising Yachts: Design and Performance' (1945) contains a detailed (though it has to be said not always immediately grasped) description of the method. Interestingly, soon after the method had got established, others discredited it, pointing out that it was a hydrostatic model (still hull sitting in still water) and that a real yacht under way is anything but static, and therefore the theory couldn't apply. But for some unexplained reason, yachts that have a good metacentric moment profile (the second part of a metacentric analysis) are generally well balanced, and those that have a poor profile tend to be difficult to handle, so the theory does have some practical use, even if we don't know exactly how it works (my own hunch is that it is because the key part of the assessment is relative, so although the absolute numbers might be wrong, they are nonetheless useful because the relative contributions do reflect reality, if that makes sense).
cathodeRay hat geschrieben: ↑Di 29 Jan 2019 11:13
Martin - that all makes complete sense as a way of refining the process, but I still find I can't hit 128 exactly, even with very high zoom levels. I wonder if this is because although we can 'see' sub-pixels, they don't really exist (at 100% zoom), and furthermore (because of the nature of pixels, as discrete entities) its hit and miss as to whether we can ever hit a mid point. Consider the case of a 1 x 9 pixel line: the mid point is 4.5 pixels, but 4.5 can't exist, so the dividing line has got to be between either pixel 4 and 5 or 5 and 6.
If there is a subpixel position, it will be antialiased, depending on the area occupied. So if you have a black rectangle on white background with a position of 4.5, the edge pixel will have a value of 128. You can check that by turning on pixel mode ("View > Pixel Mode").
So antialiasing increases the precision.
