On Tue, Sep 1, 2015 at 12:33 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Tue, Sep 1, 2015 at 7:02 AM, Kevin Wheatley <kevin.j.wheat...@gmail.com> > wrote: > >> Following on from my previous email, this adds some functions to >> actually convert from linear to non-linear encoding. I have another >> that changes the OpenEXR codec to actually use these. > > > Won't performance be crumblingly slow with this kind of API? It seems to > make more sense to write a filter that can convert between different TRC > types, or do it in swscale, and then add some fast implementations > (LUT-based, or approximation-based) alongside the slow versions.
I'm using the functions to construct a LUT in the OpenEXR reader when possible, the cleanest design would be to pass floating point into the swscale engine for sure, but I'm not sure I'd personally want to go changing that code. I'm happy for some other approach to be put forward, I have some users who wanted the feature, so I have something that works for their needs so my urgency is minimal. I've performed a few more tests and spotted something missing in one of my earlier changes in the pixel description code, patch to follow... Kevin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
