« Return to Thread: merging SIP and SIVP - an idea
merging SIP and SIVP - an idea
by Ricardo Fabbri-3
::
Rate this Message:
Hi Shiqi,
long time no see!
As a follow-up to our usual idea of merging SIP and SIVP, I had an
idea about supporting both OpenCV and ImageMagick. Here is a plan of
how this can be feasible:
The end-goal would be a toolbox that optionally compiles the functions that use
opencv, or the functions that use imagemagick, or both, depending on
flags passed to the
configure script. For the functions that overlap, we can start by providing both
implementations, the configure script will default to the best
option. For example, imread can be implemented by ImageMagick by
default, but if we choose not to use
imagemagick, then an imread by opencv would be used. Of course, if it
turns out that there is no advantage in keeping two implementations
around, in the future we can
remove one of them.
We can start with a transition plan. The short term goal would be to start
providing such a "configure" script in SIP, which can take both opencv and
imagemagick, or just one of them. By default, for now, SIP would compile to the
normal SIP without opencv, but if you pass a flag such as "--full-build" then it
would try to compile all possible functions (the union of SIP and SIVP).
Once that is done, SIVP could also have a transitional version that would be
identical to the above package, but whose configure script would default to
build the usual OpenCV-based SIVP, without imagemagick.
That is a lot of work, but all the effort would be towards trying to bring
SIP and SIVP into agreement where they overlap, and complementing each other
where they don't overlap. For instance, the transitional "SIP" would have to
move towards supporting integer formats.
I think I can try to start the transitional merge by incorporating SIVP features
back into SIP and activating opencv as an optional step.
We can always keep it simple by providing the SIP and SIVP-style packages
around.
Let me know what you think.
Thanks.
> Hi Shiqi,
>
> I am sorry I didn't reply to your email before, I have been extremely
> busy with my PhD load, but hopefully I will gradually get back to SIP
> and Scilab.
> It is a really good idea to merge SIP and SIVP. The main difference
> right now seems to be that SIP uses ImageMagick. I think OpenCV cannot
> handle as many image formats, right? Imagemagick handles virtually 100
> formats. It would be nice to support both, but maybe it would be to
> hard to maintain everything into a single toolbox. If we work
> together, it might be feasible, though. I was also thinking about
> interfacing http://vxl.sourceforge.net
> but that is more for a long-term project.
>
> Anyways, great job with SIVP. You can continue to use SIP code as you wish.
>
> Let me know what are your ideas,
>
>
>>
>>
>> I noticed you have put a notice on SIP homepage. It's a googd news for
>> all SIP users. ^-^
>
>> Now SIVP is still in developing. I have ported some macros such as
>> imnoise, edge, etc from SIP to SIVP. Compared with SIP, the advantages
>> of SIVP are integer image support(UINT8, INT8, ..., INT32) and some fast
>> functions which using OpenCV (such as canny in SIVP edge function). The
>> disadvantage is that the functions are still not enough. The SIVP
>> function prototypes is the same as Matlab Image Processing toolbox.
>>
>> You will be back to SIP next month. I wonder if it's a chance to merge
>> SIP and SIVP to one toolbox.
>>
>> Shiqi
>>
>>
------------------------------------------------------------------------------
_______________________________________________
SIPtoolbox-devel mailing list
SIPtoolbox-devel@...
https://lists.sourceforge.net/lists/listinfo/siptoolbox-devel
long time no see!
As a follow-up to our usual idea of merging SIP and SIVP, I had an
idea about supporting both OpenCV and ImageMagick. Here is a plan of
how this can be feasible:
The end-goal would be a toolbox that optionally compiles the functions that use
opencv, or the functions that use imagemagick, or both, depending on
flags passed to the
configure script. For the functions that overlap, we can start by providing both
implementations, the configure script will default to the best
option. For example, imread can be implemented by ImageMagick by
default, but if we choose not to use
imagemagick, then an imread by opencv would be used. Of course, if it
turns out that there is no advantage in keeping two implementations
around, in the future we can
remove one of them.
We can start with a transition plan. The short term goal would be to start
providing such a "configure" script in SIP, which can take both opencv and
imagemagick, or just one of them. By default, for now, SIP would compile to the
normal SIP without opencv, but if you pass a flag such as "--full-build" then it
would try to compile all possible functions (the union of SIP and SIVP).
Once that is done, SIVP could also have a transitional version that would be
identical to the above package, but whose configure script would default to
build the usual OpenCV-based SIVP, without imagemagick.
That is a lot of work, but all the effort would be towards trying to bring
SIP and SIVP into agreement where they overlap, and complementing each other
where they don't overlap. For instance, the transitional "SIP" would have to
move towards supporting integer formats.
I think I can try to start the transitional merge by incorporating SIVP features
back into SIP and activating opencv as an optional step.
We can always keep it simple by providing the SIP and SIVP-style packages
around.
Let me know what you think.
Thanks.
> Hi Shiqi,
>
> I am sorry I didn't reply to your email before, I have been extremely
> busy with my PhD load, but hopefully I will gradually get back to SIP
> and Scilab.
> It is a really good idea to merge SIP and SIVP. The main difference
> right now seems to be that SIP uses ImageMagick. I think OpenCV cannot
> handle as many image formats, right? Imagemagick handles virtually 100
> formats. It would be nice to support both, but maybe it would be to
> hard to maintain everything into a single toolbox. If we work
> together, it might be feasible, though. I was also thinking about
> interfacing http://vxl.sourceforge.net
> but that is more for a long-term project.
>
> Anyways, great job with SIVP. You can continue to use SIP code as you wish.
>
> Let me know what are your ideas,
>
>
>>
>>
>> I noticed you have put a notice on SIP homepage. It's a googd news for
>> all SIP users. ^-^
>
>> Now SIVP is still in developing. I have ported some macros such as
>> imnoise, edge, etc from SIP to SIVP. Compared with SIP, the advantages
>> of SIVP are integer image support(UINT8, INT8, ..., INT32) and some fast
>> functions which using OpenCV (such as canny in SIVP edge function). The
>> disadvantage is that the functions are still not enough. The SIVP
>> function prototypes is the same as Matlab Image Processing toolbox.
>>
>> You will be back to SIP next month. I wonder if it's a chance to merge
>> SIP and SIVP to one toolbox.
>>
>> Shiqi
>>
>>
------------------------------------------------------------------------------
_______________________________________________
SIPtoolbox-devel mailing list
SIPtoolbox-devel@...
https://lists.sourceforge.net/lists/listinfo/siptoolbox-devel
« Return to Thread: merging SIP and SIVP - an idea
| Free embeddable forum powered by Nabble | Forum Help |
