(The bug can be avoided by never using image interpolation)

---

While working on a renamed and refurbished material_map{} feature for 
the yuqk fork, ran across a bug where non-indexed / non-palette image 
was - by numerical noise - sometimes slipping into an indexed state of 0 
when interpolation was used. This happening no matter whether the base 
image was indexed or not.

The bug traced to two functions in imageutil.cpp called 
InterpolateBicubic() and Interp(). These are general routines so the 
exposure touches any code which looks at the calculated 'index' value to 
decide later actions.

The fix I used was to apply rounding rather than a cast to int when 
returning the index value - which is always calculated alongside the red 
/ grey color channel. (Yes, the index values themselves are interpolated 
too for actual indexed images)

---
In InterpolateBicubic() change:

   *index = (int)tempIndex;
to:
   *index = (int)std::lround(tempIndex);

---
In Interp() change:

   *index = (int)temp_index;
to:
   *index = (int)std::lround(temp_index);


Find attached a sample scene for v3.8 beta 2 and an image where the top 
portion shows noise from the bug and the bottom being the yuqk fork's 
current output for the same set up with the fixes above applied.

Bill P.

Post a reply to this message

Attachments:
Download 'image_indexed_textures_v38.pov.txt' (2 KB) Download 'material_map_bug.jpg' (198 KB)

Preview of image 'material_map_bug.jpg'

[using v3.7.0 and v3.8 beta 1 in Windows 10]

The material_map feature is new to me; I don't think that I have ever used it in
a scene-- probably because I never use 'indexed' images. But your post spurred
me to take a look at the documentation, and to try it out.

Instead of using a true indexed image, I decided to make a typical .png 24-bit
image for use in the map, by following the docs' example code at  "2.3.5.11 When
All Else Fails: Material Maps". (The material_map pattern still makes use of
so-called 'indices' in the image, but they are the red-channel gradations of
0/255, 1/255, 2/255 etc, rather than 1,2,3 etc.) I rendered this initial image
with *no* antialiasing, which makes a big difference...and *no* interpolation
later, when I used it in the map.

So far, I have not been able to reproduce the 'noise' that you mentioned-- but I
discovered something else: Once I carefully made the preliminary image for the
material_map, and added the required number of textures to correspond to the
'indices' of its red-channel steps, the final rendered texture results did not
quite correspond correctly to the indices: A few textures were missing.

After a lot of double-checking of my code and some experimentation, I made a
'lucky informed guess' as to the cause: It turned out to be a gamma issue. To
make the initial image for use in the material_map, I had used assumed_gamma 1.0
as usual, and with my File_Gamma as 'srgb' (as usual). But this 'mis-match' of
gammas caused the problem! So I re-made the image, keeping assumed_gamma at 1.0
but *changing* the File_Gamma to 1.0 to match it-- and the missing textures
appeared correctly in the final material_map render. (Using assumed_gamma 2.2
and a matching 2.2 File_Gamma also solves it.) Apparently, those two gamma
values need to be the same for that initial render, so that the material_map
code will then work correctly with it under-the-hood.

I don't yet know if this problem affects true 'indexed' images.

This solution leads me to believe that, when the material_map code was first
implemented in POV-ray long ago, the various gammas of rendering might have been
different than they currently are... possibly with a gamma of 2.2 being used
across-the-board, or by default. That's my guess.

Post a reply to this message

On 1/18/25 09:09, Kenneth wrote:
> [using v3.7.0 and v3.8 beta 1 in Windows 10]
> 
> The material_map feature is new to me; I don't think that I have ever used it in
> a scene-- probably because I never use 'indexed' images. But your post spurred
> me to take a look at the documentation, and to try it out.
> 
> Instead of using a true indexed image, I decided to make a typical .png 24-bit
> image for use in the map, by following the docs' example code at  "2.3.5.11 When
> All Else Fails: Material Maps". (The material_map pattern still makes use of
> so-called 'indices' in the image, but they are the red-channel gradations of
> 0/255, 1/255, 2/255 etc, rather than 1,2,3 etc.) I rendered this initial image
> with *no* antialiasing, which makes a big difference...and *no* interpolation
> later, when I used it in the map.
> 
> So far, I have not been able to reproduce the 'noise' that you mentioned-- but I
> discovered something else: Once I carefully made the preliminary image for the
> material_map, and added the required number of textures to correspond to the
> 'indices' of its red-channel steps, the final rendered texture results did not
> quite correspond correctly to the indices: A few textures were missing.
> 
> After a lot of double-checking of my code and some experimentation, I made a
> 'lucky informed guess' as to the cause: It turned out to be a gamma issue. To
> make the initial image for use in the material_map, I had used assumed_gamma 1.0
> as usual, and with my File_Gamma as 'srgb' (as usual). But this 'mis-match' of
> gammas caused the problem! So I re-made the image, keeping assumed_gamma at 1.0
> but *changing* the File_Gamma to 1.0 to match it-- and the missing textures
> appeared correctly in the final material_map render. (Using assumed_gamma 2.2
> and a matching 2.2 File_Gamma also solves it.) Apparently, those two gamma
> values need to be the same for that initial render, so that the material_map
> code will then work correctly with it under-the-hood.
> 
> I don't yet know if this problem affects true 'indexed' images.
> 
> This solution leads me to believe that, when the material_map code was first
> implemented in POV-ray long ago, the various gammas of rendering might have been
> different than they currently are... possibly with a gamma of 2.2 being used
> across-the-board, or by default. That's my guess.
> 

Thanks for the feedback. I think I need to tweak my documentation on 
gamma. Up front I recommended it not be used because I assumed these 
'indexed aimed' images would be written at a file gamma of 1.0 where the 
red channel was used, but you're right, ultimately gamma while reading 
an image file needs to match the gamma encoding for the image (*) when 
it was written. Excepting indexed images, for which the gamma settings 
should not matter.

(*) - IIRC the default srgb set up with png files for recent official 
v3.8 releases has an issue where the srgb block is not being written. 
This was fixed in the yuqk fork.

Did you intend to attach an image to your post?

The noise issue can only show up if one of the interpolation modes is 
used. It's more likely to be there for interpolations 3 and 4. It didn't 
show up for me always with linear interpolation. In being numerical 
noise, it might be somewhat sensitive to compiler settings too.

Bill P.

Post a reply to this message

So, I may be way off base here, but I just wanted to speculate, to promote
clarification of what's going on.

It occurred to me that what Kenneth might be seeing is an artifact of one gamma
"stretching" the color values sufficiently so that they skip over some of them.
I now also wonder if he's missing a "compression" in another part of the
mapping, where one value gets represented twice, and so it _looks_ like a single
instance.

Probably something to do numerically rather than graphically to really see
what's going on.

Just some thoughts.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/18/25 09:09, Kenneth wrote:
> > [using v3.7.0 and v3.8 beta 1 in Windows 10]
>
> Did you intend to attach an image to your post?
>

I was going to originally, but the image may not have been very informative
without comparing it the test code I used. So I have attached the code here
instead.

It uses a switch, to first *create* the 24-bit .png image-- which needs to be
renamed as "MMT" --then to use that image to run the material_map/textures
result. (This code is my own slight re-working of the documentation's example
and uses only five texture entries in the material_map.)

> IIRC the default srgb set up with png files for recent official
> v3.8 releases has an issue where the srgb block is not being written.
> This was fixed in the yuqk fork.

I didn't know that. Although, for all of my usual .png renders in 3.8 beta 1,
Ive's IC app reports them as having the correct sRGB embedded gamma.

from BE:
> It occurred to me that what Kenneth might be seeing is an artifact of one
> gamma "stretching" the color values sufficiently so that they skip over
> some of them. I now also wonder if he's missing a "compression" in another
> part of the mapping, where one value gets represented twice, and so
> it _looks_ like a single instance.

I have been contemplating that idea as well, if I understand your meaning. For
example, an sRGB 'File_Gamma' has a slightly different 'curve' from straight 2.2
gamma, at the low and high ends of its brightness(?) representations (if I
understand this stuff sufficiently.) And both of those gammas vary greatly from
a straight 'linear' gamma 1.0, of course. So numerically, these odd combinations
between assumed_gamma and File_Gamma don't match-- which will throw off the
material_map's indices of textures vs. red-channel brightness values.

To truly see where all of these differences occur in a material_map, an
interesting experiment would be make the 'preliminary' .png image with 256
distinct levels of brightness in the red channel-- and then to create 256
different texture entries in the material_map, to correspond! (I think my posted
code here could probably be re-jiggered to automatically do all of
this...although the visual result might be a bit difficult to interpret in a
meaningful way!)

Post a reply to this message

Attachments:
Download 'material_map_tester_kw.pov.txt' (2 KB)

On 1/19/25 05:28, Kenneth wrote:
> I didn't know that. Although, for all of my usual .png renders in 3.8 beta 1,
> Ive's IC app reports them as having the correct sRGB embedded gamma.

Thanks for the scene code! :-)

I don't have a v3.8 beta 1 compile currently and I cannot find the 
newsgroup post where I wrote about the png, sRGB block bug...

Using your scene; Once I have created an MMT.png file (using 
file_gamma=1.0 on the command line), if I run:

   p380b2 material_map_tester_kw.pov

I get an output file size of 6625 bytes. When I use the command:

   p380b2 material_map_tester_kw.pov file_gamma=srgb

I get an output file size of 6638 - because the srgb block has been 
added with the latter command (13 bytes larger). It's not there by 
default and should be (and for a LONG while it was. It should be there 
in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.

You can 'see' whether the srgb block exists in any png file by looking 
at the first 100 bytes or so in an editor or by using a command to write 
those initial bytes to the screen of a terminal window. On linux:

'head -c100 my.png'

	�PNG
�
IHDR 'gAMA��
             �asRGB���s��O�tIME�
--
               above

When you run v3.8 beta 1 without using 'file_gamma=1.0' on the command 
line (or as an ini setting), do you see the sRGB text in the png file?

The sRGB block being missing leads to an inconsistency where we cannot 
make a read-->immediate_write, srgb round trip of an png image through 
POV-Ray without image changes.
---

On the interpolation noise bug, I ran your scene with 'interpolation 3' 
and I do see it with my v3.8 beta 2 compile (top). See attached image - 
the current yuqk result on the bottom.

---

With the traditional material_map implementation, if you have in the 
index control image (MMT.png), indexes larger than the length of the 
texture list it gets wrapped back onto the list with a sort of 
'mod(index,txtr_list_length)'.

I thought this approach confusing. Now in yuqk, the map overruns are set 
to the index zero texture.

Regions outsides the effective mapping and/or 'once' area (or to actual 
indexed image indexes which are transparent I believe) already get 
mapped to the zero index. I think it makes sense to map out of bounds 
indexes to the zero index in the same way.

---

Bill P.

Post a reply to this message

Attachments:
Download 'material_map_tester_kw_noise.jpg' (51 KB)

Preview of image 'material_map_tester_kw_noise.jpg'

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/19/25 05:28, Kenneth wrote:
> > I didn't know that. Although, for all of my usual .png renders in 3.8 beta 1,
> > Ive's IC app reports them as having the correct sRGB embedded gamma.
> ...
> When you run v3.8 beta 1 without using 'file_gamma=1.0' on the command
> line (or as an ini setting), do you see the sRGB[**] text in the png file?

no, you're correct.  have attached output of a quick 'hexdump'[*], comparing
images rendered by beta.2 and the recent yuqk.

[*] easier to read :-).
[**] another "easy" one for the 1st commit ;-)


regards, jr.

Post a reply to this message

Attachments:
Download 'betavyuqk.png' (40 KB)

Preview of image 'betavyuqk.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I may be way off base here, but I just wanted to speculate, to promote
> clarification of what's going on.
>
> It occurred to me that what Kenneth might be seeing is an artifact of one gamma
> "stretching" the color values sufficiently so that they skip over some of them.
> I now also wonder if he's missing a "compression" in another part of the
> mapping, where one value gets represented twice, and so it _looks_ like a single
> instance.
>
> Probably something to do numerically rather than graphically to really see
> what's going on.
>
> Just some thoughts.

One thing you might try is, rather than use png, use gif.

https://en.wikipedia.org/wiki/GIF

It seems that gif exclusively used an indexed color palette (color look up
table).

Then you can simply open the gif in IrfanView, and use Image > Information, and
it will tell you how many unique color indices you have.

If you're going to do graphic / visual experiments, it might be worth assembling
a color_map such that your color entries are non-adjacent in the color wheel.
So, all of the even entries would be "monotonically" increasing from 0, and all
the odd entries would get shifted - say, by adding 127, and taking mod(N, 255)
to get the result that's "wrapped around to 0".
That way, you get maximum contrast between color indexes, and might be better
able to see doubled entries.
You'd need hard stops in your color map to prevent interpolation between
entries, and then you could simply render a smooth gradient across a wide image
format (1920 x 1080).

- BW

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/19/25 05:28, Kenneth wrote:
> >
> > for all of my usual .png renders in 3.8 beta 1,
> > Ive's IC app reports them as having the correct sRGB embedded gamma.
>
> When I use the command:
>
>    p380b2 material_map_tester_kw.pov file_gamma=srgb
>
> [The srgb block is] not there by
> default and should be (and for a LONG while it was. It should be there
> in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.
>

Ah, I see what you mean now. Yes, if I leave out an explicit File_Gamma=srgb
when running a render in 3.8 beta 1, Ive's IC reports the image as having a
'vanilla' 2.2 gamma instead, when it should be srgb 'by default'.


> You can 'see' whether the srgb block exists in any png file by looking
> at the first 100 bytes or so in an editor or by using a command to write
> those initial bytes to the screen of a terminal window.
>
Sorry to say that I don't have an appropriate editor to check that in Windows
(unless there is some trick that I don't know of!)
>
> On the interpolation noise bug, I ran your scene with 'interpolation 3'
> and I do see it with my v3.8 beta 2 compile (top). See attached image -
> the current yuqk result on the bottom.

Yes, I see a bit of speckling even with interpolate 2, and far worse noise (like
your example) with interpolate 3 and 4.
>
>
> With the traditional material_map implementation, if you have in the
> index control image (MMT.png), indexes larger than the length of the
> texture list it gets wrapped back onto the list with a sort of
> 'mod(index,txtr_list_length)'.
>
> I thought this approach confusing. Now in yuqk, the map overruns are set
> to the index zero texture.
>
> I think it makes sense to map out of bounds
> indexes to the zero index in the same way.
>
Yes, that sounds like a more logical way of doing it, and more understandable as
to the visual result. (The documentation about "taking modulo N" is not very
easy to mentally visualize, ha.)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 1/19/25 05:28, Kenneth wrote:
> > >
> > > for all of my usual .png renders in 3.8 beta 1,
> > > Ive's IC app reports them as having the correct sRGB embedded gamma.
> >
> > When I use the command:
> >
> >    p380b2 material_map_tester_kw.pov file_gamma=srgb
> >
> > [The srgb block is] not there by
> > default and should be (and for a LONG while it was. It should be there
> > in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.
> >
>
> Ah, I see what you mean now. Yes, if I leave out an explicit File_Gamma=srgb
> when running a render in 3.8 beta 1, Ive's IC reports the image as having a
> 'vanilla' 2.2 gamma instead, when it should be srgb 'by default'.
>

My apologies, Willaim: I mis-quoted your reply, which probably made my own reply
a bit confusing. It should have been the following:

[Kenneth:]
for all of my usual .png renders in 3.8 beta 1,
Ive's IC app reports them as having the correct sRGB embedded gamma.
   {because I use an explicit File_Gamma=srgb]

[William:]
When I use the command:

        p380b2 material_map_tester_kw.pov file_gamma=srgb

I get an output file size of 6638 - because the srgb block has been
added with the latter command (13 bytes larger). It's not there by
default and should be (and for a LONG while it was. It should be there
in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.

[Kenneth:]
Ah, I see what you mean now. Yes, if I leave out an explicit File_Gamma=srgb
when running a render in 3.8 beta 1, Ive's IC reports the image as having a
'vanilla' 2.2 gamma instead, when it should be sRGB 'by default'.

-----
When running 'official' v3.7.0 instead, the 'default' File_Gamma is indeed sRGB,
as you mentioned.

Post a reply to this message