[Rock-dev] using FramePair structure to output two frames together
Martin.Azkarate at esa.int
Martin.Azkarate at esa.int
Sun Jul 14 17:54:44 CEST 2013
Answer below in red. Sorry but the indexing method does not work in my
email.
From: Alexander Duda <Alexander.Duda at dfki.de>
To: Martin.Azkarate at esa.int
Cc: rock-dev at dfki.de
Date: 12/07/2013 17:50
Subject: Re: [Rock-dev] using FramePair structure to output two
frames together
Sent by: rock-dev-bounces at dfki.de
On 07/12/2013 05:14 PM, Martin.Azkarate at esa.int wrote:
Hello,
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:
void Task::updateHook()
{
TaskBase::updateHook();
if (_frame_in.read(input_frame)==RTT::NewData)
{
Frame* left = new Frame(input_frame->size.width,
input_frame->size.height, 8, input_frame->frame_mode);
Frame* right = new Frame(input_frame->size.width,
input_frame->size.height, 8, input_frame->frame_mode);
deInterlace(*input_frame,*left,*right);
Frame* left_gray = new Frame(left->size.width, left->size.height, 8,
MODE_GRAYSCALE);
Frame* right_gray = new Frame(right->size.width, right->size.height,
8, MODE_GRAYSCALE);
frame_helper.convertColor(*left,*left_gray);
frame_helper.convertColor(*right,*right_gray);
frame_left.reset(left_gray);
frame_right.reset(right_gray);
_frame_left.write(frame_left);
_frame_right.write(frame_right);
}
}
why do you convert the colour insight the component? Is not the component
supposed to just split the frame?
-> 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).
void Task::deInterlace(const base::samples::frame::Frame &input,
base::samples::frame::Frame &left, base::samples::frame::Frame &right)
{
//! 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.
//! So in "one pixel" of 16bits of the input frame there are "two
pixels" of 8bits one of each left and right frames.
uint32_t width=input.size.width;
uint32_t height=input.size.height;
uint32_t i = (width*height*2)-1;
uint32_t j = (width*height)-1;
while (i > 0) {
right.image[j] = input.image[i--];
left.image[j--] = input.image[i--];
}
left.copyImageIndependantAttributes(input);
right.copyImageIndependantAttributes(input);
}
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
-> 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?
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.
Greets
Alex
Any more ideas about the questions below?
input_frame, frame_left and frame_right are ReadOnlyPointers of type Frame
defined in Task.hpp. Rest of the Hooks are empty/default.
Question: 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)
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).
Changing the last part of the updateHook to the following:
void Task::updateHook()
{
TaskBase::updateHook();
if (_frame_in.read(input_frame)==RTT::NewData)
{
Frame* left = new Frame(input_frame->size.width,
input_frame->size.height, 8, input_frame->frame_mode);
Frame* right = new Frame(input_frame->size.width,
input_frame->size.height, 8, input_frame->frame_mode);
deInterlace(*input_frame,*left,*right);
Frame* left_gray = new Frame(left->size.width, left->size.height, 8,
MODE_GRAYSCALE);
Frame* right_gray = new Frame(right->size.width, right->size.height,
8, MODE_GRAYSCALE);
frame_helper.convertColor(*left,*left_gray);
frame_helper.convertColor(*right,*right_gray);
FramePair* frame_pair;
frame_pair->id=index_frame++; //! index_frame is defined in Task.hpp
and initialized to 0 in configureHook.
frame_pair->time = input_frame->time;
frame_pair->first = *left_gray;
frame_pair->second = *right_gray;
output_frame_pair.reset(frame_pair); //! output_frame_pair is also a
ReadOnlyPointer in Task.hpp
_frame_out.write(output_frame_pair);
}
}
gives me the following error when I run it: Orocos[WARN]: deployment
[myTaskContext] unexpectedly terminated with signal 11
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:
void Task::updateHook()
{
TaskBase::updateHook();
if (_frame_in.read(input_frame)==RTT::NewData)
{
FramePair* frame_pair;
frame_pair->time=input_frame->time;
frame_pair->id=index_frame++;
frame_pair->first.init(1024,768,8,MODE_GRAYSCALE);
frame_pair->second.init(1024,768,8,MODE_GRAYSCALE);
output_frame_pair.reset(frame_pair);
_frame_out.write(output_frame_pair);
}
}
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.
I make it even simpler:
void Task::updateHook()
{
TaskBase::updateHook();
if (_frame_in.read(input_frame)==RTT::NewData)
{
FramePair* frame_pair;
frame_pair->time=input_frame->time;
frame_pair->id=index_frame++;
output_frame_pair.reset(frame_pair);
_frame_out.write(output_frame_pair);
}
}
I get the same error when exiting the updateHook.
Question: 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?
Thank you very much for your attention,
Martin
Martin Azkarate
ESA - European Space Agency
Spanish Trainee, TEC-MMA - Automation and Robotics Section
ESTEC - European Space research and TEchnology Centre
Keplerlaan 1, PO Box 299
NL-2200 AG Noordwijk, The Netherlands
Martin.Azkarate at esa.int | www.esa.int
Tel +31 71 565 3480 | Mob +31 650 625 564
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.
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-456620
Fax: +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20130714/8053f4a1/attachment-0001.htm
More information about the Rock-dev
mailing list