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)