Saved render output does not match the OctaneRender Viewport

[DMAEuropa]

I am beginning to notice major issues when it comes to saving final rendered images.
It does not matter on the scene, file type, or render settings, the issue is still there.
I have even tried versions 4.05 all the way up to the latest 2020.1.5.

Basically upon saving a file, some strange artifacting/compression/gamma issue is occurring, but in the OctaneRender Viewport the issues are completely gone.

I have attached two images showing a closeup of the issue in question, with the left image showing a screenshot of the Render Viewport and the contrast bumped up so you can see it still retains lots of detail.
And the right image shows what happens when an image is saved in any fashion.

The gamma settings are 2.2 across the board and I'm using linear workflows, I'm completely baffled! I'm wondering if it's an obscure 3DS Max setting somewhere.

For now I'm stuck with harshly clipped dark areas and lots of colour banding. Any help is appreciated!

[DMAEuropa]

Update!

I managed to figure this out, it turns out I was using tonemapping wrong as I was used to the way 4.04 worked.

I switched tonemapping to HDR and made sure my camera settings were all using a gamma of 1, which meant that I could still compress highlights and get a lot more control.
Now I'm exporting 32 bit images once again and I'm very happy!

[DartFrog]

This is still an issue. According to Paride, the sdk is missing LDR which is causing this issue. Somehow this bug has carried all the way from octane v4.05 to the newest 2020 plugin. For those of us that don't have the space for saving out 32-bit images, we still cannot upgrade to any of the newest octane plugins until this is solved.

[paride4331]

Hi DartFrog,
there's been some misunderstanding, maybe I did not explain myself very well.
I meant about the v2020 UI went into the v4.05 UI, nothing about the SDK; you can save out 32-bit.
Regards
Paride

[DartFrog]

Sorry, I meant as far as storage space goes, we are unable to save 32-bit images. We work on too many projects to save out 32-bit images for each project. Our workflow requires LDR 16-bit PNGs, and currently we can not save out a png in any new plugin because the image gets clipped and if it's saved with an alpha, the whole image ghosts and has alpha applied to it instead of just the areas with transparency (per my post here viewtopic.php?f=80&t=76179 ).

[DartFrog]

Hi DartFrog,
there's been some misunderstanding, maybe I did not explain myself very well.
I meant about the v2020 UI went into the v4.05 UI, nothing about the SDK; you can save out 32-bit.
Regards
Paride

Hi @Paride,

I just wanted to make sure you know what I mean. As it stands we cannot work in low dynamic range in any plugin past 6.20. Saving out the images with alpha adds alpha to the whole image instead of just the areas with transparency (per my attached images). LDR also clips black and white levels per the images above in this original post. I would happily save out 32 bit images, but they are too large for the amount of projects our studio works on per day. We have to be able to save out tonemapped 16-bit PNGs the same way we save them out in 6.20.

Is there any plan to release an update with this fixed? Please let me know if you need any more info from me too.

Cheers