Sure but modern ICC color-managed workflows (e.g. digital photography, printing) basically don't distinguish between EOTF and OETF. Assuming your source is tagged correctly and all displays have a profile matching their true response, you necessarily need to linearize with the inverse of the encoding gamma. All edits are done directly in the source color space, if the viewer's profile differs from the source it's up the viewer to translate accordingly. You don't edit images "on the assumption" that they'll be decoded with a 2.2 gamma.
For some reason video workflows never adapted to the ICC system (probably because in CRT days you couldn't really adapt your decode gamma on the fly) which is basically where the whole debate in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... comes from.
I'm not saying that the people using 2.2 EOTF are wrong, but all this just adds to the absurdity: in the modern day where LUTs are cheap and plentiful, instead of tagging content as an ambiguous sRGB it could simply be tagged as gamma 2.2 if it's actually intended to be decoded at that gamma.
For some reason video workflows never adapted to the ICC system (probably because in CRT days you couldn't really adapt your decode gamma on the fly) which is basically where the whole debate in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... comes from.
I'm not saying that the people using 2.2 EOTF are wrong, but all this just adds to the absurdity: in the modern day where LUTs are cheap and plentiful, instead of tagging content as an ambiguous sRGB it could simply be tagged as gamma 2.2 if it's actually intended to be decoded at that gamma.