I'm still suspicious about the logic you're using here: > On Jan 2, 2019, at 1:32 PM, Renaud Talon <[email protected]> wrote: > > # Set input colorspace to linear if converting EXR file > if sourcePath.split('.')[-1] == 'exr': > srcColSpace = spec.get_string_attribute('oiio:ColorSpace', 'linear') > ImageBufAlgo.colorconvert(resizedBuf, resizedBuf, srcColSpace, 'sRGB')
I think that the reason this works for you is that you are presuming in this case that the TIFF input is already in sRGB, and since it's not exr it isn't doing any transform at all, and since you are outputting to JPEG it just coincidentally turns out that the untransformed values are already in sRGB. But that seems very brittle to me, and wrong in the general case. Examples: What if the input TIFF is linear? (Wrong -- it will fail to write sRGB to the jpeg file.) What if the output is exr too, so you are doing exr->resize->exr? (Wrong -- it will incorrectly write sRGB to the output exr file.) Ideally, the logic you want is this: 1. If the input file is nonlinear, transform it into a linear space. (Aside: depending on the format you're reading from and your studio conventions, it may be hard to determine this.) 2. Do all the math, such as the resize, in linear space. (Actually, your resample() is fine because it only copies without filtering, but if you ever want a higher quality resize(), it will be subtly wrong if not done in a linear space.) 3. For output, if you are writing to a file format that requires a different color space (e.g. JPEG requires sRGB) or for some other reason you want to store in a nonlinear space, then transform from linear to that desired space right before output. Note that exr is usually linear, because with 'half' or 'float' pixels, there's no good reason to encode pixel values with the sRGB nonlinear transfer function. The whole point of sRGB nonlinearity is to use the limited encoding precision of 8 bits in a more perceptibly uniform way. It's a compromise that is no longer helpful once you have 16 bit values. -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
