Board index » delphi » Brightness & Contrast on AVI

Brightness & Contrast on AVI

Hi,
    does anybody know how to change the Brightness or Contrast of an AVI
file when playing? Thanx.
 

Re:Brightness & Contrast on AVI


Quote
Pablo Pedrocca <pjpedro...@onenet.com.ar> wrote in message

news:7npdlg$a0g2@forums.borland.com...

Quote
>     does anybody know how to change the Brightness or Contrast of an AVI
> file when playing? Thanx.

I would be surprised if you could do this under software control while playing
the AVI -- execept perhaps for very small images.

A brightness adjustment is easy -- you just "visit" each pixel and add a
constant value to the R, G and B components of the pixel.

Contrast enhancement is a bit trickier, especially for color images and
I doubt if this could be done by software in real time.  Some sort of
histogram stretching or histogram equilization would required going
through the image once to gather statistics and a second time to
make the adjustments.

With some hardware assistance (perhaps from DirectX?) this might be
possible.

___
efg

Earl F. Glynn     E-Mail:  EarlGl...@att.net
Overland Park, KS  USA

efg's Computer Lab:  http://www.efg2.com/Lab

Re:Brightness & Contrast on AVI


On Thu, 29 Jul 1999 08:37:14 -0500, "Earl F. Glynn"

Quote
<EarlGl...@att.net> wrote:
>Contrast enhancement is a bit trickier, especially for color images and
>I doubt if this could be done by software in real time.  Some sort of
>histogram stretching or histogram equilization would required going
>through the image once to gather statistics and a second time to
>make the adjustments.

You could apply a simple sigmoid-curve transformation; this would
enhance contrast, but obviously wouldn't be optimal in any sense. In
any case, as you say, the thought of trying to do this in real time on
anything but a small thumbnail boggles the mind.

-Steve

Re:Brightness & Contrast on AVI


Steve Schafer (TeamB) <pand...@telepath.com> wrote in message
news:37ac6e08.146295193@90.0.0.40...

Quote
> In
> any case, as you say, the thought of trying to do this in real time on
> anything but a small thumbnail boggles the mind.

With a 450 MHz processor, you can get a few frames per second with
images as large as 640-by-480 with simple pixel manipulations.

In a few years, with multi-GHZ processors, real-time may be possible
without extra help from the hardware.

efg

Re:Brightness & Contrast on AVI


geez! Contrast is a simple color transformation.. it can be calculated very
quickly into a lookup table and applied to each frame on the fly. (this is
taken from my graphics library FastLIB)

type TLut = array[Byte]of Byte; //lookup table

function ContrastLut(Amount:Integer):TLut;
var
  i,z: Integer;
begin
  for i:=0 to 126 do
  begin
    z:=i-((Abs(128-i)*Amount)div 256);
    if z>255 then z:=255 else if z<0 then z:=0;
    Result[i]:=z;
  end;
  for i:=127 to 255 do
  begin
    z:=i+((Abs(128-i)*Amount)div 256);
    if z>255 then z:=255 else if z<0 then z:=0;
    Result[i]:=z;
  end;
end;

function Lightnesslut(Amount:Integer):TLut;
var
  i,z: Integer;
begin
  if Amount<0 then
  begin
    Amount:=-Amount;
    for i:=0 to 255 do
    begin
      z:=i-((Amount*i)shr 8);
      if z>255 then z:=255 else if z<0 then z:=0;
      Result[i]:=z;
    end;
  end else // Amount > -1
  begin
    for i:=0 to 255 do
    begin
      z:=i+((Amount*(i xor 255))shr 8);
      if z>255 then z:=255 else if z<0 then z:=0;
      Result[i]:=z;
    end;
  end;
end;

applying the Lut is simple.. just loop through your pixels and
pixel.r:=Lut[pixel.r] !  this is a very fast method.. you can apply other
things such as gamma correction all in one Lut.. and apply all the
conversions in one pass!

Re:Brightness & Contrast on AVI


Quote
>But aren't you assuming pf8bit PixelFormat and palettes?
>Look up tables aren't used that much with high color or true color images.

think of an RGB image as three (8bit) grayscale images because the RGB
colorspace is orthagonal. So any lookup table can be applied to an RGB image
simply by using 3 lookup tables, or the same one for each r,g,b byte.

Quote
>How does your suggestion work with 15-bits/pixel high color
>pixels, or 24-bits/pixel true color images?

the same way it would work with an 8bit image. In an 8bit image you only
need to apply the lookup table to each r,g,b of each color in its color
table.. with 16,24,and 32 you apply the lookup table to each r,g,b of each
pixel.

Quote
>"Contrast" is really just using the whole range of an address
>space.  In a 256 shades of gray world, this means using
>the full range from 0 to 255 and is "easy" -- except there
>are a variety of ways to stretch the values to use the
>full range.

>With pf24bit images one might trying converting
>from RGB to HSV and then using some sort of contrast
>improvement on the "V" plane with the result converted
>back to RGB.  Sometimes this works.

>Please explain why you think contrast is a simple
>color transformation.  You can "stretch" one of the
>color planes, but that can introduce color shifts
>with the resulting image having the wrong color.

I said simple color transformation because contrast is applied to color, not
pixels.. and anytime you are just changing the color, you can put it into a
lookup table to apply to each and every pixel (because there are more pixels
than colors ;-).. if you still have trouble understanding, I can send you a
sample delphi project.. you adjust gamma correction and brightness the same
way

-Gordy
www.jps.net/gfody

Re:Brightness & Contrast on AVI


Quote
Gordy <gf...@jps.net> wrote in message news:7nr7b6$bkn1@forums.borland.com...
> geez! Contrast is a simple color transformation.. it can be calculated very
> quickly into a lookup table and applied to each frame on the fly. (this is
> taken from my graphics library FastLIB)

But aren't you assuming pf8bit PixelFormat and palettes?

Look up tables aren't used that much with high color or true
color images.

High color and true color images don't use palettes.

How does your suggestion work with 15-bits/pixel high color
pixels, or 24-bits/pixel true color images?

"Contrast" is really just using the whole range of an address
space.  In a 256 shades of gray world, this means using
the full range from 0 to 255 and is "easy" -- except there
are a variety of ways to stretch the values to use the
full range.

With pf24bit images one might trying converting
from RGB to HSV and then using some sort of contrast
improvement on the "V" plane with the result converted
back to RGB.  Sometimes this works.

Please explain why you think contrast is a simple
color transformation.  You can "stretch" one of the
color planes, but that can introduce color shifts
with the resulting image having the wrong color.

I've searched several image processing textbooks
and none explain contrast enhancements on
color images -- they all explain only how to do this
with achromatic images.

___
efg

Earl F. Glynn     E-Mail:  EarlGl...@att.net
Overland Park, KS  USA

efg's Computer Lab:  http://www.efg2.com/Lab

Re:Brightness & Contrast on AVI


Quote
Gordy <gf...@jps.net> wrote in message news:7nrrh4$c655@forums.borland.com...
> >But aren't you assuming pf8bit PixelFormat and palettes?
> >Look up tables aren't used that much with high color or true color images.

> think of an RGB image as three (8bit) grayscale images because the RGB
> colorspace is orthagonal. So any lookup table can be applied to an RGB image
> simply by using 3 lookup tables, or the same one for each r,g,b byte.

Yes, this is all very true.  Have you ever actually applied this to a color
image for contrast enhancement?  While the R-G-B planes are orthogonal
for defining color, you can't apply techniques appropriate for a single plane
to all three color planes without unintended side effects.  Or, I should say,
sometimes you can, but not always.

For example, histogram stretching (or histogram equalization) is a great
method of contrast enhancement.  You can easily apply this technique
to a shades of gray image with great results, e.g.,
http://www.efg2.com/Lab/ImageProcessing/HistoStretchGrays.htm
You need a single pass through an image, and if you're assuming palettes,
you can use a lookup table for a shades of gray contrast enhancement.

BUT if you apply this same technique individually to the planes of a color
image your results CAN be OK, but not always.  You'll get a high contrast
image, but your colors may not be correct.  For example, I have an image
of a yellow tulip with green leaves.  When you contrast stretch each of
the color planes individually, the yellows still look great.  BUT the green
leaves have become blue leaves.  The color histostretched image has
maximum contrast but not all the colors are correct.  Changing one
color plane independently from the other color planes sometimes is
OK, but there are cases in which the resulting colors are not
correct.

In the old DOS days you could easily control the hardware of graphics
cards to change the palette lookup table.  With Windows you don't
have a portable solution if try to directly change the hardware.  And
with high color and true color images, there is no palette to change
in the hardware.  The API call AnimatePallete (sp?) can be used in 256
color display mode since (I assume) it just changes the hardware
palette like in the old DOS days.  But this API call doesn't work
in high color and true color display modes, which are now more
common, especially on new machines.

Perhaps I'm wrong, but I think look up-table techniques will be
only effective in the older 256 color display modes, since the
 speed comes from the hardware doing the work.

It's fairly easy to have a single true color image with thousands
of colors.  For example, the famous "Mandrill" picture has
230,427 unique RGB "colors":
http://www.efg2.com/Lab/Graphics/Colors/ShowImage.htm
Using any kind of lookup table with this many unique colors
won't be very effective.

Real-time is fast and easy if you just change the palette
in 256 color display mode.
___
efg

Earl F. Glynn     E-Mail:  EarlGl...@att.net
Overland Park, KS  USA

efg's Computer Lab:  http://www.efg2.com/Lab

Re:Brightness & Contrast on AVI


Quote
>Yes, this is all very true.  Have you ever actually applied this to a color
>image for contrast enhancement?  While the R-G-B planes are orthogonal
>for defining color, you can't apply techniques appropriate for a single
plane
>to all three color planes without unintended side effects.  Or, I should
say,
>sometimes you can, but not always.

yes, I made a photoshop type program.. check www.jps.net/gfody  under delphi
stuff -> fastlib -> examples.. you can apply contrast, and I've never
experienced the 'side effect' you speak of

Quote
>BUT if you apply this same technique individually to the planes of a color
>image your results CAN be OK, but not always.  You'll get a high contrast
>image, but your colors may not be correct.  For example, I have an image
>of a yellow tulip with green leaves.  When you contrast stretch each of
>the color planes individually, the yellows still look great.  BUT the green
>leaves have become blue leaves.  The color histostretched image has
>maximum contrast but not all the colors are correct.  Changing one
>color plane independently from the other color planes sometimes is
>OK, but there are cases in which the resulting colors are not
>correct.

your contrast lut must be static and applied to every byte (color value),
and this will not happen

Quote
>In the old DOS days you could easily control the hardware of graphics
>cards to change the palette lookup table.  With Windows you don't
>have a portable solution if try to directly change the hardware.  And
>with high color and true color images, there is no palette to change
>in the hardware.  The API call AnimatePallete (sp?) can be used in 256
>color display mode since (I assume) it just changes the hardware
>palette like in the old DOS days.  But this API call doesn't work
>in high color and true color display modes, which are now more
>common, especially on new machines.

animate palette rotates the windows logical palette. you can achieve the
same effect by rotating an 8bit DIB's colortable in highcolor mode

Quote
>Perhaps I'm wrong, but I think look up-table techniques will be
>only effective in the older 256 color display modes, since the
> speed comes from the hardware doing the work.

the lookup table technique is what makes it fast. its really really fast
when you apply it just the color table of an 8bit dib (then hardware changes
the image), but is still extremely effective for high color images.. as the
lookup table still applies.  Have a look at the code and resulting image.

let me rephrase:  anytime you make a change to the color space of an image
(like changing a certain value of red to zero).. you can apply the change to
any image very quickly with three lookup tables.. this is how contrast, and
gamma correction is applied in your video hardware as well

-Gordy

Other Threads