[JdeRobot] Compressed Images

[Roberto Calvo]

Hi,

Firstable, in the future don't write the same message in list and
Github. May be it's confused for external people that just they read the
Github.

We talked about that in the last developers meeting, and we know that
the compatibility is broken with previous versions. We assume this
change because is a great functionality that we need. The same instance
of a server can receive distinct petitions of compressed/regular images,
and serve them without problems. For that, we decided modify the
interface because getImageData doesn't have any parameter and add new
method is not a clean methodology. Also, the changes are just a few.
Just add one method in the server to say what formats are allowed, and
for the clients nothing to do if you use cameraClient.

Reminder for everybody, master is the development branch of the project,
and it's constantly changing. So don't use if you don't want to face up
with these problems. For that we have a release version (currently
JdeRobot 5.2.4-RC1 (July 2014)). We'll decide the number of new version
when the software is released.

Regarding opencvdemo component, it's working fine with the other
components of the repository and of course it's in continuously
developing. So, there is no problem if we need to add NV21 format to
cameraServer or wherever. And we can help you guys to modify your
personal components in order to update with the last changes of the
software.

Best,


El lun, 30-03-2015 a las 00:44 +0200, Oscar Garcia escribió:
> 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.
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers

-- 
Roberto Calvo Palomino        | Robotics Lab (GSyC) 
R&D Android Mobile Engineer   | Universidad Rey Juan Carlos

Twitter: @rocapal 
Linkedin: http://www.linkedin.com/in/rocapal