<font size=2 face="sans-serif">Answer below in </font><font size=2 color=red face="sans-serif">red</font><font size=2 face="sans-serif">.
Sorry but the indexing method does not work in my email.</font>
<p>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Alexander Duda <Alexander.Duda@dfki.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Martin.Azkarate@esa.int</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">rock-dev@dfki.de</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">12/07/2013 17:50</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Rock-dev]
using FramePair structure to output two frames together</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">rock-dev-bounces@dfki.de</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>On 07/12/2013 05:14 PM, </font><a href=mailto:Martin.Azkarate@esa.int><font size=3 color=blue><u>Martin.Azkarate@esa.int</u></font></a><font size=3>
wrote:</font>
<br><font size=3>Hello,<br>
<br>
I have the following code that works fine to separate two interlaced images
that arrive in a single port and separates them into two frames that are
sent out in two different ports:<br>
<br>
void Task::updateHook()<br>
{<br>
TaskBase::updateHook();<br>
<br>
if (_frame_in.read(input_frame)==RTT::NewData)<br>
{<br>
Frame* left = new Frame(input_frame->size.width, input_frame->size.height,
8, input_frame->frame_mode);<br>
Frame* right = new Frame(input_frame->size.width, input_frame->size.height,
8, input_frame->frame_mode);<br>
deInterlace(*input_frame,*left,*right);<br>
Frame* left_gray = new Frame(left->size.width, left->size.height,
8, MODE_GRAYSCALE);<br>
Frame* right_gray = new Frame(right->size.width,
right->size.height, 8, MODE_GRAYSCALE);<br>
frame_helper.convertColor(*left,*left_gray);<br>
frame_helper.convertColor(*right,*right_gray);<br>
frame_left.reset(left_gray);<br>
frame_right.reset(right_gray);<br>
_frame_left.write(frame_left);<br>
_frame_right.write(frame_right);<br>
}<br>
}</font>
<br><font size=3>why do you convert the colour insight the component? Is
not the component supposed to just split the frame?</font>
<br><font size=3 color=red>-> I do it because the frames that arrive
in the input port are in BAYER mode and the Visual Odometry component that
is after this needs the images in RGB or GRAYSCALE. I could also leave
them as they are and do the de-Bayering in the next component. It does
not make a big difference for me but I believe it interconnects better
with the usual input/output frame type of other components. Anyway, I will
eventually change the component to accept property parameters on that (such
as output frame mode, and un-distortion if required)</font><font size=3>.<br>
</font>
<br><font size=3><br>
void Task::deInterlace(const base::samples::frame::Frame &input, base::samples::frame::Frame
&left, base::samples::frame::Frame &right)<br>
{ <br>
//! Note: input frame has a data depth of 16bits while the
left and right have a data depth of 8 bits. Bytes in the input frame are
mixed in order, one byte from the left, one byte from the right, and so
on. <br>
//! So in "one pixel" of 16bits of the input frame
there are "two pixels" of 8bits one of each left and right frames.<br>
</font><font size=3 color=red>uint32_t width=input.size.width;</font><font size=3><br>
uint32_t height=input.size.height;<br>
<br>
</font><font size=3 color=red>uint32_t i = (width*height*2)-1;<br>
uint32_t j = (width*height)-1;</font><font size=3><br>
<br>
</font><font size=3 color=red>while (i > 0)</font><font size=3>
{<br>
right.image[j] = input.image[i--];<br>
left.image[j--] = input.image[i--];<br>
}<br>
<br>
left.copyImageIndependantAttributes(input);<br>
right.copyImageIndependantAttributes(input);<br>
<br>
}</font>
<br><font size=3>I guess running the loop while i == 0 is not what you
intended. In general I would stay away from bit shifting and these kind
of programming. It is horrible to maintain and is asking for trouble. I
would also not assume that your function is called with frames having the
right size. If you have wired problems like you described running the hole
component under valgrind helps most of the time<br>
</font><font size=3 color=red>-> Thanks. No bit shifting anymore. Checking
the size is redundant in my case as I create the left and right frames
in the update hook taking as parameter the size of the input frame. Should
I anyway check that the three frames have the same size in width and height
and data depth is half of the input frame in left and right frames? Would
you recommend this as a good practice in case other people want to use
this function outside of this component?</font>
<br><font size=3 color=red>About debugging, I have never used valgrind,
I am going to try that now, I usually use gdb in post execution but no
core file is generated by the process when terminating, strange.</font>
<br><font size=3><br>
Greets<br>
Alex<br>
<br>
</font><font size=3 color=red>Any more ideas about the questions below?</font>
<br><font size=3><br>
input_frame, frame_left and frame_right are ReadOnlyPointers of type Frame
defined in Task.hpp. Rest of the Hooks are empty/default.</font>
<br><font size=3><u><br>
Question</u>: Even thought this does the work for me, I would like to know
if this is a correct way of doing it. Mostly regarding the creation of
several Frame pointers and allocation of memory for those in the middle
of the updateHook? (This is actually important because it is related to
the question below)<br>
<br>
Now, I would like to send out both images left and right in a single port
using the structure FramePair, to make sure that they arrive together to
the stereo processing component with a single timestamp for both (as they
were both taken at the same time by a stereo camera). However, I have tried
to replicate the same logic using the FramePair structure and always got
errors in execution (compilation is ok).<br>
<br>
Changing the last part of the updateHook to the following:<br>
<br>
void Task::updateHook()<br>
{<br>
TaskBase::updateHook();<br>
<br>
if (_frame_in.read(input_frame)==RTT::NewData)<br>
{<br>
Frame* left = new Frame(input_frame->size.width, input_frame->size.height,
8, input_frame->frame_mode);<br>
Frame* right = new Frame(input_frame->size.width, input_frame->size.height,
8, input_frame->frame_mode);<br>
deInterlace(*input_frame,*left,*right);<br>
Frame* left_gray = new Frame(left->size.width, left->size.height,
8, MODE_GRAYSCALE);<br>
Frame* right_gray = new Frame(right->size.width,
right->size.height, 8, MODE_GRAYSCALE);<br>
frame_helper.convertColor(*left,*left_gray);<br>
frame_helper.convertColor(*right,*right_gray);<br>
FramePair* frame_pair;<br>
frame_pair->id=index_frame++; //! index_frame is
defined in Task.hpp and initialized to 0 in configureHook.<br>
frame_pair->time = input_frame->time;<br>
frame_pair->first = *left_gray;<br>
frame_pair->second = *right_gray;<br>
output_frame_pair.reset(frame_pair); //! output_frame_pair
is also a ReadOnlyPointer in Task.hpp<br>
_frame_out.write(output_frame_pair);<br>
}<br>
}<br>
<br>
gives me the following error when I run it: Orocos[WARN]: deployment <i>[myTaskContext]</i>
unexpectedly terminated with signal 11<br>
<br>
After trying several ways of assigning the frames's data to the frame_pair
structure without success I understood I was not using FramePair the right
way. So I tried something very simple as:<br>
<br>
void Task::updateHook()<br>
{<br>
TaskBase::updateHook(); <br>
<br>
if (_frame_in.read(input_frame)==RTT::NewData)<br>
{<br>
FramePair* frame_pair;<br>
frame_pair->time=input_frame->time;<br>
frame_pair->id=index_frame++;<br>
frame_pair->first.init(1024,768,8,MODE_GRAYSCALE);<br>
frame_pair->second.init(1024,768,8,MODE_GRAYSCALE);<br>
output_frame_pair.reset(frame_pair);<br>
_frame_out.write(output_frame_pair);<br>
}<br>
}<br>
<br>
And it gives the same error as above and actually the execution stops before
the end of the updateHook at the line where the first.init() function is
called.<br>
<br>
I make it even simpler:<br>
<br>
void Task::updateHook()<br>
{<br>
TaskBase::updateHook(); <br>
<br>
if (_frame_in.read(input_frame)==RTT::NewData)<br>
{<br>
FramePair* frame_pair;<br>
frame_pair->time=input_frame->time;<br>
frame_pair->id=index_frame++;<br>
output_frame_pair.reset(frame_pair);<br>
_frame_out.write(output_frame_pair);<br>
}<br>
}<br>
<br>
I get the same error when exiting the updateHook.<u><br>
<br>
Question:</u> What is it that I am missing about FramePair structure that
makes it so different to the Frame structure when it comes to memory allocation?
Somebody can put some light in this?<br>
<br>
Thank you very much for your attention,<br>
<br>
Martin<br>
</font>
<p><font size=3>Martin Azkarate </font>
<p><font size=3><b>ESA - European Space Agency</b><br>
Spanish Trainee, TEC-MMA - Automation and Robotics Section </font>
<p><font size=3><b>ESTEC - European Space research and TEchnology Centre</b><br>
Keplerlaan 1, PO Box 299 <br>
NL-2200 AG Noordwijk, The Netherlands </font><font size=3 color=blue><u><br>
</u></font><a href=mailto:Martin.Azkarate@esa.int><font size=3 color=blue><u>Martin.Azkarate@esa.int</u></font></a><font size=3>
| </font><a href=www.esa.int><font size=3>www.esa.int</font></a><font size=3>
<br>
Tel +31 71 565 3480 | Mob +31 650 625 564 </font>
<p><tt><font size=3>This message and any attachments are intended for the
use of the addressee or addressees only. The unauthorised disclosure, use,
dissemination or copying (either in whole or in part) of its content is
not permitted. If you received this message in error, please notify the
sender and delete it from your system. Emails can be altered and their
integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
</font></tt>
<br><font size=3><br>
</font>
<br><tt><font size=3>_______________________________________________<br>
Rock-dev mailing list<br>
</font></tt><a href="mailto:Rock-dev@dfki.de"><tt><font size=3 color=blue><u>Rock-dev@dfki.de</u></font></tt></a><tt><font size=3><br>
</font></tt><a href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev"><tt><font size=3 color=blue><u>http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</u></font></tt></a><tt><font size=3><br>
</font></tt>
<br><font size=3><br>
</font>
<br><tt><font size=3>-- <br>
Dipl.-Ing. Alexander Duda<br>
Unterwasserrobotik<br>
<br>
DFKI Bremen<br>
Robotics Innovation Center<br>
Robert-Hooke-Straße 5<br>
28359 Bremen, Germany<br>
<br>
Phone: +49 (0)421 178-456620<br>
Fax: +49 (0)421 178-454150<br>
E-Mail: </font></tt><a href=mailto:alexander.duda@dfki.de><tt><font size=3 color=blue><u>alexander.duda@dfki.de</u></font></tt></a><tt><font size=3><br>
<br>
Weitere Informationen: </font></tt><a href=http://www.dfki.de/robotik><tt><font size=3 color=blue><u>http://www.dfki.de/robotik</u></font></tt></a><tt><font size=3><br>
-----------------------------------------------------------------------<br>
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH<br>
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern<br>
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster<br>
(Vorsitzender) Dr. Walter Olthoff<br>
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes<br>
Amtsgericht Kaiserslautern, HRB 2313<br>
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)<br>
USt-Id.Nr.: DE 148646973<br>
Steuernummer: 19/673/0060/3<br>
</font></tt><tt><font size=2>_______________________________________________<br>
Rock-dev mailing list<br>
Rock-dev@dfki.de<br>
</font></tt><a href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev"><tt><font size=2>http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br><PRE>This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
</PRE>