[JdeRobot] Compressed Images

[Oscar Garcia]

Copied from github: 
https://github.com/RoboticsURJC/JdeRobot/issues/1#issuecomment-87491182

After write it I'm thinking that this is a very important topic to talk 
about at the next developers meeting.


--> Start of copied message
PS: Refactor image interface leave a BIG problem: backward compatibility 
is completely broken.

You had not modified opencvdemo, but if I try to connect new opencvdemo 
version to my current AndroidCameraServer version, opencvdemo drops lots 
of messages about error protocol version.

If interfaces left untouched all applications are compatible until the 
last interfaces modification, so I think that is VERY important to 
change version number and document (in ChangeLog for example) to warning 
that anything compiled previously will be ever compatible until new 
recompile.

Another point is: Is it really necessary? *Compression could work fine 
without interface refactor. Server capabilities would be the same that 
client because both of them relies on colorspace functionality.*

It's simple: RGB8 still been the same RGB 8 bits per pixel without 
compression, RGB8z could be same RGB 8bpp but compressed. Compatibility: 
cameraserver (or androidcameraserver) could use or not compression with 
an command parameter (or #define), so it will send RGB8z format and 
colorspaces in client side will do the conversion to RGB8 if needed when 
execute:


         /* Get image with same format as origin */
         colorspaces::Image frame(image_data->description->width,
                                  image_data->description->height, format_string,
                                  &(image_data->pixelData[0]));
         /* Conversion to RGB8 will happen only if needed */
         colorspaces::ImageRGB8 frame_rgb8(frame);



I'm using a new format a few years ago (NV21) that was compatible with 
cameraview but not with opencvdemo because it only supports RGB8 because 
it didn't rely on colorspaces. When I refactorize opencvdemo I added 
that functionality and now I can use NV21 (and any other format 
supported by colorspaces).

*There is no need to create new methods or refactor interfaces.* Yet, 
maybe in a future version upgrade get image format and negotiate best 
will be useful, but right now it could be a fragmentation problem. Some 
components of jderobot 5.2 (or we are in 5.3) couldn't communicate with 
other components of jderobot 5.2.

IDEA: Attach changes in interfaces (not new ones, only changes in 
existing ones) to major version update.

I think that refactor Image would wait until jderobot 6.x version.

Conclusion: let colorspaces do it's job of converting from RGB8z to RGB8 
if needed as done until today. The user could decide if server will use 
or not compression with a parameter (maybe) based in client capability 
(if it is a old one without compression or it supports compression) so 
until new minor (or major if decided) version the default will be 
uncompressed, but in new version the default will be compressed and a 
warning about it would be important.

This could be the beginning of beautiful topic.

Regards.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20150330/a8dab642/attachment.htm