Closed yjmade closed 4 years ago
libfreenect2 does not suppose all jpeg result is BGR. It merely passes through what is decoded from jpeg. This introduces additional processing which may not be needed by the user. The viewer showing wrong colors is not a problem.
libfreenect2 does not suppose all jpeg result is BGR.
At least the OpenNi2 driver part expect the color stream input would be in BGR, and it store the data as RGB.
modes[makeOniVideoMode(ONI_PIXEL_FORMAT_RGB888, 1920, 1080, 30)] = 1;
And the origin code of ColorStream::copyFrame
actually did flipping the color.
What I did is just make this method use the origin order of color from decoder, in this case is RGB, to match what OpenNI2 expect. This will not introduce addition computation.
OpenNI2 says it expects BGR but does it do anything that using RGB in place of BGR would make a difference? My expectation is that this RGB be passed down the pipeline as false BGR until where it is to be used as actual BGR and until then would this RGB be converted to BGR, not using this CPU swapping, you know, but with Tegra specific hardware accelerated routines that have to be provided by the user as it's inconvenient for this library to introduce more dependency on platform specific APIs.
TegraJPEG only support return RGB but libfreenect2 suppose all jpeg result is BGR. #774 #1082