Make turbojpeg grey decoding

[giacomodabisias]

Hi,
it happend often to me to use a greyscale images from the kinect instead of the usual rgb. I changed the decoding call to turbojpeg to get it directly decoded as greyscale. I was wondering if it would make sense to create directly a custom listener for it to get greyscale images.
In case I will add that feature.

[xlz]

There would be major changes to registration, if you are able to figure out the required changes in pixel format for registration.

I would like to require the user to only receive either rgb or gray format in a certain pipeline. Decoding both formats wastes time and does not make too much sense because the user can always do that later. I don't want to expose another configuration interface to PacketPipeline, so I recommend the API design would look like this:

• OpenGLGrayPipeline

which calls an internal configuration interface TurboJpegProcessor::setFormat().

One might think this adds much duplication in pipeline names. Indeed, in 0.2 a configuration pipeline would be introduced, and be used like this:

• ModularPipeline::selectProcessors(ModularPipeline::OpenGL, ModularPipeline::TurbJPEG_Gray).

[giacomodabisias]

@xlz I agree with you.
The other simpler solution would be to just use a flag in order to decode either rgb or grey by just switching the turbojpeg decoding call and changing accordingly the registration. What do you think about this? The user could just initialize the usual pipeline and the listener just becomes a grey instead or rgb listener

[xlz]

You will need a new interface to "use a flag".

[giacomodabisias]

Yeah ok, but I just wanted to know if something like this would be ok since you have more experience in the development.
-add in the freenect device a flag protected by mutex
-use the flag in the turbojpeg decoder to change the behavior of

tjDecompress2(impl_->decompressor, packet.jpeg_buffer, packet.jpeg_buffer_length, impl_->frame->data, 1920, 1920 * tjPixelSize[TJPF_BGRX], 1080, TJPF_BGRX, 0);

by switching TJPF_BGRX to TJPF_GRAY
-Change accordingly the registration to the new gray image format.

It seems to me a simpler solution then to the previous one you mentioned, but if you see flaws in this I can work on the other.
Thanks

[xlz]

Let me explain. That "flag" protected by mutex would be a terrible interface because it's a global variable which requires extra operation with a separate lock variable. So if a new interface is really added, the interface is a function.

We do not want to expose decoder details to users neither because there can be indefinite number of decoders. So do not add a new API function that is a method of a decoder.

There is a bigger picture here. A new interface to compose and configure pipeline would be introduced. For example: Freenect2Device::selectPipeline("opengl", "turbojpeg-gray");. So it is probably a method of Freenect2Device, and you configure the frame format by calling the method upon a freenect2 device, not upon a decoder object. The format information is then passed internally to the decoder, or any way as is implemented, without worrying about breaking API.