POV-Ray : Newsgroups : povray.general : image_pattern bug Server Time
3 Aug 2024 18:20:02 EDT (-0400)
  image_pattern bug (Message 1 to 3 of 3)  
From: Christian Walther
Subject: image_pattern bug
Date: 29 Oct 2003 05:14:15
Message: <pan.2003.10.29.10.14.23.688740@gmx.ch>
Digging around in POV's source (3.50c for Unix), I remembered another bug
that I had discovered some time ago (and I'm pretty sure that this one
*is* a bug ;) ):

The pattern values generated by an image_pattern with a color image do not
range from 0 to 1, but from 0 to something between 0.9 and 1 (it turns out
to be 0.93). This can be seen in the following scene:

camera { location <0, .5, -2> look_at <0, .5, 0> }

#default { finish { ambient 1 } }

#declare Stripes = color_map {
  #local I = 0;
  #while (I < 1)
    [I rgb I+.1]
    [I+.1 rgb I+.1]
    #local I = I + .1;
  #end
}

box {
  <-1, 0, .1>, <-.05, 1, 0>
  pigment {
    gradient y
    color_map { Stripes }
  }
}

box {
  <.05, 0, .1>, <1, 1, 0>
  pigment {
    image_pattern { gif "gradient.gif" }
    color_map { Stripes }
  }
}

where gradient.gif contains a grayscale gradient from white at the top to
black at the bottom (because the gif image is paletted, it is still
processed as a color image). The two boxes should look (approximately) the
same, but they don't.

This is caused by the line

  Value = (0.229 * colour[pRED] + 0.587 * colour[pGREEN] + 0.114 *
  colour[pBLUE]);

in image_pattern(...) in image.cpp: These coefficients do not add up to 1,
but to 0.93. This seems to be a typo, because using 0.299 instead of 0.229
changes the sum to 1.

Looking through image.cpp, I see that the same wrong coefficients are also
used in bump_map(...) (three times).

Furthermore, I see that in png_pov.cpp and ppm.cpp, different coefficients
for RGB to grayscale conversion are used: 0.30, 0.59, 0.11. Still others
(0.297, 0.589, 0.114) are used in the macros GREY_SCALE and GREY_SCALE3 in
colour.h which were probably defined just to end this inconsistency, so I
guess the proper fix would be using these macros instead of hardcoded
coefficients everywhere. According to my tests, the image_pattern bug is
indeed fixed by using

  Value = GREY_SCALE(colour);

instead of the line cited above in image_pattern(...) in image.cpp.

 -Christian


Post a reply to this message

From: ABX
Subject: Re: image_pattern bug
Date: 29 Oct 2003 05:36:31
Message: <3j5vpvk5ho43cc4deo81conn2hcfrcln0f@4ax.com>
On Wed, 29 Oct 2003 11:14:26 +0100, "Christian Walther" <cwa### [at] gmxch>
wrote:
> Digging around in POV's source (3.50c for Unix), I remembered another bug
> that I had discovered some time ago (and I'm pretty sure that this one
> *is* a bug ;) ):

It's not a bug, it's a typo ;-)

Ok. color2gray conversion is already changed and unified for several places of
source code. it is even more than marked in sources of MegaPOV 1.0 with
CONNECT_GRAY_EVALUATION_PATCH.

Anyway, thanks for helping

ABX


Post a reply to this message

From: Christian Walther
Subject: Re: image_pattern bug
Date: 29 Oct 2003 06:34:14
Message: <pan.2003.10.29.11.34.27.21211@gmx.ch>
> Ok. color2gray conversion is already changed and unified for several places of
> source code. it is even more than marked in sources of MegaPOV 1.0 with
> CONNECT_GRAY_EVALUATION_PATCH.

Fine. I just checked, and the image_pattern bug is indeed already fixed in
MacMegaPOV 1.0 (in the same way I suggested). The calculations in
bump_map(...) are still the old (wrong) ones in the MacMegaPOV 1.0 source,
so I guess this is one of the places you are referring to by "even more". 

 -Christian


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.