Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - piotrus3333

Pages: [1] 2 3 ... 21
1
comparison of rec709 vs acescg as rendering spaces for P3 displays.
use P3 capable apple device (apple should be simple and fool proof, I have no idea how android handles icc profiles, if you know what you're doing any P3 display will do)
save images in Files app (to avoid displaying in web browser)
compare.

albedos are samples from Pointers' gamut (80's study for Kodak, measuring most vibrant natural colours)
Pointer's gamut was pretty much a base for rec2020 and acescg colour spaces and it is wider than P3 - so what you see on your iphone is still not "PBR enough".

be mindful of the fact that this test shows only a slice of what wide gamut rendering is able to offer (vibrancy of natural surfaces, presented as low roughness samples lit by fairly muted enviro map) - but it should be fairly representative of what is common within context of archviz.

2
[C4D] General Discussion / Re: ACES 2 ?
« on: 2025-09-04, 13:57:05 »
we still only have the tonemap operator, and if i use the c4dinetrnal ac3es setup thing tend to get messy.


could you elaborate, if possible?
what is messy on C4D side?
(I'm not familiar with C4D colour management at all)

3
heh, I was hoping the phone display example will put things into perspective more clearly.
P3 HDR displays will be a new standard at some point. like displays bigger than HD did.
and when displays got bigger we started to render bigger images. same with colours. just a loop of progress - adoption - standard.

if you don’t see the need today - no point in worrying about it. it’s enough to be aware of the progress part.

4

And I guess to relate to the thread, I would also assume that most studios / artists who mainly produce archviz don't need to mess with color management settings besides simply keeping their monitors calibrated and using those profiles correctly.

it's not about the subject but the delivery technology: most phones nowadays have P3 screens. this means that non colour managed Corona UNDERSTANDS only 67% of colours a small device in your pocket is able to DISPLAY. that does not sound very PBR, does it?

5
true, lack of options for cxr saving is inconvenient. need convenience? pay more for VRay.
not keen? process your cxrs with external tool - I suggested Gaffer here quite a long time ago (keeps cryptomatte metadata intact by default). any tool able to copy exr metadata will work.
what’s the point of adding exr processor to Corona? waste of resources imho.

6
General CG Discussion / Re: disappointment with corona 13
« on: 2025-07-24, 14:17:05 »
food for thought:

Corona for 3dsMax
data from https://chaoscorona.ideas.aha.io/ideas

most popular with 99 votes - UI update to Qt - fair enough, all good here.
second most popular with 65 votes: "Moon & Stars addition for Corona Sun & Sky" - sorry, what?

43 votes: "Aspect ratio / image resolution per Camera" - wait.. few ways of doing that in 3dsMax plus countless scripts and plugins, is it really needed?

only 6 votes: first (most popular) "'idea" mentioning issues with CXR format. big deal for everybody rendering animations I would assume.
only 4 votes: texture baking. actual workflow breaking incomplete feature.


a question arises - is developement led by "users' needs" getting Corona in the right direction?

7
Image filter is how you control the look in this case.
try softer/larger filter.

8
The trick with transitioning fairly smoothly to Vantage is experience with changing from VRay to VRay RT (and later VRay GPU). You need to build your scenes while having Vantage's supported features list in front of you.
Transitioning from VRay GPU to Vantage is not easy. Transitioning from Corona to Vantage is completely another level of a task.

9
you can see what happens to saturated colours transformed with inverted aces 1.3 display transform here:

10
max 2024 default ocio config, Corona 12 hf2:

after changing colour management settings to Rendering Color Space: scene-linear rec 709-sRGB Corona locks Internal color space in Development/experimental stuff to sRGB (linear rec 709).
is this behaviour expected and as designed or should it be considered a bug?
as from the very beginning internal rendering math in Corona was always performed in at least Adobe wide RGB space this might lead to some users switching from 3dsMax default ACEScg to scene-linear rec 709-sRGB, expecting legacy-like (gamma 2.2) setup but in fact limiting Corona to pre-Corona, 2011 VRay's colour math with all its lighting bugs and limitations.

11
@piotrus3333 what am I doing wrong? :)
1 - set custom config in 3ds Max and load your OCIO
2 - set global default view transform to ACES 1.0 SDR-video - this way we get identical result to the default 3ds Max OCIO color management setting
3 - load a .jpg bitmap and pick "ACES 1.0 SDR-video sRGB" as its color space
4 - render

Unfortunately, the bitmap I am using is still "tonemapped". For example sampling a pure white color gives RGB207.

bug in CoronaBitmap node?
works as expected with OSL UberBitmap (texture is 0.0 for black and 1.0 or white):

12
[Max] I need help! / Re: OCIO / ACEScg
« on: 2025-04-30, 14:03:48 »
RGB primaries set to "auto" should give you the correct results.

first time loading a bitmap into CoronaBitmap follows ocio rules (sRGB by default) but then selecting Auto gives incorrect result (Linear sRGB in this case).

and why there is no "gamma 2.2 sRGB" in the drop down options? this would be the natural option to pick for users coming from old 3dsMax versions.

13
You need to tag all input textures with correct colour space so Corona can transform the data into your rendering colour space. In user contribution section there is “alternative ocio for 3dsMax” containing “aces sdr video” colour spaces. use one of those.

14
not supported in 3ds Max.
Try Natron or Resolve.

15
OCIO config based on RED display transforms and RED Creative LUT Kit:
https://piotrus3333.gumroad.com/l/ydlfxm

Pages: [1] 2 3 ... 21