[Rock-dev] using FramePair structure to output two frames together

Martin.Azkarate at esa.int Martin.Azkarate at esa.int
Fri Jul 12 17:14:34 CEST 2013


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);
    }
}

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);

}

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20130712/0bb4d136/attachment.htm 


More information about the Rock-dev mailing list