OH, I get it. --colorconvert in out means "Convert the source image from `in` to `out` before turning it into a MIP-map."
It does NOT mean "convert the source from `in` to linear, and then when writing the MIPmap convert it to `out`." So your source texture, the checkerboard, has values 0.0 and 1.0 only, and when you convert those from linear to "sRGB", they are still 0.0 and 1.0, respectively, so the rest proceeds apace, and your 1x1 fully filtered layer ends up pretty darned close to 0.5. It assumes that you write a linear file. Maybe because the texture system assumes all its input is linear. Using linear math for the downsizing when creating the MIPmap is not enough. ALL the math inside the texture system for blending between pixels (the filtering of the individual texture lookups) is also linear, and will be wrong if the map is sRGB. You could make an argument, I suppose, that this is all not as flexible as you'd want, and that you want to store nonlinear textures. You'd need a number of changes: (1) a way to instruct maketx to do a second color conversion upon output to the color space of your choice (i.e. truly save sRGB). (2) to have an option in the texture system to color convert BACK to a linear space upon reading tiles, so that the filtering math will be correct, because it's not correct to convert sRGB->linear in the shader itself after the filter math is done, the conversion has to be upstream of the filter math. (3) to figure out how you're going to be able to tell, for a TIFF texture, whether it's intended to be linear or in some other color space, because TIFF doesn't directly say this anywhere. (Maybe you could rely on the file naming convention, like maybe you seem to with checker_uint8_sRGB.tx?) (4) If you have a uint8 sRGB texture on disk, and you want to be converting to linear as the tiles are read into the texture cache... ugh, you don't want those tiles to be uint8 or you'll lose a lot of precision in the darks. So in addition to converting sRGB to linear, you also want to convert from uint8 to, I dunno, maybe uint16 or half for storage in the cache? Which also makes it consume twice as much cache space? (By the way, `info -a -stats foo.tx` is also your friend for inspecting value ranges.) > On Jan 10, 2021, at 4:09 PM, Larry Gritz <l...@larrygritz.com> wrote: > > That's right, the FLOAT here just means "give me the values as floats", and > it does not imply any color space conversion. > > So, the question is why the --colorconvert linear sRGB doesn't end up with a > 1x1 miplevel that's farther from 0.5. I also would have the same expectation > as you. > > Let me look a bit through the code... > > >> On Jan 10, 2021, at 3:41 PM, Søren Ragsdale <sor...@gmail.com >> <mailto:sor...@gmail.com>> wrote: >> >> I assumed oiio.FLOAT describes the data type and that script wouldn't know >> whether the texture it was reading was UINT8 linear, gamma22, or sRGB. >> >> That assumption seems to be correct. I changed the script to UINT8 and I'm >> still getting basically the same result. Black is 0 and white is 255 but 50% >> gray should be higher than 128 due to the nonlinear sRGB LUT: >> >> $ python ~/scripts-dev/miplevels.py checker_uint8_sRGB.tx >> 0 512x512=262144 min=0 med=255 max=255 >> 1 256x256=65536 min=0 med=255 max=255 >> 2 128x128=16384 min=0 med=255 max=255 >> 3 64x64=4096 min=0 med=255 max=255 >> 4 32x32=1024 min=127 med=127 max=155 >> 5 16x16=256 min=127 med=127 max=142 >> 6 8x8=64 min=127 med=127 max=135 >> 7 4x4=16 min=127 med=129 max=131 >> 8 2x2=4 min=128 med=129 max=129 >> 9 1x1=1 min=129 med=129 max=129 >> >> As a sanity check I made a uniform 50% grey texture and the values are at >> 188, consistent with sRGB 50% grey: >> >> $ iinfo --stats grey_float32_lin.tif >> grey_float32_lin.tif : 512 x 512, 3 channel, float tiff >> Stats Min: 0.500000 0.500000 0.500000 (float) >> Stats Max: 0.500000 0.500000 0.500000 (float) >> Stats Avg: 0.500000 0.500000 0.500000 (float) >> Stats StdDev: 0.000000 0.000000 0.000000 (float) >> Stats NanCount: 0 0 0 >> Stats InfCount: 0 0 0 >> Stats FiniteCount: 262144 262144 262144 >> Constant: Yes >> Constant Color: 0.500000 0.500000 0.500000 (float) >> Monochrome: Yes >> >> $ maketx --oiio -d uint8 --unpremult --colorconvert linear sRGB >> grey_float32_lin.tif -o grey_uint8_sRGB.tx >> >> $ python ~/scripts-dev/miplevels.py grey_uint8_sRGB.tx >> 0 512x512=262144 min=188 med=188 max=188 >> 1 256x256=65536 min=188 med=188 max=188 >> 2 128x128=16384 min=188 med=188 max=188 >> 3 64x64=4096 min=188 med=188 max=188 >> 4 32x32=1024 min=188 med=188 max=188 >> 5 16x16=256 min=188 med=188 max=188 >> 6 8x8=64 min=188 med=188 max=188 >> 7 4x4=16 min=188 med=188 max=188 >> 8 2x2=4 min=188 med=188 max=188 >> 9 1x1=1 min=188 med=188 max=188 >> >> On Sun, 10 Jan 2021 at 18:48, Solomon Boulos <bou...@cs.stanford.edu >> <mailto:bou...@cs.stanford.edu>> wrote: >> Doesn’t get as float convert from sRGB to Linear in your miplevels.py? If >> you don’t want conversion, open it as int8. >> >> On Sun, Jan 10, 2021 at 10:39 Søren Ragsdale <sor...@gmail.com >> <mailto:sor...@gmail.com>> wrote: >> I have "checker_float32_lin.tif", a simple RGBA black and white >> checkerboard. Each black or white square is 8 pixels wide, and every pixel >> value is either 0.0 or 1.0. >> >> I'm using OIIO to turn this float32 scene-linear TIFF into a uint8 sRGB >> albedo texture: >> >> maketx --oiio -d uint8 --unpremult --colorconvert linear sRGB >> checker_float32_lin.tif -o checker_uint8_sRGB.tx >> >> I've written miplevels.py (see attached) which prints the min, median, and >> max values of the first color channel for each mipmap level of the texture. >> Here's the output: >> >> $ python ~/scripts-dev/miplevels.py checker_uint8_sRGB.tx >> 0 512x512=262144 min=0.0 med=1.0 max=1.0 >> 1 256x256=65536 min=0.0 med=1.0 max=1.0 >> 2 128x128=16384 min=0.0 med=1.0 max=1.0 >> 3 64x64=4096 min=0.0 med=1.0 max=1.0 >> 4 32x32=1024 min=0.498039245605 med=0.498039245605 max=0.607843160629 >> 5 16x16=256 min=0.498039245605 med=0.498039245605 max=0.556862771511 >> 6 8x8=64 min=0.498039245605 med=0.498039245605 max=0.529411792755 >> 7 4x4=16 min=0.498039245605 med=0.505882382393 max=0.51372551918 >> 8 2x2=4 min=0.501960813999 med=0.505882382393 max=0.505882382393 >> 9 1x1=1 min=0.505882382393 med=0.505882382393 max=0.505882382393 >> >> As the mipmaps decrease in size the median value converges on 0.5. Except >> this is a sRGB texture. The value for 50% grey should be around 0.737 in >> sRGB space. >> >> It appears maketx is converting the values from linear to sRGB then scaling >> to create the mipmaps. When the source and destination color space are >> specified I think maketx should scale in scene linear color space, then >> convert to sRGB before saving each mipmap. >> >> Is this a bug? Is there a flag or workaround that I should know about? >> >> https://paroj.github.io/gltut/Texturing/Tut16%20Mipmaps%20and%20Linearity.html >> >> <https://paroj.github.io/gltut/Texturing/Tut16%20Mipmaps%20and%20Linearity.html> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> <miplevels.py>_______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > l...@larrygritz.com <mailto:l...@larrygritz.com> > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
