You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
on Android we get raw Camera stream in YUV format where first width*height values (Y plane) is grayscale representation of the frame. now the implementation doesnt allow to access this raw stream data it just converts it to the specified pixel output format (RGB by default) which u need for rendering.
i think it not very efficient way of working with camera data. imagine we are doing some CV stuff in most cases such tasks require Grayscale representation of image and in our case we need to convert again (not fast on mobiles). probably it would be a nice addition to store Y plane of incoming YUV frame. and return it on request. it will save quite significant amount of computations in some scenarios. of course it is Android only feature but still reasonable one.
let me know what u think.
also i looked at YUV2RGB conversion routines and was wondering why not to implement NEON optimised one since u have an option to compile lib with neon support enabled. of course compiler will try to do it for u but in most cases manually done methods works way faster then auto generated by compiler.
The text was updated successfully, but these errors were encountered:
on Android we get raw Camera stream in YUV format where first width*height values (Y plane) is grayscale representation of the frame. now the implementation doesnt allow to access this raw stream data it just converts it to the specified pixel output format (RGB by default) which u need for rendering.
i think it not very efficient way of working with camera data. imagine we are doing some CV stuff in most cases such tasks require Grayscale representation of image and in our case we need to convert again (not fast on mobiles). probably it would be a nice addition to store Y plane of incoming YUV frame. and return it on request. it will save quite significant amount of computations in some scenarios. of course it is Android only feature but still reasonable one.
let me know what u think.
also i looked at YUV2RGB conversion routines and was wondering why not to implement NEON optimised one since u have an option to compile lib with neon support enabled. of course compiler will try to do it for u but in most cases manually done methods works way faster then auto generated by compiler.
The text was updated successfully, but these errors were encountered: