OctaneRender™ 2020.2 XB2

Forums: OctaneRender™ 2020.2 XB2
A forum where development builds are posted for testing by the community.
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby jimho » Thu Sep 24, 2020 4:45 am

jimho Thu Sep 24, 2020 4:45 am
here I demostate how we manually turn an Octane exported ACES to a looking more close to the original viewport
https://render.otoy.com/forum/viewtopic.php?f=9&t=75843#p390014

Supermicro 4028GR TR2|Intel xeon E5 2697 V3| windows 10| revit 2019 |Titan V+ Quadro GV100+RTX 2080 Ti
jimho
Licensed Customer
Licensed Customer
 
Posts: 262
Joined: Tue Aug 21, 2018 10:58 am

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby jimho » Thu Sep 24, 2020 7:55 am

jimho Thu Sep 24, 2020 7:55 am
Thanks for responding,here are my feedbacks,

karu wrote:The change to add the ability to export a scene-linear EXR file including the tone mapping settings (and a few related changes) just didn't make it into XB2, but it will be in XB3. The option is called "Force tone mapping"; in this case you would use it in conjunction with the default color space for EXR export (linear sRGB).

OK, that's fine.
I don't mind if you call it "Jim Forced"EXR :mrgreen:

karu wrote:There appears to be a difference in saturation between the XB1 and XB2 screenshots. I guess this is a change in the scene? Nothing should have changed so let me know if it's the exact same scene.

I uploaded a wrong file for the XB2, which I forgot to tag an icc.the one for XB1 has colormanaged and this one did not, so they look different from your side, they should look same (in saturation), actualy from my side they do,
It's a typpo, and have re-uploaded
XB1-XB2.JPG


karu wrote:The EXR ToneMap image is too bright due to Photoshop interpreting sRGB as linear sRGB (or equally, Octane passing sRGB off as linear sRGB on export), as we discussed before. XB3 fixes this by never saving a non-linear color space to an EXR file.

OK,
one minor comment on so called "sRGB Linear",my view is a linear color space is Gamma=1.0, and as we allknow sRGB color space is Gamma=2.2, it is a bit confuse what is a "sRGB linear" it should either be sRGB or Linear, it seems in XB2 there is actually no real linear, means gamma=1.0 export which is original pure EXR.
to have an pure Linear(as prior versions?) is still good,
for example in Davinci Resolve or photoshop camera Raw, the Raw image is actually the "Linear" image,
when we apply sRGB.icc to the Raw it is a sRGB image, when we apply aRGB.icc(means a aRGB curve times linear 1.0), it is an aRGB image.
the linear image is a start point for space transforming.
If you take the sRGB as the base point, I guess this is not the common way, probably this is also the reason that some of the export format is too bright, that an aRGB transform curve times a sRGB image(which should be the raw or linear 1.0)...

karu wrote:[*] The EXR Linear image is darker than the Octane Viewport due to using Photoshop's tone mapping instead of Octane's tone mapping. Neither one is objectively "right"; there are just many different methods of preparing a scene-linear image for display (this is something that OCIO can address, if used consistently across all applications).

If a Linear image is produced correctly it should be greyish, it is like raw file with no color profile.

I did some test on the ACES,yet I did not see the current OCIO or ACES have more advantage than adobe's resolution, per color management point of view,
https://render.otoy.com/forum/viewtopic.php?f=9&t=75843#p390014

My observation on OCIO, it is politically get more manufacturers involved, and it is more rely on re-mapping the images, on the other hand Adobe's icc and color profile solution is keeping the original image data unchanged,
and attached icc to define transform formular, which I think is a better free-lossless solution, though it seems much older.
as well, OCIO is not conflict with adobe's color management, OCIO is actually rely on icc for what it is good for.

Anyway, If you think OCIO works, could you provide some samples or tutorial on how to do this?

karu wrote:[*] The difference between the PNG Tonemap image and the Octane Viewport image is interesting, and not something I can reproduce myself. I would guess that it's due to different display color management between Octane and Photoshop. Are you using the same display color profile in both applications?[/list]

tonemaped PNG is the closest to the viewport, the difference is quite subtle, I guess on sRGB system it is unnoticeable, no offend, you might find the differenc on a real wide gamut display...
sRGB to viewport.JPG

BTW
I found different EXR plugins act differently:

1,one EXR recognize your file as RGB profile attched(though you called your file untagged,my view to tag an imge there are different ways, consumer way is to use icc, the programer may do it in a "built-in" way),
the EXR-IO plugin for photoshop call your file has a "RGB built-in" embeded which is exactly same effect as consumer's icc profile attached,
the EXR-IO's webpage listed herehttps://render.otoy.com/forum/viewtopic.php?f=9&t=75843#p389835
Capture.JPG


In this case your image might be considered as a color managed imaage but wrongly,unfortunately.

2, another EXR plugin (ProEXR) read you image as untagged,asking user to assign one when opening in photoshop
colorprofile.JPG

Supermicro 4028GR TR2|Intel xeon E5 2697 V3| windows 10| revit 2019 |Titan V+ Quadro GV100+RTX 2080 Ti
jimho
Licensed Customer
Licensed Customer
 
Posts: 262
Joined: Tue Aug 21, 2018 10:58 am

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby wallace » Fri Sep 25, 2020 12:25 am

wallace Fri Sep 25, 2020 12:25 am
funk wrote:Thanks team.

I submitted a bug in the previous thread:
viewtopic.php?p=389103#p389103

The scene renders now, but seems to be missing (or has very little) motion blur when compared to 2020.1.5

You can make this more obvious by changing animation settings > shutter time = 100%


Thank you for your several bug reports, we are investigating them and hopefully will have a fix for them in the coming version.
User avatar
wallace
OctaneRender Team
OctaneRender Team
 
Posts: 188
Joined: Sun Dec 18, 2016 10:38 pm

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby karl » Fri Sep 25, 2020 1:47 am

karl Fri Sep 25, 2020 1:47 am
jimho wrote:one minor comment on so called "sRGB Linear",my view is a linear color space is Gamma=1.0, and as we allknow sRGB color space is Gamma=2.2, it is a bit confuse what is a "sRGB linear" it should either be sRGB or Linear, it seems in XB2 there is actually no real linear, means gamma=1.0 export which is original pure EXR.


The color space that Octane calls "linear sRGB" has the same red, green and blue chromaticities as sRGB, and the same white point as sRGB, but uses a linear transfer function instead of the sRGB transfer function*. That is, linear sRGB is a linear version of sRGB. (Since the primary chromaticities and white point of sRGB are the same as those of Rec. 709, it would also be correct to refer to this color space as "linear Rec. 709", but we chose linear sRGB to clarify the relationship between it and sRGB). Some software just calls this color space "linear", which is very unhelpful because that name implies nothing about primary chromaticities or white point (e.g. ACES2065-1 is also linear).

* (The sRGB transfer function is closely approximated by gamma 2.2 but is actually a more complicated piecewise function.)

jimho wrote:
karu wrote:[*] The EXR Linear image is darker than the Octane Viewport due to using Photoshop's tone mapping instead of Octane's tone mapping. Neither one is objectively "right"; there are just many different methods of preparing a scene-linear image for display (this is something that OCIO can address, if used consistently across all applications).

If a Linear image is produced correctly it should be greyish, it is like raw file with no color profile.


My point was that there is no definitively correct way to display a scene-linear image. There are artistic decisions to be made regarding how to bring the brightness of the scene into the range of the display device, how to account for differences in white balance between the scene and the viewing environment (based on the extent to which the viewer will be adapted to the white of the display vs. the white of the surround), other psychological differences due to looking at a rectangular screen instead of being inside the scene... This PDF is a huge read, mainly about gamma, but very informative: https://poynton.ca/~poynton/notes/PU-PR-IS/index.html

jimho wrote:I did some test on the ACES,yet I did not see the current OCIO or ACES have more advantage than adobe's resolution, per color management point of view,
https://render.otoy.com/forum/viewtopic.php?f=9&t=75843#p390014

My observation on OCIO, it is politically get more manufacturers involved, and it is more rely on re-mapping the images, on the other hand Adobe's icc and color profile solution is keeping the original image data unchanged,
and attached icc to define transform formular, which I think is a better free-lossless solution, though it seems much older.
as well, OCIO is not conflict with adobe's color management, OCIO is actually rely on icc for what it is good for.

Anyway, If you think OCIO works, could you provide some samples or tutorial on how to do this?


OCIO is not really intended to solve the same problem that ICC profiles solve. It's a way to capture many aspects of a color-managed workflow (color space transformations, "look" transformations such as color grades, viewing transformations such as tone mapping) that may be shared between many people and many applications. It's easy to pick and choose which parts of an OCIO config to use in a given situation (e.g. by selecting a look to apply from a drop-down list), it's possible for humans to read, create and modify configs, and with consistent use between applications you can ensure the end-to-end results through an image pipeline are as expected.

In the OCIO use case I alluded to you would just make sure both applications are using the same OCIO view transform (which encapsulates all the artistic decisions I mentioned above about how to display a scene-linear image), and then you would know that both applications would display the image the same, rather than relying on any built-in scene->display transformation.

jimho wrote:
karu wrote:[*] The difference between the PNG Tonemap image and the Octane Viewport image is interesting, and not something I can reproduce myself. I would guess that it's due to different display color management between Octane and Photoshop. Are you using the same display color profile in both applications?[/list]

tonemaped PNG is the closest to the viewport, the difference is quite subtle, I guess on sRGB system it is unnoticeable, no offend, you might find the differenc on a real wide gamut display...


I think the issue here is that Photoshop (unlike most other applications) interprets untagged PNG files as being in whatever working space you have set, rather than sRGB. Since the vast majority of PNG files in the world are untagged, and the vast majority of those are in fact sRGB, this doesn't make any sense IMO - if you have a fancy working space set up, any random untagged PNG from the internet will just look wrong when opened in Photoshop. In any case, the fix is to either manually assign the sRGB profile to these images, or change your Photoshop working space to sRGB, or for Octane to embed an sRGB ICC profile in PNG files that it exports. Obviously the third approach is the best approach :) It's something I want to do for sure but it's unlikely it'll be in 2020.2 (the library that we use to save images doesn't support embedding ICC profiles so it's not a quick fix...).

To back up and reply to something from a previous post:
jimho wrote:when opening in photoshop, all the image is using octane's by default "builtin RGB profile" to import(see below snapshot),

Since Octane doesn't embed ICC profiles into EXR files (indeed, there is no standard way to do this), the message that you're seeing ("The document has an embedded color profile that does not match the current RGB working space") must be due to an EXR plugin you're using - I guess it's "embedding" that profile into the previously untagged image before presenting the image to Photoshop.
karl
OctaneRender Team
OctaneRender Team
 
Posts: 363
Joined: Sun Oct 13, 2019 11:26 pm

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby jimho » Fri Sep 25, 2020 10:19 am

jimho Fri Sep 25, 2020 10:19 am
karu wrote:The color space that Octane calls "linear sRGB" has the same red, green and blue chromaticities as sRGB, and the same white point as sRGB, but uses a linear transfer function instead of the sRGB transfer function*. That is, linear sRGB is a linear version of sRGB. (Since the primary chromaticities and white point of sRGB are the same as those of Rec. 709, it would also be correct to refer to this color space as "linear Rec. 709", but we chose linear sRGB to clarify the relationship between it and sRGB). Some software just calls this color space "linear", which is very unhelpful because that name implies nothing about primary chromaticities or white point (e.g. ACES2065-1 is also linear).

* (The sRGB transfer function is closely approximated by gamma 2.2 but is actually a more complicated piecewise function.)

Means you are doing a new standard color space actually, it is not sRGB anymore, means we can not tag sRGB.icc on it,
sRGB and aRGB are both standard color space, both are very successful,
the standard maker provide sRGB.icc and aRGB.icc, to attach the according color profile to any untaged image , we can restore the original image they are produced, and the Right color be expected,
to set up a new standard colorspace, you need to provide a color profile for it,which we can tag in photoshop, just like the sRGB.icc or aRGB.icc do.

I am still not very sure about this sRGB_Linear concept, can it be a real color space, does it theoryotically work, means do this icc exist, let us see could you provide this new color profile.
the real linear space works, the good examples are as mentioned before, all the raw formats for the differnt brand of cameras, they actually are in relative space, any workspace can be applied on it, that is what I understand a real linear one.

karu wrote:My point was that there is no definitively correct way to display a scene-linear image. There are artistic decisions to be made regarding how to bring the brightness of the scene into the range of the display device, how to account for differences in white balance between the scene and the viewing environment (based on the extent to which the viewer will be adapted to the white of the display vs. the white of the surround), other psychological differences due to looking at a rectangular screen instead of being inside the scene... This PDF is a huge read, mainly about gamma, but very informative: https://poynton.ca/~poynton/notes/PU-PR-IS/index.html

It is true that there is many way to treat and deal with color, But for color management, right or wrong it is clear, consistancy is a proper CM,otherwise it is not.

karu wrote:I think the issue here is that Photoshop (unlike most other applications) interprets untagged PNG files as being in whatever working space you have set, rather than sRGB. Since the vast majority of PNG files in the world are untagged, and the vast majority of those are in fact sRGB,

To assume anything untagged as sRGB, is base on the matter of fact that most display on the internet cannot all be professional displays, so they are sRGB, and which is Microsoft's standard.
Photoshop's nature is professional image editor, it need to deal all the color space that exist and operable.
So this is definately not photoshop's fault.

photoshop-color profile(icc) work flow is a standard solution for color management,which is verified very succussful in the past at least 15 years or much more(aRGB is from1998),

karu wrote: if you have a fancy working space set up, any random untagged PNG from the internet will just look wrong when opened in Photoshop.

That is definately not the point,to show you something here,regard to the PNG which is only one (not so called linear),means it should save the viewport looking:

Png_TM_argb_XB2_sRGB_g22_LUT_viewport_restart.jpg

Png_TM_argb_XB2_g22Rc_g22_LUT_viewport_restart.jpg

the above twocomparison, the png are both tagged the screen's color profile, which meet the viewport best,
there are slightly different when change the response curve from sRGB to gamma2.2, that is why I made each of them,and they are all accordingly, Left: PNG exported from the viewport at right(which respond curve has been changed),

the below comparison: PNG are as you instructed tagged sRGB.icc, the result looks differnt to the viewport where the image exported from
Png_TM_srgb_XB2_sRGB_g22_LUT_viewport_restart.jpg

Png_TM_srgb_XB2_g22Rc_g22_LUT_viewport_restart.jpg.png


These result has been described a few times in the early different posts, here just provide evidence, as mentioned if you are using a pure sRGB system, you can see the difference from your web browser(because I did CM on it),
but you cannot reproduce this.

Supermicro 4028GR TR2|Intel xeon E5 2697 V3| windows 10| revit 2019 |Titan V+ Quadro GV100+RTX 2080 Ti
jimho
Licensed Customer
Licensed Customer
 
Posts: 262
Joined: Tue Aug 21, 2018 10:58 am

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby jimho » Fri Sep 25, 2020 6:25 pm

jimho Fri Sep 25, 2020 6:25 pm
After reading the below 2 articles
http://www.aoktar.com/octane/OCTANE%20HELP%20MANUAL.html?LINEARWORKFLOW.html
https://poynton.ca/~poynton/notes/PU-PR-IS/index.html

I think there is misunderstanding of my request,I am not against of so called "Linear work flow", a few things good to be clarified:
  • the Linear things are actually related to the inputs and how you calculate inside the render engine,
  • guess some render result can be considered as intermediate images in the later work flow, so that there is export called Linear result, Need to say this is definately not anything I am questioning for, on the contrary,the Linear option is definately should be kept and in a pure linear way(I think I had mentioned this in the previous post)
  • What I am asking for is not a linear work flow issue, I am asking a color management issue, as mentioned many many times, keep the result aprearance consistancy. for this point, there is nothing to do with so called Linear,actually throughout all my posts I seldom mentioned "linear" ,neither work flow nor color space
  • in short "Linear" is an input issue, "color management" is a result issue,you always saying "linear", I always talking about "color management", as mentioned we are in the different world.Photoshop is more about result, instead of the "Linear workflow",so of course the way photoshop treat the colosr space is differnt from what you are familiared. Mixing the two world make things chaotic
  • the "linear color space" is related to the linear workflow means it is kind of for intermediate result means they can be used as input for the next other furthing renderings.
  • for results, it should be sRGB aRGB this kind of common standard color spaces, and CM related(as mentioned "lineared color spaces"may have nothing to do with the final result and CM)
  • so, I would suggest:
    • keep your linear work flow which is good,keep the linear export option,
    • provide result format that is CM (color management) friendly,just further to the existing very good PNG, that can provide multilayers for passes
    • Since the EXR is much related with the "Linear workflow" that make things so complicated,as mentioned many times, the multi-layered CM friendly output can be "tiff","psd" etc format(they can also be mutilayered and 16 or 32bit,so may also be considered as HDR)

Hope this can things easy,
I thought my request is a very simple and strait forward one, not thinking make so much complicates, does this situation shows that Otoy donot understand your users?
Otoy, do you think this is a big issue?

Supermicro 4028GR TR2|Intel xeon E5 2697 V3| windows 10| revit 2019 |Titan V+ Quadro GV100+RTX 2080 Ti
jimho
Licensed Customer
Licensed Customer
 
Posts: 262
Joined: Tue Aug 21, 2018 10:58 am

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby karl » Mon Sep 28, 2020 3:21 am

karl Mon Sep 28, 2020 3:21 am
jimho wrote:the above twocomparison, the png are both tagged the screen's color profile, which meet the viewport best,
there are slightly different when change the response curve from sRGB to gamma2.2, that is why I made each of them,and they are all accordingly, Left: PNG exported from the viewport at right(which respond curve has been changed),

the below comparison: PNG are as you instructed tagged sRGB.icc, the result looks differnt to the viewport where the image exported from
Png_TM_srgb_XB2_sRGB_g22_LUT_viewport_restart.jpg

Png_TM_srgb_XB2_g22Rc_g22_LUT_viewport_restart.jpg.png


These result has been described a few times in the early different posts, here just provide evidence, as mentioned if you are using a pure sRGB system, you can see the difference from your web browser(because I did CM on it),
but you cannot reproduce this.


Are you sure you're using the same display color profile in both Octane (Preferences > Color management) and Photoshop (which seems to take its settings from Windows color management settings)? Except for possible rounding differences, you should see the exact same result as the Octane viewport by exporting a PNG from Octane and displaying in Photoshop with an sRGB profile assigned. The screenshots you posted seem to be consistent with display color management being disabled in Octane (i.e. the display color profile being set to sRGB).
karl
OctaneRender Team
OctaneRender Team
 
Posts: 363
Joined: Sun Oct 13, 2019 11:26 pm

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby jimho » Mon Sep 28, 2020 3:48 am

jimho Mon Sep 28, 2020 3:48 am
karu wrote:Are you sure you're using the same display color profile in both Octane (Preferences > Color management) and Photoshop (which seems to take its settings from Windows color management settings)? Except for possible rounding differences, you should see the exact same result as the Octane viewport by exporting a PNG from Octane and displaying in Photoshop with an sRGB profile assigned. The screenshots you posted seem to be consistent with display color management being disabled in Octane (i.e. the display color profile being set to sRGB).

I see,yes, you are right.
In 2020.2, when in Octane ColorManagement, if choose sRGB, it will be consistancy with previous versions(2019and prior), means the PNG result need tag screen color Profile as before
when chooce screen in the preference, the result need to tag sRGB.icc.
Interesting...

Supermicro 4028GR TR2|Intel xeon E5 2697 V3| windows 10| revit 2019 |Titan V+ Quadro GV100+RTX 2080 Ti
jimho
Licensed Customer
Licensed Customer
 
Posts: 262
Joined: Tue Aug 21, 2018 10:58 am

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby karl » Mon Sep 28, 2020 4:35 am

karl Mon Sep 28, 2020 4:35 am
jimho wrote:
karu wrote:Are you sure you're using the same display color profile in both Octane (Preferences > Color management) and Photoshop (which seems to take its settings from Windows color management settings)? Except for possible rounding differences, you should see the exact same result as the Octane viewport by exporting a PNG from Octane and displaying in Photoshop with an sRGB profile assigned. The screenshots you posted seem to be consistent with display color management being disabled in Octane (i.e. the display color profile being set to sRGB).

I see,yes, you are right.
In 2020.2, when in Octane ColorManagement, if choose sRGB, it will be consistancy with previous versions(2019and prior), means the PNG result need tag screen color Profile as before
when chooce screen in the preference, the result need to tag sRGB.icc.
Interesting...


That's correct - when you select sRGB, Octane will convert the sRGB output of the renderer to sRGB (which does nothing - the same as previous versions). When you select your monitor's color profile, Octane will convert from sRGB to that color space, meaning if you want another application to do the same conversion you need to make sure it starts from sRGB just like Octane does.

This is what I meant earlier when I said that if you have the correct display color profile for your monitor selected in Octane preferences, you will never see colors outside the sRGB gamut in the render viewport, because the image coming from the renderer is always produced in sRGB and then converted to the display color space. What you were doing before was effectively disabling display color management in Octane, taking the sRGB image and sending it to the display as if it was Adobe RGB, and then tweaking it until it looked right, which is a way to get wide-gamut display in the render viewport, but also a way to confuse Octane when it comes to exporting an image later, because as far as it knows the image has always been sRGB.
karl
OctaneRender Team
OctaneRender Team
 
Posts: 363
Joined: Sun Oct 13, 2019 11:26 pm

Re: OctaneRender™ 2020.2 XB2 [current 2020.2]

Postby jimho » Mon Sep 28, 2020 5:59 am

jimho Mon Sep 28, 2020 5:59 am
I would prefer to describe the Octane's behavior like this:

Octane's render engine generate the source image data (D0) based on sRGB Gamut which original looking on sRGB Display is V0,
but what we are discussing the situation in aRGB display:
  • in case of Octane's color management is off(2019 or prior) or choose "by default sRGB",Data D0 is sent to display (which is aRGB display) without any translate in color values, (1.0->1.0), the appearance is actually scaled to aRGB space(because data not change so here 1.0 mean aRGB's 1.0),means the aprearance V1 will be actually in aRGB space, this process is same as an D0 data attached aRGB(screen) icc profile in photoshop, that is why the export of PNG ( 2019 prior , CM off and by default sRGB option) should choose aRGB.icc, if you want to keep the viewport looking same as in photoshop.
  • in Octane 2020,if screen color profile chosen,this new version added a new process to covert D0 to data D1 which have squeeze the data D0 to the according part of the screen space which will have same appearance with D0,from D0 to D1 will be like 1.0->0.995, data value changed but keep the same sRGB looking in the aRGB, then put this D1 to the screen,this D1 data is a aRGB image but keep the original sRGB looking, when export to PNG, D0 is exported(instead of D1), so when we put into photoshop when tag sRGB.icc, it will keep the same looking as the viewport.
  • it is always the D0 data exported, that is why it is said" image has always been sRGB"
but this may make a bit of confusions for users, as mentioned above, when you choose screen in the color management you need to choose sRGB in photoshop, when you choose sRGB in octane's color management you have to choose aRGB(screen) in photoshop. Isn't it confusion?
On the contraary, if in the second situation, if you export the converted (D1) data, it will be consistancy, that when you are using sRGB system you always choose sRGB.icc, when you are using aRGB display you always choose aRGB.icc.

Supermicro 4028GR TR2|Intel xeon E5 2697 V3| windows 10| revit 2019 |Titan V+ Quadro GV100+RTX 2080 Ti
jimho
Licensed Customer
Licensed Customer
 
Posts: 262
Joined: Tue Aug 21, 2018 10:58 am
PreviousNext

Return to Development Build Releases


Who is online

Users browsing this forum: No registered users and 4 guests

Thu Mar 28, 2024 4:34 pm [ UTC ]
cron