I'm trying to write a Corba-based toolkit to get OpenCV IplImage's across the wire. We have an IplImageWrapper class that encapsulates both the IplImage header and the raw image data, which we use with data ports to move images around within an application. This works great, but now need to get the images across the wire.
I have been using the KDL corba toolkit as the primary example for the Corba-based toolkit, with reference to the RTT corba code as necessary, but still having some problems with the semantics of what is going on, and what is possible. Hence ...
# Do all types have to end up as a sequence< something > to enable easy conversion to type "Any"?
# If the above is true (or the most expeditious method), then how do we deal with what is in reality a sequence of short's (the IplImage data) _followed by_ a sequence of char's (the raw image data)? Converting everything to sequence
# Where are the structs defined within a .idl file actually used? For example, KDL::Corba::Frame (not KDL::Frame) appears to be unused as the C++ object (KDL::Frame) appears to be transformed directly to a sequence
# What prevents us slinging the KDL::Corba::Frame type directly across the wire? I seem to remember something about RTT depending on having everything convert back to the Any type ...?
Any help appreciated.
S
Corba transport semantics and limitations
On Thursday 04 December 2008 15:13:31 kiwi [dot] net [..] ... wrote:
> I'm trying to write a Corba-based toolkit to get OpenCV IplImage's across
> the wire. We have an IplImageWrapper class that encapsulates both the
> IplImage header and the raw image data, which we use with data ports to
> move images around within an application. This works great, but now need to
> get the images across the wire.
>
> I have been using the KDL corba toolkit as the primary example for the
> Corba-based toolkit, with reference to the RTT corba code as necessary, but
> still having some problems with the semantics of what is going on, and what
> is possible. Hence ...
>
> # Do all types have to end up as a sequence< something > to enable easy
> conversion to type "Any"?
No. Using a sequence is a short-cut. You can use any corba type, like
interface mydata { long x; double z; };
Generate code from that (using tao_idl), and use the Any conversions as
Sylvain pointed out.
> # If the above is true (or the most expeditious
> method), then how do we deal with what is in reality a sequence of short's
> (the IplImage data) _followed by_ a sequence of char's (the raw image
> data)? Converting everything to sequence is horribly inefficient.
So you don't need to.
> # Where
> are the structs defined within a .idl file actually used? For example,
> KDL::Corba::Frame (not KDL::Frame) appears to be unused as the C++ object
> (KDL::Frame) appears to be transformed directly to a sequence. What am I
> missing here?
It looks like 'junk' to me. Unused, but it does allow the alternative
implementation.
> # What prevents us slinging the KDL::Corba::Frame type
> directly across the wire? I seem to remember something about RTT depending
> on having everything convert back to the Any type ...?
I guess it was for efficiency/ease of coding reasons at the C++ side. It does
make this far less usable for external tools or languages. I would prefer to
have used the structs in order to more easily use the IDL interface (which is
already very cumbersome...)
Peter
Corba transport semantics and limitations
On Dec 5, 2008, at 02:24 , Peter Soetens wrote:
> On Thursday 04 December 2008 15:13:31 kiwi [dot] net [..] ... wrote:
>> I'm trying to write a Corba-based toolkit to get OpenCV IplImage's
>> across
>> the wire. We have an IplImageWrapper class that encapsulates both the
>> IplImage header and the raw image data, which we use with data
>> ports to
>> move images around within an application. This works great, but now
>> need to
>> get the images across the wire.
>>
>> I have been using the KDL corba toolkit as the primary example for
>> the
>> Corba-based toolkit, with reference to the RTT corba code as
>> necessary, but
>> still having some problems with the semantics of what is going on,
>> and what
>> is possible. Hence ...
>>
>> # Do all types have to end up as a sequence< something > to enable
>> easy
>> conversion to type "Any"?
>
> No. Using a sequence is a short-cut. You can use any corba type, like
> interface mydata { long x; double z; };
> Generate code from that (using tao_idl), and use the Any conversions
> as
> Sylvain pointed out.
So we still have to go C++ struct -> Corba struct -> Corba Any? Unless
we use Sylvain's efficient, but decidely unsafe, conversion from C++
struct -> Corba byte ...
>> # Where
>> are the structs defined within a .idl file actually used? For
>> example,
>> KDL::Corba::Frame (not KDL::Frame) appears to be unused as the C++
>> object
>> (KDL::Frame) appears to be transformed directly to a sequence. What
>> am I
>> missing here?
>
> It looks like 'junk' to me. Unused, but it does allow the alternative
> implementation.
>
>> # What prevents us slinging the KDL::Corba::Frame type
>> directly across the wire? I seem to remember something about RTT
>> depending
>> on having everything convert back to the Any type ...?
>
> I guess it was for efficiency/ease of coding reasons at the C++
> side. It does
> make this far less usable for external tools or languages. I would
> prefer to
> have used the structs in order to more easily use the IDL interface
> (which is
> already very cumbersome...)
Understood. Well I guess we'll see how this approach works out
shortly ...
S
Corba transport semantics and limitations
> > No. Using a sequence is a short-cut. You can use any corba type, like
> > interface mydata { long x; double z; };
> > Generate code from that (using tao_idl), and use the Any conversions
> > as
> > Sylvain pointed out.
>
> So we still have to go C++ struct -> Corba struct -> Corba Any? Unless
> we use Sylvain's efficient, but decidely unsafe, conversion from C++
> struct -> Corba byte ...
Actually, I would strongly *suggest* to put the pixel data as sequence. (I already saw that done, that's why I mention it)
Do not even think about defining a pixel type in IDL and convert the pixel data
as sequence
Sylvain
Corba transport semantics and limitations
On Dec 5, 2008, at 08:23 , Sylvain Joyeux wrote:
>>> No. Using a sequence is a short-cut. You can use any corba type,. (I already saw that done, that's why I mention it)
>>> like
>>> interface mydata { long x; double z; };
>>> Generate code from that (using tao_idl), and use the Any conversions
>>> as
>>> Sylvain pointed out.
>>
>> So we still have to go C++ struct -> Corba struct -> Corba Any?
>> Unless
>> we use Sylvain's efficient, but decidely unsafe, conversion from C++
>> struct -> Corba byte ...
>
> Actually, I would strongly *suggest* to put the pixel data as
> sequence
> Do not even think about defining a pixel type in IDL and convert the
> pixel data
> as sequence
Got it. Actually, the sequence approach never even crossed my
mind - why transfer to something else when we already deal in bytes?!?
The version I'm using right now is just transferring a fixed size when I get this
array of char, but I will change to sequence
working and move on to variable sized images.
Thanks!
S
Corba transport semantics and limitations
Orocos simply needs you to convert to Any, and Corba IDL compilers generate
the necessary code for you ... so what you need to do is:
* convert the IplImage to a Corba::Image type that you define in IDL
* do
Any* val = new Any();
*val <<= corba_image;
return val;
Same thing on the reading side:
Corba::Image* img;
*any >>= img;
// convert back to IplImage
delete img;
Note something: this is probably horribly slow.
One thing you can do -- which is totally unsafe and non-recommended, but in
nonetheless ;-) -- is to marshal the IplImage directly as sequence
IDL and do a memcpy or equivalent. TAO, and I expect that omniORB has the
same, have special "pass-through" features for sequence of bytes that make
them much faster (but type-less, so prone to problems).