<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Copied from github: <a
href="https://github.com/RoboticsURJC/JdeRobot/issues/1#issuecomment-87491182">https://github.com/RoboticsURJC/JdeRobot/issues/1#issuecomment-87491182</a><br>
<br>
After write it I'm thinking that this is a very important topic to
talk about at the next developers meeting.<br>
<br>
<br>
--> Start of copied message<br>
PS: Refactor image interface leave a BIG problem: backward
compatibility is completely broken.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Another point is: Is it really necessary? <b>Compression could work
fine without interface refactor. Server capabilities would be the
same that client because both of them relies on colorspace
functionality.</b><br>
<br>
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:<br>
<br>
<br>
<blockquote>
<pre><font color="#000066"> /* 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);
</font></pre>
</blockquote>
<br>
<br>
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).<br>
<br>
<b>There is no need to create new methods or refactor interfaces.</b>
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.<br>
<br>
IDEA: Attach changes in interfaces (not new ones, only changes in
existing ones) to major version update.<br>
<br>
I think that refactor Image would wait until jderobot 6.x version.<br>
<br>
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.<br>
<br>
This could be the beginning of beautiful topic.<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<br>
Regards.<br>
</body>
</html>