@Maru - I hope this didn't come off as offensive, but here's a good reason not to suggest:
A) In case OS uses sRGB, just assign sRGB in PS (and optionally convert to whatever space users wants to work in)
B) In case user is using a calibrated display or uses a manufacturer display profile, assign that profile to your document in PS (and optionally convert to whatever space users wants to work in)
Reasons for not suggesting A
- I might use a calibrated device > suggesting sRGB results in wrong colors
- I might use a display that came with some installer which silently installs a generic display profile for the display (and user might not know it) > suggesting sRGB results in wrong colors
- I might switch my main display, old one was uncalibrated, new one comes with calibration profile... same wrong suggestion
Reason for not suggesting B
- When calibrating, the resulting display profile will change slightly every time a display is calibrated. The reason for this can be an aging display, user error, calibrating device picking up ambient lighting and making the calibration dependent on daytime or room lighting while calibrating, and profiling intent (for example having profiles with different target brightness to accommodate for different lighting conditions for postproduction people working in the studio or on site of production).
In case of an aging device, which will inevitably occur, my display profile is *different* from the one I've used a few months earlier. It means that assigning the profile 6 months back will not look the same when I re-render the job now and assign my current - now slightly different - profile. The display profile of a calibrated device will inevitably change over time if user cares enough to re-calibrate every given time span. If I don't re-calibrate I lose color fidelity, so one of my responsibilities in a color-aware working environment is to make sure I re-calibrate ragularly (or 'validate' the profile as it's called).
- Similar argument as above, I buy a new display. Both were calibrated but the new one is obviously technically better. Both calibration profiles will look vastly different when assigned to the same image. The profiles are all right, but they correct for a very different base scenario, and they will not be identical, resulting in different colors when following the advice.
And here's where Corona development can help. Please please please finally add a final color transform to the VFB that would allow the user to assign a profile just like PS/AE do it.
I've had the discussion with some devs in the past and the argument against it was that they would need to take care of input maps and color values... no, you absolutely don't!!
Sure you could do it, but only if you needed to convert color values from one space to another, which you don't!
Here's an example:
Important preface for those who aren't aware - color profiles don't change the pixel values, they add a color transform for the device output *only*.
Let's say I'm using AdobeRGB as my main profile for ALL my work. I have my textures and backgrounds prepared in PS using AdobeRGB.
I load them into Max, which ingores it, uses either sRGB or my display profile to display them, and yes, they look like shit.
BUT, the moment I render them, and have the VFB apply a display transform to AdobeRGB, they look exactly like what they looked like in PS. (Let's ignore the OCIO or ACES tonemapping operator for the sake of the argument I'm trying to make). If I save the file, and the profile I chose in the VFB will be embedded in the file, I will have the same colors I had in PS originally, and how the VFB displayed them wherever I'm looking at them (PS or Windows).
(Whether or not the profile is embedded is not important, but I'll know that what I see in the VFB will not be the either crippled sRGB crap or overly saturated wide gamut output of a pro-grade display but proper AdobeRGB I'm using in PS, too.)
Yes, they won't look like they do in PS in the viewports etc, because that's the 3dsmax part and they chose to ignore ICC entirely. Yes, OCIO might falsify this and tone mapping will do another round of 'damage' to my input, but that's not the point. By giving the user the option you would do *your* part.
This way, I gain the ability to see my intended colors in the VFB and frankly, that's what I care about the most.
The creator of VFB+, a nice VFB plugin from ancient times when renderers didn't come with their own VFBs and postprod options, integrated ICC display transform in a weekend. And he struggled most with CMYK conversion which you wouldn't have to care about at all. It really was a matter of a few days.
Or... you guys can just go on with the common bi-weekly post about 'my colors look different in PS', not caring about pro users who really need color fidelity in their pipeline and ask for it since years, and not educating people and giving them wrong advice instead. I could go on and on... it's just frustrating to see how this gets ignored.
I'm open for discussing this problem and how to overcome it in another place if needed, be it a new thread or discord. It's high time this gets solved as far as can be done on Corona's side.
