merging SIP and SIVP - an idea
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
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 |
|
|
Re: merging SIP and SIVP - an idea
by vitors
::
Rate this Message:
Hello Fabbri and all SIP and SIVP developers,
I was wondering if could help you with the transition step you mentioned. When you said about "configure", which tool where you talking about? Let me explain: I joined for two years a software project and one of my tasks was to move from GNU autotools to CMake. The idea was to use the same set of scripts to be able to build our software (library, unit tests, documentation, GUI, etc.) on both Linux and Windows environments. My experience says that CMake is simply excellent doing this job. The biggest problem now is to manage my time because I just moved from team (and city) and I'll be quite busy for the next two months. However, once things get more organized and clear at the office, I can say how much time I would have to work on SIP install scripting. Please, let me know what you think about this idea. Vitor p.s.: For those who don't know CMake: http://www.cmake.org > 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 > ------------------------------------------------------------------------------ _______________________________________________ SIPtoolbox-devel mailing list SIPtoolbox-devel@... https://lists.sourceforge.net/lists/listinfo/siptoolbox-devel |
|
|
Re: merging SIP and SIVP - an idea
by Cheng Zhang-4
::
Rate this Message:
Hi Vitor,
FYI. I had already used CMake in SIP Windows port in 2005. I definitely support your idea of adopting CMake in SIP's build process. It's a great tool. Cheng On Mon, Mar 30, 2009 at 9:51 AM, <vitors@...> wrote: Hello Fabbri and all SIP and SIVP developers, -- Cheng Zhang PhD Candidate The Department of Electrical and Computer Engineering The University of Iowa, USA ------------------------------------------------------------------------------ _______________________________________________ SIPtoolbox-devel mailing list SIPtoolbox-devel@... https://lists.sourceforge.net/lists/listinfo/siptoolbox-devel |
|
|
Re: merging SIP and SIVP - an idea
by Ricardo Fabbri-3
::
Rate this Message:
Hi Vitor & Cheng,
CMake is great, there are many reasons I'd like to see it used: - I also have been using it extensively with the VXL computer vision libraries, which could very well be used as one of the basis for new SIP functions in the future. I actually already build some interface functions between vxl and matlab using CMake, and that should give a good idea on how to do the same for SIP/Scilab. - KDE migrated to use CMake, and so many other huge libraries use it, so it is a ubiquitous and standard tool. - My lab has connections with people in Kitware - Most importantly, we want to be able to support many OS. Right now the Autoconf/Automake tools work very well only for Linux. So I hope this idea can be pushed forward with concrete and realistic results. While the CMake port is being done, nothing prevents us from trying to start merging SIP and SIVP with the current build system and get it to work well in Linux first. That will get most conflicts and merges between the two out of the way. 2009/3/30 Cheng Zhang <chengzha@...>: > Hi Vitor, > > FYI. I had already used CMake in SIP Windows port in 2005. I definitely > support your idea of adopting CMake in SIP's build process. It's a great > tool. > > Cheng > > On Mon, Mar 30, 2009 at 9:51 AM, <vitors@...> wrote: >> >> Hello Fabbri and all SIP and SIVP developers, >> >> I was wondering if could help you with the transition step you >> mentioned. When you said about "configure", which tool where you >> talking about? Let me explain: I joined for two years a software >> project and one of my tasks was to move from GNU autotools to CMake. >> The idea was to use the same set of scripts to be able to build our >> software (library, unit tests, documentation, GUI, etc.) on both Linux >> and Windows environments. >> My experience says that CMake is simply excellent doing this job. >> >> The biggest problem now is to manage my time because I just moved from >> team (and city) and I'll be quite busy for the next two months. >> However, once things get more organized and clear at the office, I can >> say how much time I would have to work on SIP install scripting. >> >> Please, let me know what you think about this idea. >> >> Vitor >> >> p.s.: For those who don't know CMake: http://www.cmake.org >> > 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 >> > >> >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> SIPtoolbox-devel mailing list >> SIPtoolbox-devel@... >> https://lists.sourceforge.net/lists/listinfo/siptoolbox-devel > > > > -- > Cheng Zhang > > PhD Candidate > The Department of Electrical and Computer Engineering > The University of Iowa, USA > > ------------------------------------------------------------------------------ > > _______________________________________________ > SIPtoolbox-devel mailing list > SIPtoolbox-devel@... > https://lists.sourceforge.net/lists/listinfo/siptoolbox-devel > > ------------------------------------------------------------------------------ _______________________________________________ SIPtoolbox-devel mailing list SIPtoolbox-devel@... https://lists.sourceforge.net/lists/listinfo/siptoolbox-devel |
| Free embeddable forum powered by Nabble | Forum Help |
