Is it mandatory to convert the image to float?

[zanazakaryaie]

Hi
I want to accelerate AKAZE on ARM processors. Before everything, the algorithm converts the 8 bit image to a float image ranging from 0 to 1. Is this mandatory? How can I avoid this?

[pablofdezalc]

Dear Zana, It is not strictly mandatory. You can use 8 bit image for the scale space and 16 bit image for the derivatives. There could be some decrease in accuracy for the detector response but I guess it is possible to make it work. However, that is not something that is currently supported in the current library. Regards, Pablo

…

On Sat, 2 Nov 2019 at 07:59, Zana Zakaryaie Nejad ***@***.***> wrote: Hi I want to accelerate AKAZE on ARM processors. Before everything, the algorithm converts the 8 bit image to a float image ranging from 0 to 1. Is this mandatory? How can I avoid this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37?email_source=notifications&email_token=AAJY6CBH4WGB7YVEL6ABWXTQRUXPZA5CNFSM4JIDX7P2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HWJQJTA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJY6CGKGHXRNMUIUNQ3HIDQRUXPZANCNFSM4JIDX7PQ> .

[zanazakaryaie]

Hi Pablo
Thanks for the reply.

I think if I use the 8bit image, then all the convolution kernels (including those of gaussianBlur, scharr, and Hessian) must be multiplied by 255. Is that true?

[pablofdezalc]

You can use 8 bit image for the gray scale images generated in the scale space. However, for the diffusivities, first and second order derivatives you need to use float or 16 bits. If the convolution kernels are normalised, you don't need to multiply by 255. Regards, Pablo

…

On Fri, 8 Nov 2019 at 18:10, Zana Zakaryaie Nejad ***@***.***> wrote: Hi Pablo Thanks for the reply. I think if I use the 8bit image, then all the convolution kernels (including those of gaussianBlur, scharr, and Hessian) must be multiplied by 255. Is that true? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37?email_source=notifications&email_token=AAJY6CFMW7G2IFSC7KS6FALQSWTP3A5CNFSM4JIDX7P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDS5HQY#issuecomment-551932867>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJY6CGUYXXGWA7KLSCQBRTQSWTP3ANCNFSM4JIDX7PQ> .

[zanazakaryaie]

I started to use 8bit and 16bit data types for scale-space. Indeed, I used 8bit for gaussian blurred images and 16bit for scharr derivates. But the pm_g2 diffusivity image has 1/(1+X*k2) formulation which is float. I don't know what to do here. If I use float, then what datatype should I use for evolution images which are calculated in FED?

[pablofdezalc]

Dear Zana, In the current implementation you need to convert to float. It is possible to change some parts of the implementation to use 16bit data instead. However you need to be a bit careful with some conversions from floats to 16bits in some parts of the algorithm. Regards, Pablo

…

On Mon, 6 Apr 2020 at 22:10, Zana Zakaryaie Nejad ***@***.***> wrote: I started to use 8bit and 16bit data types for scale-space. Indeed, I used 8bit for gaussian blurred images and 16bit for scharr derivates. But the pm_g2 diffusivity image has 1/(1+X*k2) formulation which is float. I don't know what to do here. If I use float, then what datatype should I use for evolution images which are calculated in FED? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJY6CH2YKVSYZLKJMXZP43RLJALBANCNFSM4JIDX7PQ> .

[zanazakaryaie]

So you agree that only some parts can be converted to 8 or 16bit. Other parts must remain float. For example the diffusivities. Could you please guide me which parts can be converted and which parts cannot?