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