search

quic / qidk

Other
76 stars 16 forks source link

Why the size of the applicationInputBuffers is 4 times the actual size #11

Closed Sanath1998 closed 3 months ago

Sanath1998 commented 4 months ago

HI @quic-shubpate @quic-rneti @quic-ppant

In yoloNAS example Why the size of the applicationInputBuffers is 4 times the actual size. Input 1228800 (33203204) instead of 302700 (3320*320)?

Please if any proper explanation is there it would really help us.

quic-shubpate commented 4 months ago

Hi @Sanath1998 , we have to pass input buffer with Float32 datatype as it is supported by all CPU, GPU and DSP runtime, so each element is 4 bytes in size (buffer_size = no. of elements * size of element)

Sanath1998 commented 4 months ago

Hi @Sanath1998 , we have to pass input buffer with Float32 datatype as it is supported by all CPU, GPU and DSP runtime, so each element is 4 bytes in size (buffer_size = no. of elements * size of element)

Can we convert this to original array size as given? If yes what is the procedure or this itself with 4bytes we can process for post processing @quic-shubpate ?

Actually we are doing segmentation referring to this code so thought of asking if any suggestion please could you say @quic-shubpate

quic-shubpate commented 4 months ago

If you are using SNPE Userbuffer float then each element of the input array should be in Float32 datatype format (if it is not then you can typecast it). SNPE will also generate the output in Float32 datatype format.

This is generally used, as pre-processing on the input buffers needs to be done to change the input range between 0.0 to 1.0 or the range on which the model is trained.

If you are using SNPE Userbuffer TF8 / TF16 then each element of input array should be in UINT8 or UINT16 datatype and SNPE will also generate output in same dtype. (for eg: if model can directly accept camera RGB buffers without any pre-processing)

quic-rneti commented 3 months ago

Closing issue, as there is no further question for ~ 2 weeks