[Rock-dev] using FramePair structure to output two frames together
Alexander Duda
Alexander.Duda at dfki.de
Fri Jul 12 17:49:17 CEST 2013
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?
>
> 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*2);
> uint32_t height=input.size.height;
>
> int i = (width*height)-1;
> int j = ((width*height)>>1)-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
Greets
Alex
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20130712/2ba5b265/attachment-0001.htm
More information about the Rock-dev
mailing list