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