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'