Great!
That's a good question about how to deal with the fact that some input
images will be "0-centered" and others will be "[0,1] encoded with 0.5
center".
Observe that because we're normalizing, there is no need to scale the
input; subtracting 0.5 is sufficient: x = fullrange ? x : x - 0.5
So here is what I'm thinking might be the right way to generalize:
IBA::normalize(ImageBuf& dst, const ImageBuf& src, float center = 0.0f,
scale = 1.0f, ROI roi = {}, int nthreads = 0);
The code simply uses (x - center) for the input (no conditional
needed!)
And the computation outputs: X/length(X) * scale + center
So if you have full-range values (like exr) and you want unit-length
vectors out, for in-place normalization you can just call
normalize(img, img);
But if you know you want values in and out to be on [0,1] with 0.5 meaning
neutral, then you call it as
normalize(img, img, 0.5f, 0.5f);
And at no extra cost, the flexibility is built in to produce other lengths
of vectors or use other center points.
What do you think about that?
On Thu, Jun 8, 2023 at 8:30 PM Vladlen Erium <v...@hdri.xyz> wrote:
> I think i did it.
>
> Had an issue with half-float from Imath, but maybe because tried to
> reimplement template.
>
> And results pretty fast. 1000x iterations on 4K texture: 18.564438 sec so
> roughly 0.01856 sec for normalizing.
>
> Have one question. What is better for OIIO, single function that will have
> boolean FullRange option as an input and x = !fullRange ? 2.0f * x - 1.0f :
> x; in code or two normalize functions one for 0.0-1.0 range inputs/outputs
> and another for -1.0 +1.0 range?
>
> Integer normal maps usually 0-1 range, when float exr, if 3D artists have
> a brain should use full -1 +1 range, but quite often in studios with
> "liniar workflow" EXR textures also can be in 0-1 range.
>
> Best regards
> Vlad
>
> On Jun 9, 2023, at 11:13 AM, Larry Gritz <l...@imageworks.com> wrote:
>
>
> Yes, I am convinced that IBA::normalize() would be useful to add.
>
> 🎣 Mackerel!
>
> (somebody should start by filing an issue so we don't forget about this
> potential enhancement)
>
>
> On Thu, Jun 8, 2023 at 7:08 PM Vladlen Erium <shaam...@icloud.com> wrote:
>
>> Thanx Larry!
>>
>> I definitely will check ImageBuf::Iterator. And do my best.
>> Common or not, but if you'll check some of 3D format parsers, you can
>> find that they are by default normalize vertices normals. And even if most
>> 3D DCC apps do the same with normal maps inputs, and most normal maps
>> generator output normalized data, it still a good to have this function in
>> openimageio, well, just in case. :D
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
