Hi,
I will chime in because that statement is misleading, incorrect and dangerous. The main reason for using this workflow, i.e. the one that tries to nullify out the effect of the view transform, whether it is the ACES one or another, is to preserve the specific Output-Referred look of an existing asset.
Nowadays, most studios are using Scene-Referred workflows: they create their assets in a standard Working Space and review those assets under a chosen standard View Transform.
Onset references used to create assets textures or HDRIs are converted to the standard Working Space and reviewed under the standard View Transform.
Resources coming from outside, e.g. Google Images, are usually rendered, i.e. likely to have an S-Curve applied, and Output-Referred encoded, so if you want to integrate them in your workflow, you have to undo the encoding and rendering (which might prove impossible).
If you have “library materials authored in sRGB” then it is easy, convert them to the standard Working Space and make sure that you are always looking at them and presenting them under the standard View Transform. If somebody argues that they look different compared to before, just let that person know that the materials were seen without an appropriate View Transform back then and that it this is a situation that is unadapted for modern Scene-Referred workflows where computation accuracy and correctness are required.
Here is a small interlude quote:
“Friends don’t let friends view scene-linear without an S-shaped viewing transform”.
Now let’s take a critical but essential step back and think about what is happening when you are applying the Reverse View Transform on textures, e.g. using Output - sRGB as an IDT to preserve their Output-Referred look. You are effectively applying a Non-Linear transformation to Scene-Referred linear light values and thus transforming values that were previously radiometrically linear into values that are now non-linear. I will repeat in bold and with emphasis because it is CRITICAL: You are transforming initially correct radiometrically linear light values into now incorrect non-linear light values!!!
The Ramp in the following screenshot speaks for itself:
Note that in this above example I was purposely dis-regarding the fact that the textures might be stored in a 8-bit container and thus requires decoding, the problem would be the same nonetheless:
You should never-ever-ever-ever do that without an excellent reason, the only important one I see is to preserve logos and branding appearance for picky clients.
Cheers,
Thomas