Author Topic: Tonemapping - Plz Halp  (Read 19964 times)

2020-05-22, 10:49:34
Reply #360

Nejc Kilar

  • Active Users
  • **
  • Posts: 965
    • View Profile
    • My personal website
@Designerman77

I don't want to be a negative Sally but I think the C4D version in general can't be compared to the 3ds Max version. At least not yet. We still have a lot of instabilities, full releases that break all the render farm compatibility / local render farm compatibility and imho it just isn't production ready yet (know of a few studios that agree too). I mean we can't output tonemapped images (8/16bit) without noticeable color space issues, let alone tackling things like bump maps not being able to scale... And the way releases are scheduled, you can't even use render farms reliably because they use the official version but those ship with really basic bugs more often than not and so you constantly need to switch between dailies and full releases.

As for this thread in general, to all of you who partake in the debate here, thank you for being cool! Reading through these pages is fun and while I agree a lot of it is subjective or could be tested better, I think it at the very least sparks another discourse on the topic. Thank you all!
« Last Edit: 2020-05-22, 11:54:59 by Nejc Kilar »

2020-05-22, 11:48:54
Reply #361

Designerman77

  • Active Users
  • **
  • Posts: 503
    • View Profile
@Designerman77

I don't want to be a negative Sally but I think the C4D version in general can't be compared to the 3ds Max version. At least not yet. We still have a lot of instabilities, full releases that break all the render farm compatibility / local render farm compatibility and imho it just isn't production ready yet (know of a few studios that agree too). I mean we can't even output tonemapped images (8/16bit) without noticeable color space issues, let alone things like bump maps not being able to scale... And the way releases are scheduled, you can't even use render farms reliably because they use the official version but those ship with really basic bugs more often than not and so you constantly need to switch between dailies and full releases.

As for this thread in general, to all of you who partake in the debate here, thank you for being cool! Reading through these pages is fun and while I agree a lot of it is subjective or could be tested better, I think it at the very least sparks another discourse on the topic. Thank you all!


Hmmm... makes me a bit sad to hear that the C4D version is significantly worse than the Max-version.
From the quality of the images in the net, I've always had this subjective impression... let aside the rumors that C4D users are "less experienced in average" or 3DsMax is soooo much better.




2020-05-22, 11:54:22
Reply #362

Nejc Kilar

  • Active Users
  • **
  • Posts: 965
    • View Profile
    • My personal website
Well at this point its about reliability and usability and in my opinion the 3ds Max version is quite better off - especially on the reliability part. I'm sure we'll get there, eventually. GI, materials, tonemapping and things like that are obviously awesome in both versions :)

I suppose we shouldn't derail this thread with DCC specific stuff though. :P

To stay on topic, did we ever figure out what exactly was wrong with the current filmic implementation in the VFB? Afaik the shoulder slope was a bit off?

2020-05-22, 12:09:25
Reply #363

lolec

  • Active Users
  • **
  • Posts: 155
    • View Profile
Lolec can you explain why are new features harder to implement if more users are using engine in production ?
I dont get the correlation. Would it not be the opposite, the bigger the user base, the more money, the bigger and more talented team, the more features. No ?

Sure, I will try.

First, more money = larger team , unfortunately not always true. Finding talented people is incredibly hard. Even with all the money in the world. I bet the corona team hasn't gotten much bigger and most of the core developers have been there for years. VERY hard problem to solve, finding people.

When you have more users you have more "versions" of users.  THAUSANDS that use 3dsmax 2016, Thausands that NEED Phoenix for work. Or need to use their existing material libraries or absolutely NEED the render to be compatible with renderfarms.... the list goes on and on.

When you are creating a new niche product you can break compatibility or not work for 5% of people and that means a few dozen users, no big problem.

I will give you a good example:

Let's say corona team finds a way to make the render 50% faster but it will break compatibility with old materials. They CANT do it. There are a lot of people who depend on corona for work. They cant do something like that :(
Fstorm? he can probably still do stuff like that and upset people slightly, but not bring whole studios down.

Fstorm releases a feature, it doesn't work for some users, he gest 3 angry messages on facebook.

Corona CANT do it. they just cant afford to realease a broken feature. thousands of people depend on corona for work and need it to be rock solid.

It is a universal phenomenon, the larger the user base, the slower you can move. That's just the way it is :(



Well, Corona is not 100% "rock solid" either.
If it was the case, then why for heaven's sake does the "Quality Filter" in C4D still mess up all edges and surfaces, as soon as round-edge-map and / or bump map is applied?
This problem was literally shutting down my business for about two months when this denoising mode was integrated.
If the devs had not integrated the AI-denoiser after similar complaints from other users, I would have switched to Arnold as a last escape.

Lolec, for sure Corona is a fantastic engine, but we don't have to praise it like the golden calf. :)
Only constructive critique brings improvement...

I think that just proves my point. A new feature broke something for some users, and they had to spend significant amount of time fixing it until it was usable again.

Fstorm doesn’t have to worry about C4D ( they also have more devs, but the point is each dev has to worry about much more than just adding new features like a machinegun)

We are talking context here, I meant Corona is solid, robust, usable and compatible compared to Fstorm. As you all be comparing the two. There are more robust and production ready engines, those have an even harder time adding new features. Corona strikes some balance, a balance I like and prefer.

I think praise is part of criticism, I like that balance and would like them to continue prioritizing both aspects :)


2020-05-22, 20:03:23
Reply #364

Designerman77

  • Active Users
  • **
  • Posts: 503
    • View Profile
Hey lolec, don't get me wrong, I DO love the Corona renderer!
Totally. And I could praise its 90% fantastic features 24/7. :)

However, let's get back to our light mapping / color grading topic this thread had started with.
After having rendered tens and tens of white empty interiors with parquet floor, this showed me quite clearly where the small but very significant things lay, which make renders often look somehow lame, dull and as if your eyes simply cannot focus on anything in the pics:

1. light-dark transitions on surfaces ( e.g. room walls ):

with "usual" HC-values ( 1+ ), those transitions get very washed out. ( To avoid that I arrived at 0.7 - 0.6 as may standard setting for HC. )
Same effect (dull image) , although by far not so strong, when Filmic Highlight is used.
Filmic highlight should behave a bit differently from how it does at the moment. Currently it softly clamps the highlights but also brightens the mids / darks. Result: transitions on walls / surfaces again get dull.
In my opinion, filmic highlight should do the soft clamping ONLY on the highlights... leaving the mids & darks unaffected. So you don't lose the subtle contrast which you never get back by brutally cranking up contrast values.

2. The correct proportion between lit surfaces and those in the shadow.
On this point I will not philosophy too much.

If one uses HC 0.7 - 0.6 this seems to be quite okay.
HC 0.7 - 0.6 seems to also be the answer to my first point (transitions)... and it could work fine if filmic highlights behaved like proposed in point Nr. 1.



2020-05-22, 20:33:56
Reply #365

lolec

  • Active Users
  • **
  • Posts: 155
    • View Profile
I think it’s fair to wish and hope for better features, but I will only complain about corona the day my renders look as good as the best corona renders I can find. Until then, I better work on myself.

2020-05-23, 00:18:55
Reply #366

Designerman77

  • Active Users
  • **
  • Posts: 503
    • View Profile
I think it’s fair to wish and hope for better features, but I will only complain about corona the day my renders look as good as the best corona renders I can find. Until then, I better work on myself.

The best Corona-renders you can find online? One does not know how much post-work is in many of those renders.
As I stated before: a render engine should be so good that it makes post work just a matter of taste but not a necessity for a part of your renders. :)

However, I totally agree with your motto to work on oneself.

2020-05-23, 01:46:24
Reply #367

cjwidd

  • Active Users
  • **
  • Posts: 684
    • View Profile
    • Artstation
with "usual" HC-values ( 1+ ), those transitions get very washed out. ( To avoid that I arrived at 0.7 - 0.6 as may standard setting for HC. )

I really have to agree with @Designerman77 on this issue. I've been conducted a huge variety of tonemapping tests over the last few months and I do not consistently arrive at visually satisfying result with HC = 1.0 without a LUT.
« Last Edit: 2020-05-24, 03:58:01 by cjwidd »

2020-05-24, 08:43:57
Reply #368

cjwidd

  • Active Users
  • **
  • Posts: 684
    • View Profile
    • Artstation
Walls are diffuse (reflection level = 0) shades of grey - (186,186,186), (201,201,201), or (231,231,231) - meant to represent typical white wall paint values.
Scene is lit with v6 sun (FFFFFF) / sky (desat)

186,186,186


201,201,201


231,231,231


231,231,231 - EV: -1.025, default
*exposure matched to tonemapped versions


231,231,231 - EV: -1.025, default + Kim_Amland_fstorm 0.30 contrast


scene setup

« Last Edit: 2020-05-24, 13:32:20 by cjwidd »

2020-08-13, 00:35:39
Reply #369

cjwidd

  • Active Users
  • **
  • Posts: 684
    • View Profile
    • Artstation
\canon-lut-201911\3dlut\65grid-3dlut\full-to-full-range\BT709_CanonLog2-to-BT709_WideDR_65_FF_Ver.2.0.cube

It doesnt give me the same result in Corona as Vray however.

edit (sorry I missed part of your question):
I chose it because there is only 3 to choose from as I need a log to rec709 df65 to match the setup of the corona scene. (6500kelvin).
- BT709_CanonLog2-to-BT709_WideDR_65_FF_Ver.2.0.cube
- BT709_CanonLog3-to-BT709_WideDR_65_FF_Ver.2.0.cube
- BT709_CanonLog-to-BT709_WideDR_65_FF_Ver.2.0.cube

The first one didnt have a vignette, so used that to keep things as clear as possible without adding additional parameters. Its how I work normally with the VFB, the more you play with the tone mapping controls (highlight burn, contrast etc) the more you complicate things when trying to compare results.

@James Vella, can you explain why we would use:
- Rec-709 LUT instead of a DCI-P3 LUT?
- 65 grid instead of 17 or 33 grid - is that just a resolution consideration?
- 1d vs. 3d LUT?
- log vs. log2 vs. log3?
« Last Edit: 2020-08-13, 00:53:19 by cjwidd »

2020-08-13, 19:22:37
Reply #370

James Vella

  • Active Users
  • **
  • Posts: 169
    • View Profile
@James Vella, can you explain why we would use:
- Rec-709 LUT instead of a DCI-P3 LUT?
- 65 grid instead of 17 or 33 grid - is that just a resolution consideration?
- 1d vs. 3d LUT?
- log vs. log2 vs. log3?

- I didnt see DCI-P3 in this list and I work in rec709 color space generally so that choice was easy for me, leaving 3 options to pick from.
- grid size yes basically resolution.
- 1D LUT is ok if you want to control contrast, white point, basic color adjustments otherwise if you need more precise data then 3D LUT is the best choice.
- log,log2,log3 are just different profiles. I chose the most neutral one for this example. You can take a look at a comparison video below for a better look at the curve (this is for s-log fyi).

if you check the manual that comes with the download you will see it goes into more detail regarding the file name/acronyms.

eg.
[Gamut]_[Gamma]-to-[Gamut]_[Gamma]_[GridNum]_[Range][Range]_[Verison].cube

BT709_CanonLog2-to-BT709_WideDR_65_FF_Ver.2.0.cube



Also a good short video on Wide DR

« Last Edit: 2020-08-13, 19:57:24 by James Vella »

2020-08-19, 07:45:48
Reply #371

cjwidd

  • Active Users
  • **
  • Posts: 684
    • View Profile
    • Artstation
Just discovered this write-up by Jorgen Herland, seems to explains a lot of the undertones of this thread


2020-08-19, 20:06:18
Reply #372

James Vella

  • Active Users
  • **
  • Posts: 169
    • View Profile
Thanks for sharing, to quote from Jorgen:

"However, this requires the linear render be converted to log first, to compress all the RGB values into a low dynamic range before the LUT is applied..."

I tend to agree. This is basically my findings on page 13 of this thread when comparing ACES to the Canon LUT. It was pretty close and much less hassle then the current ACES workflow.

2020-08-19, 21:20:25
Reply #373

cjwidd

  • Active Users
  • **
  • Posts: 684
    • View Profile
    • Artstation
The suggestion is to convert the rendered image to log before applying the filmic LUT, BUT the Corona Renderer curve editor is too cumbersome to replicate the lin2log transfer function.

As a workaround - to that workaround (!) - the suggestion is to simulate the lin2log transfer function by adjusting the tonemapping options, e.g. contrast (5.0) and highlight compression (5.0).

Maybe it would be sufficient to create the lin2log curve in PS and then import into Corona Renderer curve editor to achieve the same effect(?) I tried to do this, but PS curve editor doesn't have bezier controls either lol
« Last Edit: 2020-08-22, 04:42:24 by cjwidd »

2020-08-19, 22:04:18
Reply #374

PROH

  • Active Users
  • **
  • Posts: 1140
    • View Profile
Hi. No expert on this, so this might be a stupid question:
What's wrong with using the "Input LUT is in Log color space" checkbox together with an ACES LUT (i.e. "Filmic Very High Contrast")? Picture attached.