karu wrote: When displaying an image in the render viewport, Octane always produces the image in sRGB first.
this may not be the best, but reasonable, As a matter of fact when you setup a new color space for rendering colors, take the sRGB as the base reference is the right choice, anyway the most number of the displays are in the sRGB mode(sure precision will be depends on the difference of the manufacturers)
karu wrote: In versions prior to 2020.1, it displays that sRGB image directly
take the sRGB as the your color space founding base and then display the sRGB image directly, to say this you are trying to imply the image on the screen is still a "sRGB image", but this is WRONG:
To display sRGB image directly, means through windows display drivers, that actually means just to scale the color space of original image (sRGB) to screen color space (let us say aRGB), this action is same as to display an untaged image(from sRGb) on a aRGB display, which situation has explained in my previous post.
The matter of fact is when it is on the display, it is already in aRGB(screen) color space, no matter it is originally from sRGB or whatever:
when the original color in sRGB put onto a wide gamut display,it is not like what you think, that it will keep in the sRGB space, Microsoft windows is not doing it this way, they just simply put the color directly to screen color space,means a clolor (1,0,0)in sRGB from your original image will be put directly to aRGB space as (1,0,0) without any transform, means the color apearance is actually changed(with value not change),the both(1,0,0)are different red.
actually to achieve as what you say if you want to keep the sRGB red color(1,0,0) displayed on a aRGB moniter you actually need to send a color value which is like (0.9xxx,0,0) to the screen then you can kepp the color appearance same(the real number should be depend on what exact the screen color space is).
you can verify this with your engineeers who really know display driver and test if what I am saying is correct.
as mentioned before, only color managed image will keep the original color appearance,(need tag icc) windows driver do not do this. Remember? I mentioned MS is not keen for wide gamut.
beside your original sRGB source image, there is other factors, that is, we the user will adjust the effect,there is back and forth (e.g. change the lights or using the camera imager etc) base on what is displayed on the screen, means the final satisfacted image is base on the screen effect which is actually in the aRGB space, as said no matter what is this aRGB image originally come from.
karu wrote: (bad luck if your monitor isn't sRGB)
this statement maybe true if it refers to your luck, because you might not be able to tell mine, actually, I am in a good lucky and the monitor is excellent.
karu wrote: In 2020.1 and later it uses the current display profile to convert the sRGB image to the display's color space, and displays that.
see the above explanation you may aware that this is actually doing nothing more than before versions, because this is exactly the same as the previous, you have repeated what the display driver has done, if you understand how Microsoft display driver works.
if you are spending a lot of resource to do this, it is really a bad luck for Otoy.
karu wrote:You will never actually see colors outside the sRGB gamut in the render viewport if your display profile is configured correctly.
false, explained already, you may have misunderstandings on how the windows color management system work.
karu wrote:This is clearly not ideal, but it's how it has always worked.
said understandable.
karu wrote:Display color management is only used when displaying an image in the render viewport; it has no effect when exporting images
I hope you finally understand this is not right, this only makes octane render not a color management supported.
karu wrote:Octane always exports PNG files as sRGB (unless you choose an OCIO color space), and doesn't tag any exported images with ICC profiles or any other color space data.
I knew. this is no problem with sRGB workflow, and as mentioned in the above post, for most people, it is right, but may not be ideal in terms of color management.
karu wrote:Regarding your examples of the behavior before and after 2020.1:
- Pre-2020.1: Manually tagging a PNG exported from Octane with your monitor's ICC profile is incorrect,
disagree. as mentioned in the explanations in the very begin a few lines in this post, the final satisfied image on the screen, is in the screen color space,
and as mention the right way of color management for image files are to tag the right color space profile to it, so obviously this is the reason why I tag the screen's color space icc to the image.
*one tecnique detail need to be clarified here, in some situation a montior's icc may not good ro represent so called "screen color space" because different manafacturer may have different ways to do their icc,some moniter's icc maybe not use for this purpose,in this case the ""screen color space profile" can just mean aRGB.icc, if the monitor of this kind of icc maker is a aRGB compatable (usually they will anounce as 9x% aRGB)
forunately mine is not this kind, and also the monitor and the icc is still healthy, so there is no problem for me to the monitor 's icc profile directly.
but this is very technical details which does not impact main discussions.
karu wrote:since Octane always exports PNGs in sRGB.
false, it is untagged, doesn't mean it is belong to sRGB, as mentioned we are working on the aRGB, when we change the caremera imager, it is already actually in the screen color space,
Please note when we are doing the rendering it is not only the software is working, we the people is acting base on the screen feedback. so the final satisfied image is actually an aRGB image, it is not all from your original sRGB.
karu wrote:Tagging it with your monitor's profile just had the effect of making Photoshop's display color management be a no-op (because the image profile was the same as the display profile)
false, before and after tagging icc makes a lot of difference, no-op is obiously wrong guessing.
karu wrote:Effectively, the image looked the same in both applications, because it was wrong in both applications.
disagree.the goal of color management is to keep the image same looking, if we susessfully achieve this, and fully achieved means all CM(color management) supported applications act consistancy, this means the configurations for the system working properly. If you call this wrong, and all the CM supported apps are wrong, I am curious about what is your correct is.
karu wrote:There are many things that can be improved here, such as allowing the render viewport to actually utilize the wide gamut of a wide gamut display (without OCIO), supporting >8 bits per pixel for display in the render viewport, tagging exported images with color space information,
all sounds great, but be careful before you really make sure your color management understandings are in the right track, all these proposals might be risky.
since color space is such a fundamentle things,I would say Otoy please pay more attention on this, probably have a few truely aRGB monitors in your office,get them proper configured, then, you will agree with what I am talking about.