OctaneRender™ 2020.2 (XB1) is out! + 2021 roadmap updates! Tweet

[jimho]

Since programers and users are living in the different world, it might be good to make it clear again,
From Karu's comment,
statement 1

You can simply use the non-tone-mapped option .... This should display as expected in any application that displays EXR files.

statement 2

Note that this will not include any of the tone mapping transformations from the camera imager node (e.g. response curve/gamma/custom LUT) because those are part of a display transformation, which is not relevant to the scene-linear image data stored in EXR files.

the statement 2 is true, then the conclusion of "display as expected " in the statement 1 is false,obviously (per our users' point of view)
to clarify what we want here:
1, the camera imager node provides flexibility for the appearance of the rendering result (in octane viewport) which is great, we would like these transitions also appear in the post production applications(I believe to most of us, it means photoshop for still image)
2,the png export is perfect showing the transitions, but we need to put all the passes together one by one MANUALLY,
3,the EXR is perfect to have all the passes, but what it is now,
3.1 either not reflecting any of the camera imager's transition(the linear option,need to apply the transition MANUALLY),
3.2 Or not the correctly translated (the tonemapping option,need to correct it MANUALLY)
4,What we are asking is: can we integrate item 2 and 3: have the right tone(like the png)and all the passes (like the EXR),we donot care what it calls EXR PSD TIFF,or un-official, biased EXR what ever.

I think this is a important thing for this software of octane, not only refers to this specific issue,
You see because of the item 3, there is a lot of things users need to deal manually which means need user to be enough skillful, otherwise they do not get the right result,
for example If it is not pointed out the key of the solution is the Gamma and the number is 0.45454, many people may try other parameters like "brightness" "curve""contrast" etc, there is many others,

Otoy, do you understand why there is so much fraustrations from users?
I say it is not only this specific issue, there is still many others, you are just doing half of your job and leave the other half to users,
And this, make a lot of fraustration.

Otoy, can you pay more attention to the better user experience...
Thank you

[karl]

if for any reason you do not want to change the current sRGB tonemapped EXR,
Can you add a new EXR option which can have the RIGHT appearance in photoshop, just simply integrated the 0.4545 into the current version of sRGB tonemapped EXR?
OCIO is far more complicated than what I am suggesting here, for such a simple purpose, it is not worthy

Is there a reason you don't export as a 16-bit PNG? If you're trying to display an EXR file you will always be fighting against whatever transformation the other application is doing to convert the linear light representation into one suitable for display. In Photoshop it appears that it's approximately a 2.2 gamma function (it's probably the sRGB transfer function, but the difference between those is hard to notice). In some other application it may be something more sophisticated (e.g. it might include proper tone mapping). If you want to bypass the display transformation that the other application is doing, it makes more sense to provide that application with an image that's already baked into a display color space rather than trying to anticipate the exact display transformation it will use and cancel it out in a scene-linear image that isn't really scene-linear.

It seems that what you're asking for is an option that exports an EXR file including the artistic look aspects of the tone mapping that Octane does, without the actual conversion to a display color space. Unfortunately there is no clear distinction between those two parts of the transformation in the current implementation; we can't do one without the other (I have been planning to split these parts, but it will take some time as it requires reformulating the transformations from a more scientific perspective, and would likely not match the existing behavior pixel for pixel). The best we could do for now would be to do the full tone mapping transformation, and then unapply the sRGB transfer function. This matches your suggestion. However, the problem is that the resulting image would still not be a standard scene-linear EXR file, because of any non-reversible clipping/desaturating etc. that had been done to bring the numbers into the 0-1 sRGB range.

If there's a specific reason why you need to use EXR for this, I would like to understand what it is, to try to work out the best solution for this use case and other use cases. Otherwise, I recommend exporting a 16-bit PNG file.

[karl]

Since programers and users are living in the different world, it might be good to make it clear again,
From Karu's comment,
statement 1

You can simply use the non-tone-mapped option .... This should display as expected in any application that displays EXR files.

statement 2

Note that this will not include any of the tone mapping transformations from the camera imager node (e.g. response curve/gamma/custom LUT) because those are part of a display transformation, which is not relevant to the scene-linear image data stored in EXR files.

the statement 2 is true, then the conclusion of "display as expected " in the statement 1 is false,obviously (per our users' point of view)
to clarify what we want here:
1, the camera imager node provides flexibility for the appearance of the rendering result (in octane viewport) which is great, we would like these transitions also appear in the post production applications(I believe to most of us, it means photoshop for still image)
2,the png export is perfect showing the transitions, but we need to put all the passes together one by one MANUALLY,
3,the EXR is perfect to have all the passes, but what it is now,
3.1 either not reflecting any of the camera imager's transition(the linear option,need to apply the transition MANUALLY),
3.2 Or not the correctly translated (the tonemapping option,need to correct it MANUALLY)
4,What we are asking is: can we integrate item 2 and 3: have the right tone(like the png)and all the passes (like the EXR),we donot care what it calls EXR PSD TIFF,or un-official, biased EXR what ever.

I think this is a important thing for this software of octane, not only refers to this specific issue,
You see because of the item 3, there is a lot of things users need to deal manually which means need user to be enough skillful, otherwise they do not get the right result,
for example If it is not pointed out the key of the solution is the Gamma and the number is 0.45454, many people may try other parameters like "brightness" "curve""contrast" etc, there is many others,

Otoy, do you understand why there is so much fraustrations from users?
I say it is not only this specific issue, there is still many others, you are just doing half of your job and leave the other half to users,
And this, make a lot of fraustration.

Otoy, can you pay more attention to the better user experience...
Thank you

Thank you for the explanation, I now understand exactly what you want and why you want it. (I typed the previous post before seeing this).

This underscores the importance of splitting the artistic look aspects of the tone mapping transformation from the display color space transformation. Funk was also asking for this earlier, in the context of OCIO.

I think, for now, we can add a new option that does what I described in my previous post, with the drawbacks I described in my previous post. It would need to be made clear that this option is still not a "proper" EXR export because it isn't scene-referred, wouldn't be appropriate for wide-gamut/HDR work, etc. I will think on exactly what this option would be called (and how it would work in the context of OCIO). I can't promise anything, but I think this will be ready in a future 2020.2 XB release (hopefully XB2).

[karl]

Hi karu,

Is there a 100% correct way to set the Order? (see attached ss)

I`ve got a response curve applied as well as a LUT and would like to save out an .EXR. I often find myself adjusting the EXR in PS a bit as it comes out a bit too bright when exported as Tonemapped .EXR.

It sounds like the brightness issue you're having is the same as jimho and funk - fundamentally the problem is that Photoshop doesn't know what "tone mapped EXR" is. The plan is to provide an option for EXR export that is not tone mapped but has the same color transformations that the tone mapped option does (with some drawbacks).

There isn't one definitively correct way to set the order - it really depends on what you want, which is why all those options are provided. Those three curves, together, take the image from a scene-linear light representation (in the linear sRGB color space) to a displayable image (in the sRGB color space). The simplest way to achieve that is to apply effectively no artistic look and just apply the sRGB transfer function - this is the default setup and would be considered the "science" part of the transform whereas everything else is the "art" part. So, slightly facetiously, I would say that the 100% correct settings are whatever makes the resulting image look 100% correct

That screenshot appears to be from an older version - in 2020.2 some things have been clarified in this area:

• The "Tonemap settings" section of a render target node has been renamed to "Imaging settings", because not everything in there related specifically to tone mapping.
• The settings on a camera imager node that specifically relate to tone mapping have been grouped together in a "Tone mapping" section.
• The different color space choices when exporting an image have been labeled with whether or not they include tone mapping.

[jimho]

it isn't scene-referred, wouldn't be appropriate for wide-gamut/HDR work, etc.

Regard to the wide gamut color space, I would like to share some of my options,I think it might be helpful to introduce some background knowledge of color management here. A clear image of color management may let you understand how to treat it in the software.

I am actually not working in sRGB color space, the display I am working on is happened to be named as "Eizo color edge CG275W" which provides a color space pretty close to Adobe RGB which is wider than the standard sRGB clolor space and is exactly what you mentioned wide gamut.

Color management is actually quite a big topic, I've seen some people ,at photagrapher's forums, arguing on this thing for years. So here, I just want to highlight some conclusions.

We all know that displayed and printed colors are different,they follow different laws, so their gamuts are different. Photagraphers want their pictures printed looking as closer as possible to what it appeares on their screens, this is the begining that color management introduced,

Microsoft (and others) set the display standard color space as sRGB, though printed color gamut is wider than it. Photagraphers prefer Adobe RGB which is wider and could cover the printed color gamut better,and fortunatly a few display manufacturer can provide the similar color gamut on their screen, this is where the wide gamut coming from.

A proper color management setup is a bit complicated since hardware (like display, printer, scanner etc), OS and software applications and working procedures are all involved, I cannot explain all the details here,but I can say the result of the proper color management, that is: an image will be looking all the same in the different viewer or edit applications(if they are color management supported).

Actually not everyone need to do color management,because Microsoft did a basic one for most of the people, that is sRGB as mentioned above,all windows system is by default using sRGB,if you are not using a wide gamut display(which can be ten times in price compared with normal sRGB display), you do not need color management at all.Since not all the people require it, probably this is the reason why this color management issue comming out so late (for octane).

But if you want your image printed pricisely, and very expensive wide gamut display be proper utilized, the color management is a must ( will explain later), as mentioned this will involve hardware, OS and software applications (if they supported) and relative procdures.

A software supporting color management means they can correctly recognize an image which is tagged a proper color space icc profile.

I can name some of the softwares that supporting color managment,they are: PHOTOSHOP, Lightroom, Google Chrome, Firefox, Windows Photo Viewer( not Photos in windows 10, MS is not a fans of Adobe RGB and not keen on wide gamut),
How to tag an icc to an untagged image? The answer is in PHOTOSHOP,this is actually the very key procedure for an image with color managing: to tag the color space in which the image is belonging to(e.g. sRGB.icc)

an Untagged image is actually in the screen's color space, since the most windows system and displays are by default sRGB, in most cases they will be recognized as sRGB image (especially in softwares from Microsoft)
but this will be not true if you are using a wide gamut display, they may not in the sRGB mode but might be much wider,and this is what they born for, in this case the untagged image may look much higher saturation, and this is very typical mistake that people start using wide gamut display while without proper color management.

If a system is not proper configured, images will appears to be different in different applications and windows viewers, in this case the looking of the image in the PHOTOSHOP is the real looking for it(which might not be the best looking one).
if the hardware of display is proper color managed, you will get a color profile for the display( the icc file specifically for your display),this file need to be put into somewhere in windows display setup to let the OS know your screen is a wide gamut screen, thus proper configured.

through the above words,we find out:

1, for a fully sRGB user, color management may not be a critical issue,if they are always working in the sRGB color space, most of them may even not need it, (also they may even don't know what we are talking about here, because images that looking completely different on a wide gamut display will looking exactly the same on their sRGB display....)

2, color management related to the wide gamut color space(e.g.adobe RGB), or say most of the color management requirement is from the wide gamut display user.

There are 2 type of users who are using a render engine, 1, people who is doing animation, 2, people who work on the still image:

• Animations need to be displayed on screens,probably for TV screens, the color space for this purpose(TV broadcasting) is REC709 which gamut is close to sRGB, I guess this type of people will also be interested in color management. but to them REC709 might be better preffered in stead of sRGB.Maybe this type of people are jsut those that Karu mentioned as "more sophisticated requirements" , I guess.because the post edit sofware they use may be different from adobe's, but still adobe have their post production software, in which the situation maybe similar to photoshop as below I will mention, so even the animation makers, there is still quite amount will have the problem I named.

• People who is doing still images, their requirement is similar to photagraphers their image may finally need to be printed, as highlighted quite many times PHOTOSHOP for them is a key application,
  So please let your EXR appearence be proper in it, PLEASE.

and FYI, here to say, what I am treating with octane render's image, and, which seems quite successful in terms of color management.

As mentioned, regard to an untagged image, it is in the screen's color space, I repeat this statement, because it is exactly the situation that happens in the octane render's rendering viewport.

So for previous version of Octane, what I am doing for the exported PNG (and EXR) is:
I will tag my screens icc to it MANUALLY, when load into photoshop. After the tagging of icc, in the photoshop's viewport it looks exactly the same as it appears in the octane's viewport.
And I am happy to see from the version of 2020.1, we can describe the display's color space in the preference,and the exported png is no need to tag manually, this is good improvement.

regard to the EXRs, when loading into photoshop, photoshop will ask what color space should be applied, I think this is reasonable, because EXR(as Karu always highlighted, the pure, or say the linear one) is in a kind of raw file format(similar like photograph's raw format).

Finally what I am trying to say here, I write so many words above, just want you to understand:

1,if the screen color space is described in the octane's preference,your tonemap to the PNG should be following that one,the screen icc, it may not be sRGB, in my case it is following screen color space which is actually very close to adobe RGB.

2,I hope Octane render can be considered as color managment supported software in future, means, it can generate image with proper icc tagged, whatever the format it calls(psd, tiff and others can all have layers and icc description).Color management is a sophisticated way to treat images, it do not actually change the image (it will not mapping the image directly, so could still keep the image linear ) but just get the image properly tagged with the icc profile, and let the color management supported edit softwares translating this tag together with the original image, so the mapping happens in this stage (i.e. in photoshop).

3,as mentioned in the pervious post, and also according to the key idea of color management, the looking of the images should be consistance when they are opened in different apps, and with layers for the passes.

Apologize for the long post.
Though still, if there is someone who have no idea of color management, yet just happend bought a wide gamut display, may find this post useful for them either.

[karl]

So for previous version of Octane, what I am doing for the exported PNG is:
I will tag my screens icc to it MANUALLY, when it is load into photoshop.After the tagging, in the photoshop's viewport it looks exactly the same as it appears in the octane's viewport.
And I am happy to see from the version of 2020.1, we can describe the display's color space in the preference,and the exported png is no need to tag manually, this is good improvement.

There's a lot to respond to here, but I just want to clarify some details of display color management in Octane.

When displaying an image in the render viewport, Octane always produces the image in sRGB first. In versions prior to 2020.1, it displays that sRGB image directly (bad luck if your monitor isn't sRGB). 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. You will never actually see colors outside the sRGB gamut in the render viewport if your display profile is configured correctly. This is clearly not ideal, but it's how it has always worked.

Display color management is only used when displaying an image in the render viewport; it has no effect when exporting images (it's display color management after all, and the idea is that users with different monitor setups should be able to load the same scene and produce identical exported images). 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. The behavior you were seeing with PNGs in Photoshop is consistent with Photoshop treating all untagged PNG images as sRGB, which I believe is what it does.

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, since Octane always exports PNGs in sRGB. 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), so it matched what Octane was doing when it displayed the sRGB image (which was also a no-op, because there was no display color management before 2020.1). Effectively, the image looked the same in both applications, because it was wrong in both applications.
• 2020.1+: The reason why you don't need to manually tag anything to get the display to match between Octane and Photoshop isn't because Octane is tagging the image for you. It's because the display transformation that Octane is doing to display the sRGB image matches the display transformation that Photoshop is doing to display the sRGB image, because both are configured with the same display profile. The image looks correct in both applications (and different to how it looked in the previous example), but is only able to utilize the sRGB portion of your display's wide gamut.

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, allowing exporting of non-sRGB PNGs (without OCIO)... but this is how things work today.

[jimho]

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)

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.

(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.

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.

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.

This is clearly not ideal, but it's how it has always worked.

said understandable.

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.

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.

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.

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.

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.

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.

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.

[jimho]

https://www.exr-io.com/features/

exr_icc.JPG

It shows EXR support icc with no problem

[mojave]

Hi all,

A new OctaneRender 2020.2 XB2 version is now available which has superseded this build.

[nibbler]

Great work:

Is it now possible to Connect Octane X Metal (XB1) Masters with Octane Win/MAC Cuda 2020.2 (XB1) Clients as RenderSlaves?
If not, will it be integrated in Octane 2020 XB2?

THX for feedback.