Rick Simon wrote:
> Uni <plgp...@usa.net> wrote in news:3CBB999F.71849F3D@usa.net:
> > Sometimes when I adjust the Low and/or High values of the
> > Histogram, I end up with a graph with steep, but very narrow,
> > dropouts in it. Does this mean there is something wrong with the
> > image? How do you go about setting the High and Low values of the
> > Histogram and avoid this?
> There's nothing inherently wrong with that, John. When working with
> the Histogram, it's helpful to understand that the graph you are
> looking at does not represent the image itself. Instead, it
> represents the distribution of colors within the image.
> For instance, as Kris pointed out in a recent posting, lets say you
> were to write a small program that simply rearranged all the pixels
> in an image in a random manner. Not changed the color value of any of
> them mind you, just moved them around within the image in a random
> manner. You would end up with an image that looked like random noise.
> If you were to look at the Histogram for that "randomized" image and
> compare it to the Histogram for the original image though, you would
> see that the two Histograms were exactly the same! A Histogram does
> not deal with shapes or areas. It simply divides the pixels within
> the image up into brightness levels from 0 to 255 and graphs them
> out. It doesn't care where the pixels are within the image, it only
> cares how bright each one is.
> As an example to illustrate what you are seeing with a Histogram
> adjustment, let's say you are working on a grayscaled image (easiest
> to explain) and using a Histogram to adjust Luminosity. Let's say
> that this image has a large flat area with zero data that extends
> inwards from the left edge of the Histogram for about 1/2". What does
> that tell you? To me, it says that there are very few (or no) pixels
> in the image that are pure black (0,0,0 - corresponds to the leftmost
> edge of the Histogram). Furthermore, the further I go from the left
> edge before I encounter data (or a rise in the graph), the more
> shades of dark gray (1,1,1 or 2,2,2 or 3,3,3...) there are that are
> not being used. By the time I've gone roughly 1/2" into the
> Histogram, I'm up to 45,45,45. If the line in the Histogram is still
> flat, that means that the image has no pixels in it that are
> utilizing any of those dark gray colors, from pure black 0,0,0 to
> dark gray 45,45,45.
> Let's say that our image also has a correspondingly large flat area
> on the right side as well. That tells me that the image is also not
> using pure white (255,255,255) or a number of shades of very light
> gray. For the sake of simplicity, we'll say that the right side is
> pretty much like the left side and that we can come inwards around 45
> shades of gray before we find any rise in the Histogram. That means
> that the image is also not using white or any shade of light gray
> above 210,210,210.
> Overall then, we have an image that is only using 166 shades of gray
> out of the total 256 shades that are available to us. As with any
> process that reduces the numbers of colors available, this tends to
> reduce the quality of the image. To make matters worse, this "color
> reduction" did not make use of any sort of optimized algorithm to
> reduce the colors while maintaining image quality. It simply chopped
> off the upper and lower ends.
> Here's where the Histogram comes into play. By setting the lower and
> upper "clip limits" to 45 and 210 respectively, we are telling the
> Histogram tool that we want any pixels currently at 45,45,45 to
> become 0,0,0 (pure black) and any pixels at 210,210,210 to become
> pure white (255,255,255) when the Histogram Adjustment is applied.
> All other pixels throughout the entire image will also have their
> shade adjusted, correspondingly. What we are doing is, we are taking
> all of the current color values within the image and "stretching them
> out" so that they cover the entire gamut of available colors, from
> pure black to pure white. In our example image, that equates to
> taking 166 shades of gray, and spreading them across the 256 possible
> So how does the Histogram do that? It simply intersperses "empty"
> shades in between "full" shades in order to spread things out. For
> instance, let's say that in our original image, we had lots of pixels
> that were at shades 127,127,127 128,128,128 and 129,129,129. They
> would have made a solid appearing "bump" in the middle of the
> Histogram. After applying our Histogram adjustment however, we might
> now find that the pixels that were at 127,127,127 have now had their
> color shifted downwards by one to 126,126,126 to help "fill in" those
> empty first 45 shades of dark gray. The pixels that had been at
> 126,126,126 had also had their value reduced to 124,124,124 and the
> pixels at 125,125,125 had their value reduced, etc. This continues
> down the line until the available darker colors are spread across
> that "empty" area that used to exist on the left side of the
> Histogram. The pixels at 128,128,128 stayed where they were since
> they were right in the middle. Similar to the darker shades, the
> pixels at 129,129,129 and higher, had their colors changed upwards to
> fill in those 45 shades of light gray that had been empty.
> When the Histogram "spreads out" the available shades to fill those
> empty areas, it leaves gaps where none existed before. For instance,
> in our example above the shades at 127, 128 and 129 were side by
> side. After the Histogram adjustment however, they are now separated
> by a single empty shade in between each one. Visually, what was once
> a solid bar now appears as a series of three "spikes". The key to
> remember here though, is that we are dealing with a graph of
> brightness values, not the image itself. While you can see these
> "spikes" and they appear obvious to you in the graph, when it comes
> to looking at the image itself, it's an entirely different story.
> What we have done is, we have gone from a difference between three
> mid grays at 127,127,127 to 129,129,129 in the original image, to a
> difference between three mid grays of 126,126,126 to 130,130,130. To
> the human eye, such minor differences are extremely difficult to
> detect when they appy to such small differences in shading.
> So, understanding this, as far as your original questions are
> concerned, the "short answer" is:
> No. Having those spikes in the Histogram are nothing to be concerned
> about (IMHO).
Rick, this is your usual very fine explanation of course.
Permit me to add just two things. You said that the histogram
"doesn't care where the pixels are within the image, it only
cares how bright each one is". That's exactly true. However,
in real life different regions of the image often correspond
approximately to different portions of the histogram. For
instance the black dress or suit is in a different region
from the light face. This is what sometimes makes it possible
to threshold an image to extract objects approximately and
what connects the subject matter to the histogram. It is
also why I made the suggestion I did in response to Kerry's
"stupid question time, how did I do this effect?" post.
(But, of course, you knew that :) The other point is that
you can't use a histogram adjustment to create data. If
the histogram occupied only part of the 0 to 255 brightness
range stretching it will improve contrast and make the image
look less washed out. The price might, however, be visible
banding in some regions. Because the histogram doesn't
know or care where a pixel is in the image, it cannot
somehow insert a pixel of intermediate shade between the
steps of the banding since it doesn't know where to place
it in the image in a way that makes sense for the subject.
As was discussed elsewhere in the thread, any form of
blurring, because it is spatially oriented, will introduce
new brightness levels in the histogram and place them in
the correct part of the image - but your image looks
blurred :) As a result, in the case of moderate banding
your best bet may be Edge Preserving, which can be the
compromise that lets you get the best of both worlds - not
many steps in the histogram and not much blurring of detail.
> Rick Simon
Kris Zaklika Jasc Software, Inc. The
Product Ideas: id...@jasc.com Power
Customer Service: customer.serv...@jasc.com To
Technical Support: tech...@jasc.com Create