`dai::RawImgFrame::Specs::bytesPP` doesn't contain `3` for `RGB888i` and several other types

[diablodale]

the function dai::RawImgFrame::typeToBpp() returns unexpected values for common image types. Here are seven examples, they may be more...

type	result	expected
RGB888i	1	3
BGR888i	1	3
RGB888p	1	3
BGR888p	1	3
RGBA8888	1	4
YUV444p	1	3
YUV422p	1	2

Setup

• depthai-shared v2.17.0 and continues to main

Repro

A quick hack...

1. Write app that will capture the 1920x1080 NV12 color frame from the sensor
2. color_frame->setType(dai::ImgFrame::Type::RGB888i);
3. Inspect the frame's bytesPP

Result

bytesPP = 1

Expected

bytesPP = 3 because RGB888i uses 3 bytes per pixel to represent the color

[themarpe]

Thanks for the report @diablodale

@whoactuallycares do you mind addressing this in such setters (as setType) and in FW, to set the bytesPP at the final serialization accordingly (Note, use typeToBpp function)

[whoactuallycares]

Changed values in 1b122a9

[themarpe]

Thanks, add @szabi-luxonis to review as well

[diablodale]

Hi @whoactuallycares. Will code I don't have visibility into work correctly when bytes are rounded up? For example, NV12 uses 1.5 bytes per pixel and your commit has 2

[themarpe]

We'll likely have to change to a floating represenatation for cases where bytesPP would be used to do a stride*bytesPP*height to calculate the image size. At current state it was more inline with planes - eg it denoted bytes per pixel on a plane, but still not completely correctly due to NV12 and others having different sizes per plane