Hi, Vlad. That's probably the simplest approach with the existing set of IBA functions, yes. Maybe there is some optimizing you can do around the edges -- like, `mul(img,img)` may be faster than `pow(img,2.0)`, I'm not sure, and definitely you want to use the variety of IBA functions that takes a destination image rather than returning an ImageBuf, in order to minimize needless buffer copying. But those obvious tricks will only get you so far.
If you're doing this a lot and it's performance critical, a better way would be to write it as a single function that uses ImageBuf::Iterator to traverse the image and do all the operations at once for each pixel, with no extra buffer copies. Looking at the source code to any of the usual IBA functions that take one input image and produce one output image will provide you with a good example to copy and change the guts to make your new function. I don't recall anybody asking for this particular thing before, but if you think it is a commonly needed operation, then by all means propose a PR to add this new function after you've implemented it. On Sun, Jun 4, 2023 at 6:28 PM Vladlen Erium <v...@hdri.xyz> wrote: > What should be most efficient way to implement normalizing vector data > images (normals) using ImageBuffAlgo? > > For this moment I only see the way to do this in four steps. > ImageBuffAlgo::madd for [0.0,1.0] -> [-1.0,1.0] > ImageBuffAlgo::pow for power of 2 > ImageBuffAlgo::sum_channels for vector magnitude > ImageBuffAlgo::div (sec and magnitude) to normalize vector length > ImageBuffAlgo::madd for normalize to [0.0, 1.0] range. > > This not only required to make so many steps but also required a lot of > temporary buffers, that for huge textures can required lot of memory. When > all steps can be done per pixel and perfectly parallelized (shaders, cuda). > > Maybe I missed some OIIO functions? 🤔 > > Best regards: > Vlad > > PS: btw, looks like Google completely filter out all Larry messages if > Gmail used for subscription to this mailing list. They even not in spam > folder, where mail list messages quite often can be moved 😒 > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > -- Larry Gritz l...@imageworks.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
