That's only because it's not viewed in the right color space? (I'm using color space in the ICC sense to also include the transfer function).
For some reason video folks seem really intent on creating their own terms for everything that photographers already standardized with ICC. And to make things worse they decided to make the EOTF and OETF not be inverses of each other.
Of course things will look off if you display a log-encoded image on a display that uses a power-gamma. You have to linearize the input (invert the log-encoding) then delinearize (inverse power) before sending it to the display. With ICC-aware tools (that most photographer uses) this conversion is done automatically for you (e.g. colorsync on mac).
But for some reason video workflows are not icc color managed. As I understand the oetf is basically unused entirely: since edits are made under bt1886 conditions, effectively baking in this bt1886 assumption on the viewer side as well. This seems to be the exact opposite of how ICC workflows work, where regardless of the monitor color profile the editor uses, all edits are transferred to the underlying source color profile of the image.
The only page I've ever seen which actually acknowledges that "log encoding" is just an alternative to gamma encoding is https://imatest.atlassian.net/wiki/spaces/KB/pages/114161421..., as I discussed in an earlier rant https://news.ycombinator.com/item?id=37877599