vxl-maintainers Mailing List for The VXL Project

VXL maintainers,

It has been a long time since we've tagged a versioned release of VXL.  It
looks like it's been about 6 years since VXL 1.17.0.  Does anyone object if
someone at Kitware tags a new release of the master branch at 1.18.0?  I
don't remember what the release procedure is and we haven't done one since
moving to Github, so the procedure is probably out of date.  Is there
anything that we should do besides ensuring that the commit we tag builds
and work across platforms?

VXL is no longer as active as it once was, but I know there are several
groups still using it.  The project appears to be mostly in maintenance
mode now with most changes (at least in core) focused on keeping the code
base working with more modern compilers and build systems.  That said, we
still need stable releases every once in a while, even if they are
primarily to maintain compatibility as compilers evolve.  In our case, we
have some customers that require that we report which versions of open
source projects we are using.  We'd rather have a meaningful version number
to report instead of something very outdated.

Let me know if there are any concerns about tagging a release.  If we don't
hear any objections we will probably just make the tag.

Thanks,
Matt

Dear All,
The documentation build no longer works on my local systems.
In theory one just sets BUILD_DOCUMENTATION:BOOL=ON in the CMakeCache.txt,
then calls "make build_doxygen_doc"

However, this no longer works - it seems that various variables (e.g. PROJECT_BINARY_DIR) are not set up properly.

Has anyone else had this problem? Or is there a different way of building the doc. now?

Tim

Tim Cootes,  Professor of Computer Vision
Centre for Imaging Sciences,  Faculty of Biology Medicine and Health,
The University of Manchester, Manchester M13 9PT, UK
Tel:   (+44) 0161 275 5146
http://personalpages.manchester.ac.uk/staff/timothy.f.cootes/

Hi Peter,

VDL is indeed more consistent with VXL naming.
In fact, VDL could be thought as a folder under VXL, ie,  vxl/contrib/vdl,
but managed in a separate repository and recursively having similar
structure as VXL.
Under vxl/contrib, we have BRL, GEL, etc. So 'VDL' would fit right in.

One rationale for VXD is that we would be appending a '*d' to every library
under development, like bnld, vgld, vsold, etc. In that sense, then, it is
v*d.

If we switch to VDL, technically every development library should be like
vgl -> vgdl or vdgl. But that gets confusing. I'm thinking about just
appending a d anyways, even if we use VDL.

I'm not sure yet if we should switch to VDL, but it is a good name. What do
you think?

--
Dr Ricardo Fabbri
Professor of Computer Engineering
GNU/Linux registered user #175401
pt.wikipedia.org/wiki/IPRJ
labmacambira.sf.net
rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>

On Thu, Oct 27, 2016 at 2:35 PM, Peter Vanroose <pet...@ya...>
wrote:

> Shouldn't that be "VDL", then?
> "Vision Development Libraries"
> As opposed to / next to: VGL (geometry), VNL (numerics), VIL (imaging),
> etc.
> It's the "X" which is the wildcard ...
>
> -- Peter. --
>
>
> Den fredag, 21 oktober 2016 22:29 skrev "Wheeler, Frederick W (GE Global
> Research, US)" <wh...@ge...>:
>
>
>
> Perhaps “VXD”?  VXL is meant to mean Vision Something Libraries.  VXD
> could mean Vision Something Development.
>
> Fred
>
> *From:* Ricardo Fabbri [mailto:rf...@gm...]
> *Sent:* Friday, October 21, 2016 2:49 PM
> *To:* Matt Leotta <mat...@ki...>
> *Cc:* Vxl-maintainers <vxl...@li...>; Anil
> Usumezbas <ani...@gm...>
> *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project
>
> Hi Matt,
>
> I was thinking about "a collection of code that builds against VXL but
> doesn't contain VXL".
> Another name would be dvxl or DVXL for Development VXL. Does that dound
> less odd?
> I am open for other names. I should be uploading the code very soon, in
> the coming days.
>
> Thanks,
>
>
> --
> Dr Ricardo Fabbri
> Professor of Computer Engineering
> GNU/Linux registered user #175401
> pt.wikipedia.org/wiki/IPRJ
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=>
> labmacambira.sf.net
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=>
> rfabbri.github.io
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=>
>
> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...>
> wrote:
>
> Ricardo,
>
> You are free to do what you like with your own code base that builds on
> VXL.  I think it's great to be sharing more code based on VXL and I'm
> especially interested in seeing more 3D stereo code.  Your curve
> reconstruction work is great, and it would be nice to have to more openly
> accessible.
>
> I'm a little confused about what you are proposing here.  Maybe it's just
> the name that is throwing me off.  Are you talking about a fork of VXL that
> contains all of VXL plus additional contributions?  Or are you talking
> about a collection of code that builds against VXL but doesn't contain
> VXL?  If it's the former I suggest you just make a fork on Github (either
> under your own account, or under a group for your lab) and just call it
> VXL.  It would just be github.com/rfabbri/vxl
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>.
> Actually, It looks like you've already done that.  Then you can easily push
> and pull branches to and from the mainline VXL as needed.  If you are
> talking about a repository that is just your research code that builds
> against VXL, that is fine too, but the name "Bigvxl" seems a little odd for
> that.
>
> --Matt
>
> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...>
> wrote:
>
> Hi,
> I am planing to release a considerable amount of research code on 3D
> stereo based on vxl, as a new repository. We all want to keep vxl lean, so
> I am planning to call the new project bigvxl. Do you agree? Is the name too
> close to vxl?
> The idea is to release large (and possibly klunky) computer vision systems
> in bigvxl, which can slowly mature to one day make it into vxl or even
> core. Some "big" code by nature don't even have to ever make it to vxl
> strict standards or granularity, but can still be very useful.
> The idea came up because most research and industry labs having internal
> code that use vxl do not have an intermediate, common and more laidback
> open source step prior to pushing code to lean vxl. So I am proposing to
> help maintain a common bigvxl repository that can be seen as closely
> coordinated with vxl and that can keep up (at least partially) with vxl
> changes and be built on official dashboards. I also plan to stratify bigvxl
> into core, development libraries, contrib, and so on. At least the bigvxl
> team (myself and a couple of students for now) should keep bigvxl's basic
> libraries conforming to the latest vxl at all times. Bigvxl woud be easier
> to change and less strict (thus messier) than vxl.
> Any thoughts? I plan to publish an initial bigvxl based on publishable
> Brown University code in the coming days.
> Best,
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=>
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=>
>
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>
>

Shouldn't that be "VDL", then?
"Vision Development Libraries"As opposed to / next to: VGL (geometry), VNL (numerics), VIL (imaging), etc.It's the "X" which is the wildcard ...
 -- Peter. -- 

    Den fredag, 21 oktober 2016 22:29 skrev "Wheeler, Frederick W (GE Global Research, US)" <wh...@ge...>:
 

 #yiv3005058133 #yiv3005058133 -- _filtered #yiv3005058133 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv3005058133 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv3005058133 #yiv3005058133 p.yiv3005058133MsoNormal, #yiv3005058133 li.yiv3005058133MsoNormal, #yiv3005058133 div.yiv3005058133MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv3005058133 a:link, #yiv3005058133 span.yiv3005058133MsoHyperlink {color:blue;text-decoration:underline;}#yiv3005058133 a:visited, #yiv3005058133 span.yiv3005058133MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv3005058133 p {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv3005058133 p.yiv3005058133msonormal0, #yiv3005058133 li.yiv3005058133msonormal0, #yiv3005058133 div.yiv3005058133msonormal0 {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv3005058133 span.yiv3005058133EmailStyle19 {color:windowtext;}#yiv3005058133 .yiv3005058133MsoChpDefault {} _filtered #yiv3005058133 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv3005058133 div.yiv3005058133WordSection1 {}#yiv3005058133    Perhaps “VXD”?  VXL is meant to mean Vision Something Libraries.  VXD could mean Vision Something Development.    Fred    From: Ricardo Fabbri [mailto:rf...@gm...]
Sent: Friday, October 21, 2016 2:49 PM
To: Matt Leotta <mat...@ki...>
Cc: Vxl-maintainers <vxl...@li...>; Anil Usumezbas <ani...@gm...>
Subject: EXT: Re: [Vxl-maintainers] bigvxl : a new project    Hi Matt,    I was thinking about "a collection of code that builds against VXL but doesn't contain VXL". Another name would be dvxl or DVXL for Development VXL. Does that dound less odd? I am open for other names. I should be uploading the code very soon, in the coming days.    Thanks, 
 
--
Dr Ricardo Fabbri
Professor of Computer Engineering
GNU/Linux registered user #175401
pt.wikipedia.org/wiki/IPRJ
labmacambira.sf.net rfabbri.github.io    On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> wrote: 
Ricardo,    You are free to do what you like with your own code base that builds on VXL.  I think it's great to be sharing more code based on VXL and I'm especially interested in seeing more 3D stereo code.  Your curve reconstruction work is great, and it would be nice to have to more openly accessible.    I'm a little confused about what you are proposing here.  Maybe it's just the name that is throwing me off.  Are you talking about a fork of VXL that contains all of VXL plus additional contributions?  Or are you talking about a collection of code that builds against VXL but doesn't contain VXL?  If it's the former I suggest you just make a fork on Github (either under your own account, or under a group for your lab) and just call it VXL.  It would just be github.com/rfabbri/vxl.  Actually, It looks like you've already done that.  Then you can easily push and pull branches to and from the mainline VXL as needed.  If you are talking about a repository that is just your research code that builds against VXL, that is fine too, but the name "Bigvxl" seems a little odd for that.    --Matt     On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> wrote: 
Hi, I am planing to release a considerable amount of research code on 3D  stereo based on vxl, as a new repository. We all want to keep vxl lean, so I am planning to call the new project bigvxl. Do you agree? Is the name too close to vxl? The idea is to release large (and possibly klunky) computer vision systems in bigvxl, which can slowly mature to one day make it into vxl or even core. Some "big" code by nature don't even have to ever make it to vxl strict standards or granularity, but can still be very useful. The idea came up because most research and industry labs having internal code that use vxl do not have an intermediate, common and more laidback open source step prior to pushing code to lean vxl. So I am proposing to help maintain a common bigvxl repository that can be seen as closely coordinated with vxl and that can keep up (at least partially) with vxl changes and be built on official dashboards. I also plan to stratify bigvxl into core, development libraries, contrib, and so on. At least the bigvxl team (myself and a couple of students for now) should keep bigvxl's basic libraries conforming to the latest vxl at all times. Bigvxl woud be easier to change and less strict (thus messier) than vxl. Any thoughts? I plan to publish an initial bigvxl based on publishable Brown University code in the coming days. Best,    ------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Vxl-maintainers mailing list
Vxl...@li...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers 
   
   
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Vxl-maintainers mailing list
Vxl...@li...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers


   

Hi,

I have done some initial work starting up VXD, a development library based
on VXL to host less mature code.

I've placed it in https://github.com/rfabbri/vxd for now

There is nothing there right now, except for some obsolete libraries from
VXL that are needed by other code that will follow.

While preparing to upload large systems, I've been worried about the
workflow around VXL, VXD and Internal library collections. During my time
at Brown, I've noticed that there are many problems maintaining multiple
repositories, requiring a high level of discipline, making VXL less popular
than it deserves. I'm worried that teams will push code to VXD but will
keep only using the internal repositories.

Folks in my collab team at Brown have a tendency to think of VXL+Git
programming of large systems as something that could be less prone to mess,
and I am tryting to come up with and document a good solution in VXD's
documentation. Above all, I don't want to create more mess!

In the README, which is very preliminary right now, I have written freely
about my thoughts regarding workflows and maintenance of VXL-related code.
This a lot of writing and I haven't had time to polish it much, but if
someone finds the time to pitch in with some ideas, it would be of great
help.

Thanks,
--
Dr Ricardo Fabbri
Professor of Computer Engineering
GNU/Linux registered user #175401
pt.wikipedia.org/wiki/IPRJ
labmacambira.sf.net
rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>

Would VXL be a compile-time dependency of VXD?

Also, where would the other directories that are currently in vxl/contrib
(besides contrib/bbas/bnl) go, VXD? Or would you decide on a case-by-case
basis?

thanks
Scott

On Sat, Oct 22, 2016 at 7:12 PM, Ricardo Fabbri <rf...@gm...> wrote:

> Here's what I'm doing for the individual library naming.
>
> A typical setup will have three VXL codebases:  VXL, VXD and an internal
> version (eg, LEMSVXL at Brown).
>
> In VXL, we have things like vgl, vnl etc.  in VXL/contrib/brl/bbas there
> are things such as bnl for contributions to vnl.
> The internal / closed-source version of bnl is called dbnl in LEMSVXL.
>
> In VXD we should have something in between for, say, vnl development
> changes that are open-sourced. Since the internal libs at Brown already
> prepend a 'd', as in 'dbnl', I was thinking that VXD should instead
> *append* a 'd', like 'bnld'.
>
> So the process of placing code would be threefold:
>
> 1) VXL: core/vnl and contrib/bbas/bnl for stable additions from Brown
> 2) VXD: basic/bnld for less stable additions from Brown, open sourced
> 3) Closed-sourced code improving bnl (as in LEMSVXL): basic/dbnl
>
> This naming convention is important as we want to keep many versions of
> the same library around, one in VXL, one in VXD and another one inside the
> lab. Is this too confusing? It will take some work to do this, so please
> let me know.
>
> Thanks,
>
>
> --
> Dr Ricardo Fabbri
> Professor of Computer Engineering
> GNU/Linux registered user #175401
> pt.wikipedia.org/wiki/IPRJ
> labmacambira.sf.net
> rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>
>
> On Sat, Oct 22, 2016 at 8:28 PM, Ricardo Fabbri <rf...@gm...> wrote:
>
>> I'm going with Fred's suggestion, vxd.
>>
>> dvxl is consistent with the name given to development libraries that will
>> be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more
>> direct reference to vxl. However, it is too similar to vxl, and is one
>> letter longer than vxd.
>>
>> I'll be uploading code now. Please, please stop me if you prefer dvxl
>> instead :)
>>
>>
>>
>> --
>> Dr Ricardo Fabbri
>> Professor of Computer Engineering
>> GNU/Linux registered user #175401
>> pt.wikipedia.org/wiki/IPRJ
>> labmacambira.sf.net
>> rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>
>>
>> On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global
>> Research, US) <wh...@ge...> wrote:
>>
>>>
>>>
>>> Perhaps “VXD”?  VXL is meant to mean Vision Something Libraries.  VXD
>>> could mean Vision Something Development.
>>>
>>>
>>>
>>> Fred
>>>
>>>
>>>
>>> *From:* Ricardo Fabbri [mailto:rf...@gm...]
>>> *Sent:* Friday, October 21, 2016 2:49 PM
>>> *To:* Matt Leotta <mat...@ki...>
>>> *Cc:* Vxl-maintainers <vxl...@li...>; Anil
>>> Usumezbas <ani...@gm...>
>>> *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project
>>>
>>>
>>>
>>> Hi Matt,
>>>
>>>
>>>
>>> I was thinking about "a collection of code that builds against VXL but
>>> doesn't contain VXL".
>>>
>>> Another name would be dvxl or DVXL for Development VXL. Does that dound
>>> less odd?
>>>
>>> I am open for other names. I should be uploading the code very soon, in
>>> the coming days.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> --
>>> Dr Ricardo Fabbri
>>> Professor of Computer Engineering
>>> GNU/Linux registered user #175401
>>> pt.wikipedia.org/wiki/IPRJ
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=>
>>> labmacambira.sf.net
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=>
>>>
>>> rfabbri.github.io
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=>
>>>
>>>
>>>
>>> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...>
>>> wrote:
>>>
>>> Ricardo,
>>>
>>>
>>>
>>> You are free to do what you like with your own code base that builds on
>>> VXL.  I think it's great to be sharing more code based on VXL and I'm
>>> especially interested in seeing more 3D stereo code.  Your curve
>>> reconstruction work is great, and it would be nice to have to more openly
>>> accessible.
>>>
>>>
>>>
>>> I'm a little confused about what you are proposing here.  Maybe it's
>>> just the name that is throwing me off.  Are you talking about a fork of VXL
>>> that contains all of VXL plus additional contributions?  Or are you talking
>>> about a collection of code that builds against VXL but doesn't contain
>>> VXL?  If it's the former I suggest you just make a fork on Github (either
>>> under your own account, or under a group for your lab) and just call it
>>> VXL.  It would just be github.com/rfabbri/vxl
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>.
>>> Actually, It looks like you've already done that.  Then you can easily push
>>> and pull branches to and from the mainline VXL as needed.  If you are
>>> talking about a repository that is just your research code that builds
>>> against VXL, that is fine too, but the name "Bigvxl" seems a little odd for
>>> that.
>>>
>>>
>>>
>>> --Matt
>>>
>>>
>>>
>>> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I am planing to release a considerable amount of research code on 3D
>>> stereo based on vxl, as a new repository. We all want to keep vxl lean, so
>>> I am planning to call the new project bigvxl. Do you agree? Is the name too
>>> close to vxl?
>>>
>>> The idea is to release large (and possibly klunky) computer vision
>>> systems in bigvxl, which can slowly mature to one day make it into vxl or
>>> even core. Some "big" code by nature don't even have to ever make it to vxl
>>> strict standards or granularity, but can still be very useful.
>>>
>>> The idea came up because most research and industry labs having internal
>>> code that use vxl do not have an intermediate, common and more laidback
>>> open source step prior to pushing code to lean vxl. So I am proposing to
>>> help maintain a common bigvxl repository that can be seen as closely
>>> coordinated with vxl and that can keep up (at least partially) with vxl
>>> changes and be built on official dashboards. I also plan to stratify bigvxl
>>> into core, development libraries, contrib, and so on. At least the bigvxl
>>> team (myself and a couple of students for now) should keep bigvxl's basic
>>> libraries conforming to the latest vxl at all times. Bigvxl woud be easier
>>> to change and less strict (thus messier) than vxl.
>>>
>>> Any thoughts? I plan to publish an initial bigvxl based on publishable
>>> Brown University code in the coming days.
>>>
>>> Best,
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=>
>>> _______________________________________________
>>> Vxl-maintainers mailing list
>>> Vxl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>

On Mon, Oct 24, 2016 at 12:51 PM, Scott Richardson <
sco...@vi...> wrote:
> Would VXL be a compile-time dependency of VXD?

Yes. At first, a CMake variable. But ideally it should detect installed VXL
automatically as other libraries commonly do.

>
> Also, where would the other directories that are currently in vxl/contrib
> (besides contrib/bbas/bnl) go, VXD? Or would you decide on a case-by-case
> basis?

The idea is that VXD can build at the same time as VXL and private
VXL-dependent libraries from other companies/universities, without
conflict, even if this means some code duplication (each library version
having potentially similar code but a different maturity level). So it
would be a parallel hierarchy as much as possible, with different naming.

To begin with, VXD will only have libraries that actually have public code
that is not ready or reviewed for VXL-quality yet. In other words, empty
development libraries will not be mirrored in VXD. This will be decided on
a case by case basis. If we have development code to be open sourced, we
create the *d libraries as needed.

I'm thinking about appending a *d to only the last path/library name. For
instance:
vxl/contrib/brl/bbas/libname would map to vxd/contrib/brl/bbas/libname*d*
(same lib, ending with a *d) as possible.
vxl/contrib/gel/vsol would map to vxd/contrib/gel/vsol*d*

Includes for vxd/contrib/gel/vsold would look like

#include <vsold/vsold_some_class.h>

In CMake, we'd have

include_directories( ${VXD_GEL_INCLUDE_DIR} )


We should strive to to make it always consistent with VXL while apending a
'd' to the lib names. This is a good idea since it is a tiny but good
initial step towards making internal private code available in VXL: you
first name it and place it properly, following the VXL hierarchy, then you
mature the code and one day it may make it to the corresponding folder in
VXL. As easy as it may sound, some developers will find it a lot of work to
have to rename/properly place their internal library prior to open-sourcing
it in VXD. Making a new library name and path correspond to a hypothetical
place in VXL in a clear way would be the first requirement to place code in
VXD.


>
> thanks
> Scott
>
> On Sat, Oct 22, 2016 at 7:12 PM, Ricardo Fabbri <rf...@gm...> wrote:
>>
>> Here's what I'm doing for the individual library naming.
>>
>> A typical setup will have three VXL codebases:  VXL, VXD and an internal
>> version (eg, LEMSVXL at Brown).
>>
>> In VXL, we have things like vgl, vnl etc.  in VXL/contrib/brl/bbas there
>> are things such as bnl for contributions to vnl.
>> The internal / closed-source version of bnl is called dbnl in LEMSVXL.
>>
>> In VXD we should have something in between for, say, vnl development
>> changes that are open-sourced. Since the internal libs at Brown already
>> prepend a 'd', as in 'dbnl', I was thinking that VXD should instead
*append*
>> a 'd', like 'bnld'.
>>
>> So the process of placing code would be threefold:
>>
>> 1) VXL: core/vnl and contrib/bbas/bnl for stable additions from Brown
>> 2) VXD: basic/bnld for less stable additions from Brown, open sourced
>> 3) Closed-sourced code improving bnl (as in LEMSVXL): basic/dbnl
>>
>> This naming convention is important as we want to keep many versions of
>> the same library around, one in VXL, one in VXD and another one inside
the
>> lab. Is this too confusing? It will take some work to do this, so please
let
>> me know.
>>
>> Thanks,
>>
>>
>> --
>> Dr Ricardo Fabbri
>> Professor of Computer Engineering
>> GNU/Linux registered user #175401
>> pt.wikipedia.org/wiki/IPRJ
>> labmacambira.sf.net
>> rfabbri.github.io
>>
>> On Sat, Oct 22, 2016 at 8:28 PM, Ricardo Fabbri <rf...@gm...>
wrote:
>>>
>>> I'm going with Fred's suggestion, vxd.
>>>
>>> dvxl is consistent with the name given to development libraries that
will
>>> be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more
direct
>>> reference to vxl. However, it is too similar to vxl, and is one letter
>>> longer than vxd.
>>>
>>> I'll be uploading code now. Please, please stop me if you prefer dvxl
>>> instead :)
>>>
>>>
>>>
>>> --
>>> Dr Ricardo Fabbri
>>> Professor of Computer Engineering
>>> GNU/Linux registered user #175401
>>> pt.wikipedia.org/wiki/IPRJ
>>> labmacambira.sf.net
>>> rfabbri.github.io
>>>
>>> On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global
>>> Research, US) <wh...@ge...> wrote:
>>>>
>>>>
>>>>
>>>> Perhaps “VXD”?  VXL is meant to mean Vision Something Libraries.  VXD
>>>> could mean Vision Something Development.
>>>>
>>>>
>>>>
>>>> Fred
>>>>
>>>>
>>>>
>>>> From: Ricardo Fabbri [mailto:rf...@gm...]
>>>> Sent: Friday, October 21, 2016 2:49 PM
>>>> To: Matt Leotta <mat...@ki...>
>>>> Cc: Vxl-maintainers <vxl...@li...>; Anil
>>>> Usumezbas <ani...@gm...>
>>>> Subject: EXT: Re: [Vxl-maintainers] bigvxl : a new project
>>>>
>>>>
>>>>
>>>> Hi Matt,
>>>>
>>>>
>>>>
>>>> I was thinking about "a collection of code that builds against VXL but
>>>> doesn't contain VXL".
>>>>
>>>> Another name would be dvxl or DVXL for Development VXL. Does that dound
>>>> less odd?
>>>>
>>>> I am open for other names. I should be uploading the code very soon, in
>>>> the coming days.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> --
>>>> Dr Ricardo Fabbri
>>>> Professor of Computer Engineering
>>>> GNU/Linux registered user #175401
>>>> pt.wikipedia.org/wiki/IPRJ
>>>> labmacambira.sf.net
>>>>
>>>> rfabbri.github.io
>>>>
>>>>
>>>>
>>>> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...>
>>>> wrote:
>>>>
>>>> Ricardo,
>>>>
>>>>
>>>>
>>>> You are free to do what you like with your own code base that builds on
>>>> VXL.  I think it's great to be sharing more code based on VXL and I'm
>>>> especially interested in seeing more 3D stereo code.  Your curve
>>>> reconstruction work is great, and it would be nice to have to more
openly
>>>> accessible.
>>>>
>>>>
>>>>
>>>> I'm a little confused about what you are proposing here.  Maybe it's
>>>> just the name that is throwing me off.  Are you talking about a fork
of VXL
>>>> that contains all of VXL plus additional contributions?  Or are you
talking
>>>> about a collection of code that builds against VXL but doesn't contain
VXL?
>>>> If it's the former I suggest you just make a fork on Github (either
under
>>>> your own account, or under a group for your lab) and just call it
VXL.  It
>>>> would just be github.com/rfabbri/vxl.  Actually, It looks like you've
>>>> already done that.  Then you can easily push and pull branches to and
from
>>>> the mainline VXL as needed.  If you are talking about a repository
that is
>>>> just your research code that builds against VXL, that is fine too, but
the
>>>> name "Bigvxl" seems a little odd for that.
>>>>
>>>>
>>>>
>>>> --Matt
>>>>
>>>>
>>>>
>>>> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am planing to release a considerable amount of research code on 3D
>>>> stereo based on vxl, as a new repository. We all want to keep vxl
lean, so I
>>>> am planning to call the new project bigvxl. Do you agree? Is the name
too
>>>> close to vxl?
>>>>
>>>> The idea is to release large (and possibly klunky) computer vision
>>>> systems in bigvxl, which can slowly mature to one day make it into vxl
or
>>>> even core. Some "big" code by nature don't even have to ever make it
to vxl
>>>> strict standards or granularity, but can still be very useful.
>>>>
>>>> The idea came up because most research and industry labs having
internal
>>>> code that use vxl do not have an intermediate, common and more
laidback open
>>>> source step prior to pushing code to lean vxl. So I am proposing to
help
>>>> maintain a common bigvxl repository that can be seen as closely
coordinated
>>>> with vxl and that can keep up (at least partially) with vxl changes
and be
>>>> built on official dashboards. I also plan to stratify bigvxl into core,
>>>> development libraries, contrib, and so on. At least the bigvxl team
(myself
>>>> and a couple of students for now) should keep bigvxl's basic libraries
>>>> conforming to the latest vxl at all times. Bigvxl woud be easier to
change
>>>> and less strict (thus messier) than vxl.
>>>>
>>>> Any thoughts? I plan to publish an initial bigvxl based on publishable
>>>> Brown University code in the coming days.
>>>>
>>>> Best,
>>>>
>>>>
>>>>
>>>>
>>>>
------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Vxl-maintainers mailing list
>>>> Vxl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Vxl-maintainers mailing list
>> Vxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>>
>

Here's what I'm doing for the individual library naming.

A typical setup will have three VXL codebases:  VXL, VXD and an internal
version (eg, LEMSVXL at Brown).

In VXL, we have things like vgl, vnl etc.  in VXL/contrib/brl/bbas there
are things such as bnl for contributions to vnl.
The internal / closed-source version of bnl is called dbnl in LEMSVXL.

In VXD we should have something in between for, say, vnl development
changes that are open-sourced. Since the internal libs at Brown already
prepend a 'd', as in 'dbnl', I was thinking that VXD should instead
*append* a 'd', like 'bnld'.

So the process of placing code would be threefold:

1) VXL: core/vnl and contrib/bbas/bnl for stable additions from Brown
2) VXD: basic/bnld for less stable additions from Brown, open sourced
3) Closed-sourced code improving bnl (as in LEMSVXL): basic/dbnl

This naming convention is important as we want to keep many versions of the
same library around, one in VXL, one in VXD and another one inside the lab.
Is this too confusing? It will take some work to do this, so please let me
know.

Thanks,


--
Dr Ricardo Fabbri
Professor of Computer Engineering
GNU/Linux registered user #175401
pt.wikipedia.org/wiki/IPRJ
labmacambira.sf.net
rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>

On Sat, Oct 22, 2016 at 8:28 PM, Ricardo Fabbri <rf...@gm...> wrote:

> I'm going with Fred's suggestion, vxd.
>
> dvxl is consistent with the name given to development libraries that will
> be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more
> direct reference to vxl. However, it is too similar to vxl, and is one
> letter longer than vxd.
>
> I'll be uploading code now. Please, please stop me if you prefer dvxl
> instead :)
>
>
>
> --
> Dr Ricardo Fabbri
> Professor of Computer Engineering
> GNU/Linux registered user #175401
> pt.wikipedia.org/wiki/IPRJ
> labmacambira.sf.net
> rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>
>
> On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global Research,
> US) <wh...@ge...> wrote:
>
>>
>>
>> Perhaps “VXD”?  VXL is meant to mean Vision Something Libraries.  VXD
>> could mean Vision Something Development.
>>
>>
>>
>> Fred
>>
>>
>>
>> *From:* Ricardo Fabbri [mailto:rf...@gm...]
>> *Sent:* Friday, October 21, 2016 2:49 PM
>> *To:* Matt Leotta <mat...@ki...>
>> *Cc:* Vxl-maintainers <vxl...@li...>; Anil
>> Usumezbas <ani...@gm...>
>> *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project
>>
>>
>>
>> Hi Matt,
>>
>>
>>
>> I was thinking about "a collection of code that builds against VXL but
>> doesn't contain VXL".
>>
>> Another name would be dvxl or DVXL for Development VXL. Does that dound
>> less odd?
>>
>> I am open for other names. I should be uploading the code very soon, in
>> the coming days.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> --
>> Dr Ricardo Fabbri
>> Professor of Computer Engineering
>> GNU/Linux registered user #175401
>> pt.wikipedia.org/wiki/IPRJ
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=>
>> labmacambira.sf.net
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=>
>>
>> rfabbri.github.io
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=>
>>
>>
>>
>> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...>
>> wrote:
>>
>> Ricardo,
>>
>>
>>
>> You are free to do what you like with your own code base that builds on
>> VXL.  I think it's great to be sharing more code based on VXL and I'm
>> especially interested in seeing more 3D stereo code.  Your curve
>> reconstruction work is great, and it would be nice to have to more openly
>> accessible.
>>
>>
>>
>> I'm a little confused about what you are proposing here.  Maybe it's just
>> the name that is throwing me off.  Are you talking about a fork of VXL that
>> contains all of VXL plus additional contributions?  Or are you talking
>> about a collection of code that builds against VXL but doesn't contain
>> VXL?  If it's the former I suggest you just make a fork on Github (either
>> under your own account, or under a group for your lab) and just call it
>> VXL.  It would just be github.com/rfabbri/vxl
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>.
>> Actually, It looks like you've already done that.  Then you can easily push
>> and pull branches to and from the mainline VXL as needed.  If you are
>> talking about a repository that is just your research code that builds
>> against VXL, that is fine too, but the name "Bigvxl" seems a little odd for
>> that.
>>
>>
>>
>> --Matt
>>
>>
>>
>> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...>
>> wrote:
>>
>> Hi,
>>
>> I am planing to release a considerable amount of research code on 3D
>> stereo based on vxl, as a new repository. We all want to keep vxl lean, so
>> I am planning to call the new project bigvxl. Do you agree? Is the name too
>> close to vxl?
>>
>> The idea is to release large (and possibly klunky) computer vision
>> systems in bigvxl, which can slowly mature to one day make it into vxl or
>> even core. Some "big" code by nature don't even have to ever make it to vxl
>> strict standards or granularity, but can still be very useful.
>>
>> The idea came up because most research and industry labs having internal
>> code that use vxl do not have an intermediate, common and more laidback
>> open source step prior to pushing code to lean vxl. So I am proposing to
>> help maintain a common bigvxl repository that can be seen as closely
>> coordinated with vxl and that can keep up (at least partially) with vxl
>> changes and be built on official dashboards. I also plan to stratify bigvxl
>> into core, development libraries, contrib, and so on. At least the bigvxl
>> team (myself and a couple of students for now) should keep bigvxl's basic
>> libraries conforming to the latest vxl at all times. Bigvxl woud be easier
>> to change and less strict (thus messier) than vxl.
>>
>> Any thoughts? I plan to publish an initial bigvxl based on publishable
>> Brown University code in the coming days.
>>
>> Best,
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=>
>> _______________________________________________
>> Vxl-maintainers mailing list
>> Vxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=>
>>
>>
>>
>>
>>
>
>

I'm going with Fred's suggestion, vxd.

dvxl is consistent with the name given to development libraries that will
be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more
direct reference to vxl. However, it is too similar to vxl, and is one
letter longer than vxd.

I'll be uploading code now. Please, please stop me if you prefer dvxl
instead :)



--
Dr Ricardo Fabbri
Professor of Computer Engineering
GNU/Linux registered user #175401
pt.wikipedia.org/wiki/IPRJ
labmacambira.sf.net
rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>

On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global Research,
US) <wh...@ge...> wrote:

>
>
> Perhaps “VXD”?  VXL is meant to mean Vision Something Libraries.  VXD
> could mean Vision Something Development.
>
>
>
> Fred
>
>
>
> *From:* Ricardo Fabbri [mailto:rf...@gm...]
> *Sent:* Friday, October 21, 2016 2:49 PM
> *To:* Matt Leotta <mat...@ki...>
> *Cc:* Vxl-maintainers <vxl...@li...>; Anil
> Usumezbas <ani...@gm...>
> *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project
>
>
>
> Hi Matt,
>
>
>
> I was thinking about "a collection of code that builds against VXL but
> doesn't contain VXL".
>
> Another name would be dvxl or DVXL for Development VXL. Does that dound
> less odd?
>
> I am open for other names. I should be uploading the code very soon, in
> the coming days.
>
>
>
> Thanks,
>
>
>
> --
> Dr Ricardo Fabbri
> Professor of Computer Engineering
> GNU/Linux registered user #175401
> pt.wikipedia.org/wiki/IPRJ
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=>
> labmacambira.sf.net
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=>
>
> rfabbri.github.io
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=>
>
>
>
> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...>
> wrote:
>
> Ricardo,
>
>
>
> You are free to do what you like with your own code base that builds on
> VXL.  I think it's great to be sharing more code based on VXL and I'm
> especially interested in seeing more 3D stereo code.  Your curve
> reconstruction work is great, and it would be nice to have to more openly
> accessible.
>
>
>
> I'm a little confused about what you are proposing here.  Maybe it's just
> the name that is throwing me off.  Are you talking about a fork of VXL that
> contains all of VXL plus additional contributions?  Or are you talking
> about a collection of code that builds against VXL but doesn't contain
> VXL?  If it's the former I suggest you just make a fork on Github (either
> under your own account, or under a group for your lab) and just call it
> VXL.  It would just be github.com/rfabbri/vxl
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>.
> Actually, It looks like you've already done that.  Then you can easily push
> and pull branches to and from the mainline VXL as needed.  If you are
> talking about a repository that is just your research code that builds
> against VXL, that is fine too, but the name "Bigvxl" seems a little odd for
> that.
>
>
>
> --Matt
>
>
>
> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...>
> wrote:
>
> Hi,
>
> I am planing to release a considerable amount of research code on 3D
> stereo based on vxl, as a new repository. We all want to keep vxl lean, so
> I am planning to call the new project bigvxl. Do you agree? Is the name too
> close to vxl?
>
> The idea is to release large (and possibly klunky) computer vision systems
> in bigvxl, which can slowly mature to one day make it into vxl or even
> core. Some "big" code by nature don't even have to ever make it to vxl
> strict standards or granularity, but can still be very useful.
>
> The idea came up because most research and industry labs having internal
> code that use vxl do not have an intermediate, common and more laidback
> open source step prior to pushing code to lean vxl. So I am proposing to
> help maintain a common bigvxl repository that can be seen as closely
> coordinated with vxl and that can keep up (at least partially) with vxl
> changes and be built on official dashboards. I also plan to stratify bigvxl
> into core, development libraries, contrib, and so on. At least the bigvxl
> team (myself and a couple of students for now) should keep bigvxl's basic
> libraries conforming to the latest vxl at all times. Bigvxl woud be easier
> to change and less strict (thus messier) than vxl.
>
> Any thoughts? I plan to publish an initial bigvxl based on publishable
> Brown University code in the coming days.
>
> Best,
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=>
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=>
>
>
>
>
>

Perhaps “VXD”?  VXL is meant to mean Vision Something Libraries.  VXD could mean Vision Something Development.

Fred

From: Ricardo Fabbri [mailto:rf...@gm...]
Sent: Friday, October 21, 2016 2:49 PM
To: Matt Leotta <mat...@ki...>
Cc: Vxl-maintainers <vxl...@li...>; Anil Usumezbas <ani...@gm...>
Subject: EXT: Re: [Vxl-maintainers] bigvxl : a new project

Hi Matt,

I was thinking about "a collection of code that builds against VXL but doesn't contain VXL".
Another name would be dvxl or DVXL for Development VXL. Does that dound less odd?
I am open for other names. I should be uploading the code very soon, in the coming days.

Thanks,


--
Dr Ricardo Fabbri
Professor of Computer Engineering
GNU/Linux registered user #175401
pt.wikipedia.org/wiki/IPRJ<https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=>
labmacambira.sf.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=>
rfabbri.github.io<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=>

On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...<mailto:mat...@ki...>> wrote:
Ricardo,

You are free to do what you like with your own code base that builds on VXL.  I think it's great to be sharing more code based on VXL and I'm especially interested in seeing more 3D stereo code.  Your curve reconstruction work is great, and it would be nice to have to more openly accessible.

I'm a little confused about what you are proposing here.  Maybe it's just the name that is throwing me off.  Are you talking about a fork of VXL that contains all of VXL plus additional contributions?  Or are you talking about a collection of code that builds against VXL but doesn't contain VXL?  If it's the former I suggest you just make a fork on Github (either under your own account, or under a group for your lab) and just call it VXL.  It would just be github.com/rfabbri/vxl<https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>.  Actually, It looks like you've already done that.  Then you can easily push and pull branches to and from the mainline VXL as needed.  If you are talking about a repository that is just your research code that builds against VXL, that is fine too, but the name "Bigvxl" seems a little odd for that.

--Matt

On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...<mailto:rf...@gm...>> wrote:

Hi,

I am planing to release a considerable amount of research code on 3D  stereo based on vxl, as a new repository. We all want to keep vxl lean, so I am planning to call the new project bigvxl. Do you agree? Is the name too close to vxl?

The idea is to release large (and possibly klunky) computer vision systems in bigvxl, which can slowly mature to one day make it into vxl or even core. Some "big" code by nature don't even have to ever make it to vxl strict standards or granularity, but can still be very useful.

The idea came up because most research and industry labs having internal code that use vxl do not have an intermediate, common and more laidback open source step prior to pushing code to lean vxl. So I am proposing to help maintain a common bigvxl repository that can be seen as closely coordinated with vxl and that can keep up (at least partially) with vxl changes and be built on official dashboards. I also plan to stratify bigvxl into core, development libraries, contrib, and so on. At least the bigvxl team (myself and a couple of students for now) should keep bigvxl's basic libraries conforming to the latest vxl at all times. Bigvxl woud be easier to change and less strict (thus messier) than vxl.

Any thoughts? I plan to publish an initial bigvxl based on publishable Brown University code in the coming days.

Best,

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=>
_______________________________________________
Vxl-maintainers mailing list
Vxl...@li...<mailto:Vxl...@li...>
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=>

Hi Matt,

I was thinking about "a collection of code that builds against VXL but
doesn't contain VXL".
Another name would be dvxl or DVXL for Development VXL. Does that dound
less odd?
I am open for other names. I should be uploading the code very soon, in the
coming days.

Thanks,


--
Dr Ricardo Fabbri
Professor of Computer Engineering
GNU/Linux registered user #175401
pt.wikipedia.org/wiki/IPRJ
labmacambira.sf.net
rfabbri.github.io <http://www.lems.brown.edu/~rfabbri>

On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...>
wrote:

> Ricardo,
>
> You are free to do what you like with your own code base that builds on
> VXL.  I think it's great to be sharing more code based on VXL and I'm
> especially interested in seeing more 3D stereo code.  Your curve
> reconstruction work is great, and it would be nice to have to more openly
> accessible.
>
> I'm a little confused about what you are proposing here.  Maybe it's just
> the name that is throwing me off.  Are you talking about a fork of VXL that
> contains all of VXL plus additional contributions?  Or are you talking
> about a collection of code that builds against VXL but doesn't contain
> VXL?  If it's the former I suggest you just make a fork on Github (either
> under your own account, or under a group for your lab) and just call it
> VXL.  It would just be github.com/rfabbri/vxl.  Actually, It looks like
> you've already done that.  Then you can easily push and pull branches to
> and from the mainline VXL as needed.  If you are talking about a repository
> that is just your research code that builds against VXL, that is fine too,
> but the name "Bigvxl" seems a little odd for that.
>
> --Matt
>
> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...>
> wrote:
>
>> Hi,
>>
>> I am planing to release a considerable amount of research code on 3D
>> stereo based on vxl, as a new repository. We all want to keep vxl lean, so
>> I am planning to call the new project bigvxl. Do you agree? Is the name too
>> close to vxl?
>>
>> The idea is to release large (and possibly klunky) computer vision
>> systems in bigvxl, which can slowly mature to one day make it into vxl or
>> even core. Some "big" code by nature don't even have to ever make it to vxl
>> strict standards or granularity, but can still be very useful.
>>
>> The idea came up because most research and industry labs having internal
>> code that use vxl do not have an intermediate, common and more laidback
>> open source step prior to pushing code to lean vxl. So I am proposing to
>> help maintain a common bigvxl repository that can be seen as closely
>> coordinated with vxl and that can keep up (at least partially) with vxl
>> changes and be built on official dashboards. I also plan to stratify bigvxl
>> into core, development libraries, contrib, and so on. At least the bigvxl
>> team (myself and a couple of students for now) should keep bigvxl's basic
>> libraries conforming to the latest vxl at all times. Bigvxl woud be easier
>> to change and less strict (thus messier) than vxl.
>>
>> Any thoughts? I plan to publish an initial bigvxl based on publishable
>> Brown University code in the coming days.
>>
>> Best,
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Vxl-maintainers mailing list
>> Vxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>>
>>
>

Ricardo,

You are free to do what you like with your own code base that builds on
VXL.  I think it's great to be sharing more code based on VXL and I'm
especially interested in seeing more 3D stereo code.  Your curve
reconstruction work is great, and it would be nice to have to more openly
accessible.

I'm a little confused about what you are proposing here.  Maybe it's just
the name that is throwing me off.  Are you talking about a fork of VXL that
contains all of VXL plus additional contributions?  Or are you talking
about a collection of code that builds against VXL but doesn't contain
VXL?  If it's the former I suggest you just make a fork on Github (either
under your own account, or under a group for your lab) and just call it
VXL.  It would just be github.com/rfabbri/vxl.  Actually, It looks like
you've already done that.  Then you can easily push and pull branches to
and from the mainline VXL as needed.  If you are talking about a repository
that is just your research code that builds against VXL, that is fine too,
but the name "Bigvxl" seems a little odd for that.

--Matt

On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> wrote:

> Hi,
>
> I am planing to release a considerable amount of research code on 3D
> stereo based on vxl, as a new repository. We all want to keep vxl lean, so
> I am planning to call the new project bigvxl. Do you agree? Is the name too
> close to vxl?
>
> The idea is to release large (and possibly klunky) computer vision systems
> in bigvxl, which can slowly mature to one day make it into vxl or even
> core. Some "big" code by nature don't even have to ever make it to vxl
> strict standards or granularity, but can still be very useful.
>
> The idea came up because most research and industry labs having internal
> code that use vxl do not have an intermediate, common and more laidback
> open source step prior to pushing code to lean vxl. So I am proposing to
> help maintain a common bigvxl repository that can be seen as closely
> coordinated with vxl and that can keep up (at least partially) with vxl
> changes and be built on official dashboards. I also plan to stratify bigvxl
> into core, development libraries, contrib, and so on. At least the bigvxl
> team (myself and a couple of students for now) should keep bigvxl's basic
> libraries conforming to the latest vxl at all times. Bigvxl woud be easier
> to change and less strict (thus messier) than vxl.
>
> Any thoughts? I plan to publish an initial bigvxl based on publishable
> Brown University code in the coming days.
>
> Best,
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>

Hi,

I am planing to release a considerable amount of research code on 3D
stereo based on vxl, as a new repository. We all want to keep vxl lean, so
I am planning to call the new project bigvxl. Do you agree? Is the name too
close to vxl?

The idea is to release large (and possibly klunky) computer vision systems
in bigvxl, which can slowly mature to one day make it into vxl or even
core. Some "big" code by nature don't even have to ever make it to vxl
strict standards or granularity, but can still be very useful.

The idea came up because most research and industry labs having internal
code that use vxl do not have an intermediate, common and more laidback
open source step prior to pushing code to lean vxl. So I am proposing to
help maintain a common bigvxl repository that can be seen as closely
coordinated with vxl and that can keep up (at least partially) with vxl
changes and be built on official dashboards. I also plan to stratify bigvxl
into core, development libraries, contrib, and so on. At least the bigvxl
team (myself and a couple of students for now) should keep bigvxl's basic
libraries conforming to the latest vxl at all times. Bigvxl woud be easier
to change and less strict (thus messier) than vxl.

Any thoughts? I plan to publish an initial bigvxl based on publishable
Brown University code in the coming days.

Best,

Hi,

Yes, these will be fixed in a follow-up patch.

Thanks,
Matt

On Thu, Jul 7, 2016 at 10:01 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C]
<blo...@ma...> wrote:
> Matt,
>
> This patch looks like it is the source of a number of valgrind defects on the ITK dashboard that need to be addressed.
>
> https://open.cdash.org/viewDynamicAnalysisFile.php?id=3934294
>
> Brad
>
>> On Jul 7, 2016, at 9:57 AM, Matt McCormick <mat...@ki...> wrote:
>>
>> Following up, this issue was addressed in this patch:
>>
>>  http://review.source.kitware.com/#/c/21296/
>>
>> and pushed upstream here:
>>
>>  https://github.com/vxl/vxl/pull/337
>>
>> It will be included in the ITK 4.10.1 release.
>>
>> On Fri, Jul 1, 2016 at 4:45 AM, Tom Vercauteren <tom...@m4...> wrote:
>>> Dear all,
>>>
>>> Sorry for the cross-posting but this refers to an issue linking both ITK and
>>> VNL.
>>>
>>> In 2010, we identified a licensing issue with some code from vnl and at the
>>> time Luis Ibanez fixed it from the ITK side:
>>> https://issues.itk.org/jira/browse/HISTITK-1160
>>>
>>> Luis notably rewrote the LSQR code:
>>> https://github.com/InsightSoftwareConsortium/ITK/tree/release-3.20/Utilities/vxl/v3p/netlib/linalg
>>> http://svn.na-mic.org/NAMICSandBox/trunk/SparseLinearSolverConversion/C++/
>>> https://github.com/InsightSoftwareConsortium/ITK/commits/release-3.20/Utilities/vxl/v3p/netlib/linalg
>>>
>>> It seems that this effort was not backported to VXL and was subsequently
>>> lost when moving to ITK 4:
>>> https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/ThirdParty/VNL/src/vxl/v3p/netlib/linalg
>>>
>>> It would be great if someone could look into this (important) licensing
>>> issue.
>>>
>>> For the only purpose of LSQR, I copied the LSQR NAMICSandBox code in a
>>> standalone github repo here:
>>> https://github.com/tvercaut/LSQR-cpp
>>>
>>> I have also added a comment in the ITK and VXL bug trackers:
>>> https://issues.itk.org/jira/browse/HISTITK-1160
>>> https://github.com/vxl/vxl/issues/332
>>>
>>> Best wishes,
>>> Tom
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/insight-developers
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/insight-developers
>

Matt,

This patch looks like it is the source of a number of valgrind defects on the ITK dashboard that need to be addressed.

https://open.cdash.org/viewDynamicAnalysisFile.php?id=3934294

Brad

> On Jul 7, 2016, at 9:57 AM, Matt McCormick <mat...@ki...> wrote:
> 
> Following up, this issue was addressed in this patch:
> 
>  http://review.source.kitware.com/#/c/21296/
> 
> and pushed upstream here:
> 
>  https://github.com/vxl/vxl/pull/337
> 
> It will be included in the ITK 4.10.1 release.
> 
> On Fri, Jul 1, 2016 at 4:45 AM, Tom Vercauteren <tom...@m4...> wrote:
>> Dear all,
>> 
>> Sorry for the cross-posting but this refers to an issue linking both ITK and
>> VNL.
>> 
>> In 2010, we identified a licensing issue with some code from vnl and at the
>> time Luis Ibanez fixed it from the ITK side:
>> https://issues.itk.org/jira/browse/HISTITK-1160
>> 
>> Luis notably rewrote the LSQR code:
>> https://github.com/InsightSoftwareConsortium/ITK/tree/release-3.20/Utilities/vxl/v3p/netlib/linalg
>> http://svn.na-mic.org/NAMICSandBox/trunk/SparseLinearSolverConversion/C++/
>> https://github.com/InsightSoftwareConsortium/ITK/commits/release-3.20/Utilities/vxl/v3p/netlib/linalg
>> 
>> It seems that this effort was not backported to VXL and was subsequently
>> lost when moving to ITK 4:
>> https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/ThirdParty/VNL/src/vxl/v3p/netlib/linalg
>> 
>> It would be great if someone could look into this (important) licensing
>> issue.
>> 
>> For the only purpose of LSQR, I copied the LSQR NAMICSandBox code in a
>> standalone github repo here:
>> https://github.com/tvercaut/LSQR-cpp
>> 
>> I have also added a comment in the ITK and VXL bug trackers:
>> https://issues.itk.org/jira/browse/HISTITK-1160
>> https://github.com/vxl/vxl/issues/332
>> 
>> Best wishes,
>> Tom
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/insight-developers
>> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers

Following up, this issue was addressed in this patch:

  http://review.source.kitware.com/#/c/21296/

and pushed upstream here:

  https://github.com/vxl/vxl/pull/337

It will be included in the ITK 4.10.1 release.

On Fri, Jul 1, 2016 at 4:45 AM, Tom Vercauteren <tom...@m4...> wrote:
> Dear all,
>
> Sorry for the cross-posting but this refers to an issue linking both ITK and
> VNL.
>
> In 2010, we identified a licensing issue with some code from vnl and at the
> time Luis Ibanez fixed it from the ITK side:
> https://issues.itk.org/jira/browse/HISTITK-1160
>
> Luis notably rewrote the LSQR code:
> https://github.com/InsightSoftwareConsortium/ITK/tree/release-3.20/Utilities/vxl/v3p/netlib/linalg
> http://svn.na-mic.org/NAMICSandBox/trunk/SparseLinearSolverConversion/C++/
> https://github.com/InsightSoftwareConsortium/ITK/commits/release-3.20/Utilities/vxl/v3p/netlib/linalg
>
> It seems that this effort was not backported to VXL and was subsequently
> lost when moving to ITK 4:
> https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/ThirdParty/VNL/src/vxl/v3p/netlib/linalg
>
> It would be great if someone could look into this (important) licensing
> issue.
>
> For the only purpose of LSQR, I copied the LSQR NAMICSandBox code in a
> standalone github repo here:
> https://github.com/tvercaut/LSQR-cpp
>
> I have also added a comment in the ITK and VXL bug trackers:
> https://issues.itk.org/jira/browse/HISTITK-1160
> https://github.com/vxl/vxl/issues/332
>
> Best wishes,
> Tom
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers
>

Dear all,

Sorry for the cross-posting but this refers to an issue linking both ITK
and VNL.

In 2010, we identified a licensing issue with some code from vnl and at the
time Luis Ibanez fixed it from the ITK side:
https://issues.itk.org/jira/browse/HISTITK-1160

Luis notably rewrote the LSQR code:
https://github.com/InsightSoftwareConsortium/ITK/tree/release-3.20/Utilities/vxl/v3p/netlib/linalg
http://svn.na-mic.org/NAMICSandBox/trunk/SparseLinearSolverConversion/C++/
https://github.com/InsightSoftwareConsortium/ITK/commits/release-3.20/Utilities/vxl/v3p/netlib/linalg

It seems that this effort was not backported to VXL and was subsequently
lost when moving to ITK 4:
https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/ThirdParty/VNL/src/vxl/v3p/netlib/linalg

It would be great if someone could look into this (important) licensing
issue.

For the only purpose of LSQR, I copied the LSQR NAMICSandBox code in a
standalone github repo here:
https://github.com/tvercaut/LSQR-cpp

I have also added a comment in the ITK and VXL bug trackers:
https://issues.itk.org/jira/browse/HISTITK-1160
https://github.com/vxl/vxl/issues/332

Best wishes,
Tom

Hi Dan,

This is great!  I have been longing for a vxl python wrappers. Thank you 
for making this first step!

I will be interested to check it out.

Best,

Gary



On 6/5/2016 2:56 PM, Daniel Crispell wrote:
> For anyone interested in using vxl from python, I've implemented the 
> beginnings of a set of vxl python bindings using Boost.Python.  As of 
> now there are only basic bindings for some vnl, vgl, and vpgl classes, 
> but I thought I'd put it out there to see if there was community 
> interest and to make sure I'm not duplicating any existing work.
>
> https://github.com/decrispell/pyvxl
>
> -Dan
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

For anyone interested in using vxl from python, I've implemented the
beginnings of a set of vxl python bindings using Boost.Python.  As of now
there are only basic bindings for some vnl, vgl, and vpgl classes, but I
thought I'd put it out there to see if there was community interest and to
make sure I'm not duplicating any existing work.

https://github.com/decrispell/pyvxl

-Dan

Disclaimer: Python 2 and python 2 packages are ONLY supposed to be built
using VS2008. Python 3 and Python 3 packages are ONLY supposed to be built
with VS2010. By complying the vxl files in a different version like say
VS2012, we are actually introducing two version of the VS runtime at the
same time... This  is not suggested, and I have seen it go south on other
python projects before. However, on VXL it seems to "work". That being said
and ignored....

We have found the cleanest/easiest solution to building debug in windows is
to build in release mode with debug symbols and optimization. The only
downside to that solution is the macros DEBUG/NDEBUG flags will still be
set for release mode

On Thu, Mar 10, 2016 at 9:07 AM, David Stoup <dav...@ki...>
wrote:

> Yes, python_d is the issue I've had. Python forces debug builds to use it
> when it doesn't always exist. VTK solved the issue by inserting a header to
> control the python.h flags.
>
> On Thu, Mar 10, 2016 at 9:05 AM, Joseph Mundy <mu...@le...>
> wrote:
>
>> So far I haven’t seen any big problems except for issues with python_d,
>> maybe that is what Dave is referring to. I didn’t see Dave’s post.
>>
>> Joe
>>
>>
>>
>> *From:* Johnson, Hans J [mailto:han...@ui...]
>> *Sent:* Thursday, March 10, 2016 8:27 AM
>> *To:* David Stoup
>> *Cc:* Joseph Mundy; vxl...@li...;
>> vxl...@li...; Vishal Jain
>>
>> *Subject:* Re: [Vxl-maintainers] BRL status on Windows
>>
>>
>>
>> I hope that someone else can take on the challenge of making python work
>> on windows.  That is far beyond my comfort level.
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>> *From: *David Stoup <dav...@ki...>
>> *Date: *Thursday, March 10, 2016 at 7:07 AM
>> *To: *Hans Johnson <han...@ui...>
>> *Cc: *Joseph Mundy <mu...@le...>, "
>> vxl...@li..." <vxl...@li...>, "
>> vxl...@li..." <
>> vxl...@li...>, Vishal Jain <
>> vi...@vi...>
>> *Subject: *Re: [Vxl-maintainers] BRL status on Windows
>>
>>
>>
>> Aside from what's mentioned above, the issue I have building BRL on
>> Windows is with Python enabled in a debug build. VTK has a decent solution
>> to the problem. I wrote up an issue several months ago.
>>
>>
>>
>> On Thu, Mar 10, 2016 at 7:57 AM, Johnson, Hans J <han...@ui...>
>> wrote:
>>
>> Joseph,
>>
>>
>>
>> I am not a native windows developer, if you could assist with finding
>> that build issue on windows, it will free me to work on other tasks more
>> suited to my skills.
>>
>>
>>
>> Thanks,
>>
>> Hans
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>> *From: *Joseph Mundy <mu...@le...>
>> *Date: *Thursday, March 10, 2016 at 6:47 AM
>> *To: *Hans Johnson <han...@ui...>, "
>> vxl...@li..." <vxl...@li...>, "
>> vxl...@li..." <
>> vxl...@li...>, Vishal Jain <
>> vi...@vi...>
>> *Subject: *RE: [Vxl-maintainers] BRL status on Windows
>>
>>
>>
>> Hans,
>>
>> I currently run VS2012.
>>
>> We will take a look as well. I agree the issue is probably to do with the
>> expat CMake find process.
>>
>> Thanks,
>>
>> Joe
>>
>> *From:* Johnson, Hans J [mailto:han...@ui...
>> <han...@ui...>]
>> *Sent:* Thursday, March 10, 2016 7:33 AM
>> *To:* Joseph Mundy; vxl...@li...;
>> vxl...@li...
>> *Subject:* Re: [Vxl-maintainers] BRL status on Windows
>>
>>
>>
>> Joseph,
>>
>>
>>
>> Can you describe your windows build environment?  VS2010?
>>
>>
>>
>> Regarding Expat,  that will require some digging.  There were changes
>> made to the FindExpat, and there are currently issues reported regarding
>> problems with the way that FindExpat and FindExpatpp are looking for their
>> files.
>>
>>
>>
>> I’ll have a look at this over the next few weeks.
>>
>>
>>
>> Hans
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>> *From: *Joseph Mundy <mu...@le...>
>> *Date: *Thursday, March 10, 2016 at 4:53 AM
>> *To: *Hans Johnson <han...@ui...>, "
>> vxl...@li..." <vxl...@li...>, "
>> vxl...@li..." <
>> vxl...@li...>
>> *Subject: *RE: [Vxl-maintainers] BRL status on Windows
>>
>>
>>
>> Hans,
>>
>> Yes. I have been working with brl on windows for years. But the recent
>> master branch is horribly broken on windows due to issues with expat and
>> expatpp. The bulk of the errors are due to missing expat symbols. Do you
>> know of some change that would affect expat?
>>
>> Thanks,
>>
>> Joe
>>
>>
>>
>> *From:* Johnson, Hans J [mailto:han...@ui...
>> <han...@ui...>]
>> *Sent:* Wednesday, March 9, 2016 8:56 PM
>> *To:* vxl...@li...;
>> vxl...@li...
>> *Subject:* [Vxl-maintainers] BRL status on Windows
>>
>>
>>
>> BRL team,
>>
>>
>>
>> Is the contrib/brl directory expected to compile on windows?
>>
>>
>>
>> There are a tremendous number of compiler errors and warnings being
>> generated.
>>
>>
>>
>> Hans
>>
>>
>>
>>
>>
>>
>>
>> ========================================================================
>>
>> | Hans J. Johnson, Ph.D.,  Associate Professor                         |
>>
>> | Appointments:                                                        |
>>
>> |   - Electrical and Computer Engineering (Primary)                    |
>>
>> |   - Biomedical Engineering                                           |
>>
>> |   - Psychiatry                                     ,NMMM~            |
>>
>> |   - Health Informatics                         MMMMMMMMMMMMMMN       |
>>
>> |   - Iowa Institute for Biomedical Imaging    MMMMMMMMMMMMMMMMMMM     |
>>
>> |   - Iowa Informatics Institute             MMMMMMMMMMM MMMM MMM      |
>>
>> |                                            MMMMMMMMMM I ?MMM  MM M   |
>>
>> | han...@ui...                     MMMMMMM ,$M,        MMMM  |
>>
>> | (319) 621 7185 (cell)                        MMMM~     MMMM   MMMMMM |
>>
>> | (319) 384 3538  ECE Phone (Primary)           MM    8MMMMMM       MM |
>>
>> |                                               M    MMMMMMM, ,M~    M |
>>
>> | 4316 Seamans Center                                MMMMMM     MM     |
>>
>> | Iowa City, IA 52242                                 ,?               |
>>
>> ========================================================================
>>
>> http://emailcharter.org
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>> _______________________________________________
>> Vxl-maintainers mailing list
>> Vxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>>
>>
>>
>>
>> --
>>
>> David Stoup
>> R&D Engineer
>>
>> Kitware, Inc.
>> 28 Corporate Drive
>> Clifton Park, NY. 12065
>> 518-881-4949 (W)
>>
>> 518-312-3946 (M)
>>
>> 518-371-4573 (F)
>>
>
>
>
> --
> David Stoup
> R&D Engineer
>
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY. 12065
> 518-881-4949 (W)
> 518-312-3946 (M)
> 518-371-4573 (F)
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>

On 03/10/2016 07:47 AM, Joseph Mundy wrote:
> I agree the issue is probably to do with the expat CMake find process.
[snip]
> horribly broken on windows due to issues with expat and expatpp.

This should fix that problem:

 https://github.com/vxl/vxl/pull/234

It looks like that expat library was copied from the CMake source tree.
It uses the "cm_" prefix extensively.  Additional work should be done
to change the prefix to "brl_" or something else specific to this use
case.

-Brad

Yes, python_d is the issue I've had. Python forces debug builds to use it
when it doesn't always exist. VTK solved the issue by inserting a header to
control the python.h flags.

On Thu, Mar 10, 2016 at 9:05 AM, Joseph Mundy <mu...@le...> wrote:

> So far I haven’t seen any big problems except for issues with python_d,
> maybe that is what Dave is referring to. I didn’t see Dave’s post.
>
> Joe
>
>
>
> *From:* Johnson, Hans J [mailto:han...@ui...]
> *Sent:* Thursday, March 10, 2016 8:27 AM
> *To:* David Stoup
> *Cc:* Joseph Mundy; vxl...@li...;
> vxl...@li...; Vishal Jain
>
> *Subject:* Re: [Vxl-maintainers] BRL status on Windows
>
>
>
> I hope that someone else can take on the challenge of making python work
> on windows.  That is far beyond my comfort level.
>
>
>
>
>
> --
>
>
>
>
>
> *From: *David Stoup <dav...@ki...>
> *Date: *Thursday, March 10, 2016 at 7:07 AM
> *To: *Hans Johnson <han...@ui...>
> *Cc: *Joseph Mundy <mu...@le...>, "
> vxl...@li..." <vxl...@li...>, "
> vxl...@li..." <
> vxl...@li...>, Vishal Jain <
> vi...@vi...>
> *Subject: *Re: [Vxl-maintainers] BRL status on Windows
>
>
>
> Aside from what's mentioned above, the issue I have building BRL on
> Windows is with Python enabled in a debug build. VTK has a decent solution
> to the problem. I wrote up an issue several months ago.
>
>
>
> On Thu, Mar 10, 2016 at 7:57 AM, Johnson, Hans J <han...@ui...>
> wrote:
>
> Joseph,
>
>
>
> I am not a native windows developer, if you could assist with finding that
> build issue on windows, it will free me to work on other tasks more suited
> to my skills.
>
>
>
> Thanks,
>
> Hans
>
>
>
> --
>
>
>
>
>
> *From: *Joseph Mundy <mu...@le...>
> *Date: *Thursday, March 10, 2016 at 6:47 AM
> *To: *Hans Johnson <han...@ui...>, "
> vxl...@li..." <vxl...@li...>, "
> vxl...@li..." <
> vxl...@li...>, Vishal Jain <
> vi...@vi...>
> *Subject: *RE: [Vxl-maintainers] BRL status on Windows
>
>
>
> Hans,
>
> I currently run VS2012.
>
> We will take a look as well. I agree the issue is probably to do with the
> expat CMake find process.
>
> Thanks,
>
> Joe
>
> *From:* Johnson, Hans J [mailto:han...@ui...
> <han...@ui...>]
> *Sent:* Thursday, March 10, 2016 7:33 AM
> *To:* Joseph Mundy; vxl...@li...;
> vxl...@li...
> *Subject:* Re: [Vxl-maintainers] BRL status on Windows
>
>
>
> Joseph,
>
>
>
> Can you describe your windows build environment?  VS2010?
>
>
>
> Regarding Expat,  that will require some digging.  There were changes made
> to the FindExpat, and there are currently issues reported regarding
> problems with the way that FindExpat and FindExpatpp are looking for their
> files.
>
>
>
> I’ll have a look at this over the next few weeks.
>
>
>
> Hans
>
>
>
> --
>
>
>
>
>
> *From: *Joseph Mundy <mu...@le...>
> *Date: *Thursday, March 10, 2016 at 4:53 AM
> *To: *Hans Johnson <han...@ui...>, "
> vxl...@li..." <vxl...@li...>, "
> vxl...@li..." <
> vxl...@li...>
> *Subject: *RE: [Vxl-maintainers] BRL status on Windows
>
>
>
> Hans,
>
> Yes. I have been working with brl on windows for years. But the recent
> master branch is horribly broken on windows due to issues with expat and
> expatpp. The bulk of the errors are due to missing expat symbols. Do you
> know of some change that would affect expat?
>
> Thanks,
>
> Joe
>
>
>
> *From:* Johnson, Hans J [mailto:han...@ui...
> <han...@ui...>]
> *Sent:* Wednesday, March 9, 2016 8:56 PM
> *To:* vxl...@li...;
> vxl...@li...
> *Subject:* [Vxl-maintainers] BRL status on Windows
>
>
>
> BRL team,
>
>
>
> Is the contrib/brl directory expected to compile on windows?
>
>
>
> There are a tremendous number of compiler errors and warnings being
> generated.
>
>
>
> Hans
>
>
>
>
>
>
>
> ========================================================================
>
> | Hans J. Johnson, Ph.D.,  Associate Professor                         |
>
> | Appointments:                                                        |
>
> |   - Electrical and Computer Engineering (Primary)                    |
>
> |   - Biomedical Engineering                                           |
>
> |   - Psychiatry                                     ,NMMM~            |
>
> |   - Health Informatics                         MMMMMMMMMMMMMMN       |
>
> |   - Iowa Institute for Biomedical Imaging    MMMMMMMMMMMMMMMMMMM     |
>
> |   - Iowa Informatics Institute             MMMMMMMMMMM MMMM MMM      |
>
> |                                            MMMMMMMMMM I ?MMM  MM M   |
>
> | han...@ui...                     MMMMMMM ,$M,        MMMM  |
>
> | (319) 621 7185 (cell)                        MMMM~     MMMM   MMMMMM |
>
> | (319) 384 3538  ECE Phone (Primary)           MM    8MMMMMM       MM |
>
> |                                               M    MMMMMMM, ,M~    M |
>
> | 4316 Seamans Center                                MMMMMM     MM     |
>
> | Iowa City, IA 52242                                 ,?               |
>
> ========================================================================
>
> http://emailcharter.org
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>
>
>
> --
>
> David Stoup
> R&D Engineer
>
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY. 12065
> 518-881-4949 (W)
>
> 518-312-3946 (M)
>
> 518-371-4573 (F)
>



-- 
David Stoup
R&D Engineer

Kitware, Inc.
28 Corporate Drive
Clifton Park, NY. 12065
518-881-4949 (W)
518-312-3946 (M)
518-371-4573 (F)

So far I haven’t seen any big problems except for issues with python_d, maybe that is what Dave is referring to. I didn’t see Dave’s post.

Joe

 

From: Johnson, Hans J [mailto:han...@ui...] 
Sent: Thursday, March 10, 2016 8:27 AM
To: David Stoup
Cc: Joseph Mundy; vxl...@li...; vxl...@li...; Vishal Jain
Subject: Re: [Vxl-maintainers] BRL status on Windows

 

I hope that someone else can take on the challenge of making python work on windows.  That is far beyond my comfort level.

 

 

-- 

 

 

From: David Stoup <dav...@ki...>
Date: Thursday, March 10, 2016 at 7:07 AM
To: Hans Johnson <han...@ui...>
Cc: Joseph Mundy <mu...@le...>, "vxl...@li..." <vxl...@li...>, "vxl...@li..." <vxl...@li...>, Vishal Jain <vi...@vi...>
Subject: Re: [Vxl-maintainers] BRL status on Windows

 

Aside from what's mentioned above, the issue I have building BRL on Windows is with Python enabled in a debug build. VTK has a decent solution to the problem. I wrote up an issue several months ago.

 

On Thu, Mar 10, 2016 at 7:57 AM, Johnson, Hans J <han...@ui...> wrote:

Joseph,

 

I am not a native windows developer, if you could assist with finding that build issue on windows, it will free me to work on other tasks more suited to my skills.

 

Thanks,

Hans

 

-- 

 

 

From: Joseph Mundy <mu...@le...>
Date: Thursday, March 10, 2016 at 6:47 AM
To: Hans Johnson <han...@ui...>, "vxl...@li..." <vxl...@li...>, "vxl...@li..." <vxl...@li...>, Vishal Jain <vi...@vi...>
Subject: RE: [Vxl-maintainers] BRL status on Windows

 

Hans,

I currently run VS2012.

We will take a look as well. I agree the issue is probably to do with the expat CMake find process. 

Thanks,

Joe

From: Johnson, Hans J [mailto:han...@ui...] 
Sent: Thursday, March 10, 2016 7:33 AM
To: Joseph Mundy; vxl...@li...; vxl...@li...
Subject: Re: [Vxl-maintainers] BRL status on Windows

 

Joseph,

 

Can you describe your windows build environment?  VS2010?

 

Regarding Expat,  that will require some digging.  There were changes made to the FindExpat, and there are currently issues reported regarding problems with the way that FindExpat and FindExpatpp are looking for their files.

 

I’ll have a look at this over the next few weeks.

 

Hans

 

-- 

 

 

From: Joseph Mundy <mu...@le...>
Date: Thursday, March 10, 2016 at 4:53 AM
To: Hans Johnson <han...@ui...>, "vxl...@li..." <vxl...@li...>, "vxl...@li..." <vxl...@li...>
Subject: RE: [Vxl-maintainers] BRL status on Windows

 

Hans,

Yes. I have been working with brl on windows for years. But the recent master branch is horribly broken on windows due to issues with expat and expatpp. The bulk of the errors are due to missing expat symbols. Do you know of some change that would affect expat?

Thanks,

Joe 

 

From: Johnson, Hans J [mailto:han...@ui...] 
Sent: Wednesday, March 9, 2016 8:56 PM
To: vxl...@li...; vxl...@li...
Subject: [Vxl-maintainers] BRL status on Windows

 

BRL team,

 

Is the contrib/brl directory expected to compile on windows?

 

There are a tremendous number of compiler errors and warnings being generated.

 

Hans

 

 

 

========================================================================

| Hans J. Johnson, Ph.D.,  Associate Professor                         |

| Appointments:                                                        |

|   - Electrical and Computer Engineering (Primary)                    |

|   - Biomedical Engineering                                           |

|   - Psychiatry                                     ,NMMM~            |

|   - Health Informatics                         MMMMMMMMMMMMMMN       |

|   - Iowa Institute for Biomedical Imaging    MMMMMMMMMMMMMMMMMMM     |

|   - Iowa Informatics Institute             MMMMMMMMMMM MMMM MMM      |

|                                            MMMMMMMMMM I ?MMM  MM M   |

| han...@ui...                     MMMMMMM ,$M,        MMMM  |

| (319) 621 7185 <tel:%28319%29%20621%207185>  (cell)                        MMMM~     MMMM   MMMMMM |

| (319) 384 3538 <tel:%28319%29%20384%203538>   ECE Phone (Primary)           MM    8MMMMMM       MM |

|                                               M    MMMMMMM, ,M~    M |

| 4316 Seamans Center                                MMMMMM     MM     |

| Iowa City, IA 52242                                 ,?               |

========================================================================

http://emailcharter.org


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111 <http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140> &iu=/4140
_______________________________________________
Vxl-maintainers mailing list
Vxl...@li...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers




-- 

David Stoup
R&D Engineer

Kitware, Inc.
28 Corporate Drive
Clifton Park, NY. 12065
518-881-4949 (W)

518-312-3946 (M)

518-371-4573 (F)

Aside from what's mentioned above, the issue I have building BRL on Windows
is with Python enabled in a debug build. VTK has a decent solution to the
problem. I wrote up an issue several months ago.

On Thu, Mar 10, 2016 at 7:57 AM, Johnson, Hans J <han...@ui...>
wrote:

> Joseph,
>
> I am not a native windows developer, if you could assist with finding that
> build issue on windows, it will free me to work on other tasks more suited
> to my skills.
>
> Thanks,
> Hans
>
> --
>
>
> From: Joseph Mundy <mu...@le...>
> Date: Thursday, March 10, 2016 at 6:47 AM
> To: Hans Johnson <han...@ui...>, "
> vxl...@li..." <vxl...@li...>, "
> vxl...@li..." <
> vxl...@li...>, Vishal Jain <
> vi...@vi...>
> Subject: RE: [Vxl-maintainers] BRL status on Windows
>
> Hans,
>
> I currently run VS2012.
>
> We will take a look as well. I agree the issue is probably to do with the
> expat CMake find process.
>
> Thanks,
>
> Joe
>
> *From:* Johnson, Hans J [mailto:han...@ui...
> <han...@ui...>]
> *Sent:* Thursday, March 10, 2016 7:33 AM
> *To:* Joseph Mundy; vxl...@li...;
> vxl...@li...
> *Subject:* Re: [Vxl-maintainers] BRL status on Windows
>
>
>
> Joseph,
>
>
>
> Can you describe your windows build environment?  VS2010?
>
>
>
> Regarding Expat,  that will require some digging.  There were changes made
> to the FindExpat, and there are currently issues reported regarding
> problems with the way that FindExpat and FindExpatpp are looking for their
> files.
>
>
>
> I’ll have a look at this over the next few weeks.
>
>
>
> Hans
>
>
>
> --
>
>
>
>
>
> *From: *Joseph Mundy <mu...@le...>
> *Date: *Thursday, March 10, 2016 at 4:53 AM
> *To: *Hans Johnson <han...@ui...>, "
> vxl...@li..." <vxl...@li...>, "
> vxl...@li..." <
> vxl...@li...>
> *Subject: *RE: [Vxl-maintainers] BRL status on Windows
>
>
>
> Hans,
>
> Yes. I have been working with brl on windows for years. But the recent
> master branch is horribly broken on windows due to issues with expat and
> expatpp. The bulk of the errors are due to missing expat symbols. Do you
> know of some change that would affect expat?
>
> Thanks,
>
> Joe
>
>
>
> *From:* Johnson, Hans J [mailto:han...@ui...
> <han...@ui...>]
> *Sent:* Wednesday, March 9, 2016 8:56 PM
> *To:* vxl...@li...;
> vxl...@li...
> *Subject:* [Vxl-maintainers] BRL status on Windows
>
>
>
> BRL team,
>
>
>
> Is the contrib/brl directory expected to compile on windows?
>
>
>
> There are a tremendous number of compiler errors and warnings being
> generated.
>
>
>
> Hans
>
>
>
>
>
>
>
> ========================================================================
>
> | Hans J. Johnson, Ph.D.,  Associate Professor                         |
>
> | Appointments:                                                        |
>
> |   - Electrical and Computer Engineering (Primary)                    |
>
> |   - Biomedical Engineering                                           |
>
> |   - Psychiatry                                     ,NMMM~            |
>
> |   - Health Informatics                         MMMMMMMMMMMMMMN       |
>
> |   - Iowa Institute for Biomedical Imaging    MMMMMMMMMMMMMMMMMMM     |
>
> |   - Iowa Informatics Institute             MMMMMMMMMMM MMMM MMM      |
>
> |                                            MMMMMMMMMM I ?MMM  MM M   |
>
> | han...@ui...                     MMMMMMM ,$M,        MMMM  |
>
> | (319) 621 7185 (cell)                        MMMM~     MMMM   MMMMMM |
>
> | (319) 384 3538  ECE Phone (Primary)           MM    8MMMMMM       MM |
>
> |                                               M    MMMMMMM, ,M~    M |
>
> | 4316 Seamans Center                                MMMMMM     MM     |
>
> | Iowa City, IA 52242                                 ,?               |
>
> ========================================================================
>
> http://emailcharter.org
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>


-- 
David Stoup
R&D Engineer

Kitware, Inc.
28 Corporate Drive
Clifton Park, NY. 12065
518-881-4949 (W)
518-312-3946 (M)
518-371-4573 (F)

I hope that someone else can take on the challenge of making python work on windows.  That is far beyond my comfort level.


--


From: David Stoup <dav...@ki...<mailto:dav...@ki...>>
Date: Thursday, March 10, 2016 at 7:07 AM
To: Hans Johnson <han...@ui...<mailto:han...@ui...>>
Cc: Joseph Mundy <mu...@le...<mailto:mu...@le...>>, "vxl...@li...<mailto:vxl...@li...>" <vxl...@li...<mailto:vxl...@li...>>, "vxl...@li...<mailto:vxl...@li...>" <vxl...@li...<mailto:vxl...@li...>>, Vishal Jain <vi...@vi...<mailto:vi...@vi...>>
Subject: Re: [Vxl-maintainers] BRL status on Windows

Aside from what's mentioned above, the issue I have building BRL on Windows is with Python enabled in a debug build. VTK has a decent solution to the problem. I wrote up an issue several months ago.

On Thu, Mar 10, 2016 at 7:57 AM, Johnson, Hans J <han...@ui...<mailto:han...@ui...>> wrote:
Joseph,

I am not a native windows developer, if you could assist with finding that build issue on windows, it will free me to work on other tasks more suited to my skills.

Thanks,
Hans

--


From: Joseph Mundy <mu...@le...<mailto:mu...@le...>>
Date: Thursday, March 10, 2016 at 6:47 AM
To: Hans Johnson <han...@ui...<mailto:han...@ui...>>, "vxl...@li...<mailto:vxl...@li...>" <vxl...@li...<mailto:vxl...@li...>>, "vxl...@li...<mailto:vxl...@li...>" <vxl...@li...<mailto:vxl...@li...>>, Vishal Jain <vi...@vi...<mailto:vi...@vi...>>
Subject: RE: [Vxl-maintainers] BRL status on Windows

Hans,
I currently run VS2012.
We will take a look as well. I agree the issue is probably to do with the expat CMake find process.
Thanks,
Joe
From: Johnson, Hans J [mailto:han...@ui...]
Sent: Thursday, March 10, 2016 7:33 AM
To: Joseph Mundy; vxl...@li...<mailto:vxl...@li...>; vxl...@li...<mailto:vxl...@li...>
Subject: Re: [Vxl-maintainers] BRL status on Windows

Joseph,

Can you describe your windows build environment?  VS2010?

Regarding Expat,  that will require some digging.  There were changes made to the FindExpat, and there are currently issues reported regarding problems with the way that FindExpat and FindExpatpp are looking for their files.

I’ll have a look at this over the next few weeks.

Hans

--


From: Joseph Mundy <mu...@le...<mailto:mu...@le...>>
Date: Thursday, March 10, 2016 at 4:53 AM
To: Hans Johnson <han...@ui...<mailto:han...@ui...>>, "vxl...@li...<mailto:vxl...@li...>" <vxl...@li...<mailto:vxl...@li...>>, "vxl...@li...<mailto:vxl...@li...>" <vxl...@li...<mailto:vxl...@li...>>
Subject: RE: [Vxl-maintainers] BRL status on Windows

Hans,
Yes. I have been working with brl on windows for years. But the recent master branch is horribly broken on windows due to issues with expat and expatpp. The bulk of the errors are due to missing expat symbols. Do you know of some change that would affect expat?
Thanks,
Joe

From: Johnson, Hans J [mailto:han...@ui...]
Sent: Wednesday, March 9, 2016 8:56 PM
To: vxl...@li...<mailto:vxl...@li...>; vxl...@li...<mailto:vxl...@li...>
Subject: [Vxl-maintainers] BRL status on Windows

BRL team,

Is the contrib/brl directory expected to compile on windows?

There are a tremendous number of compiler errors and warnings being generated.

Hans




========================================================================

| Hans J. Johnson, Ph.D.,  Associate Professor                         |

| Appointments:                                                        |

|   - Electrical and Computer Engineering (Primary)                    |

|   - Biomedical Engineering                                           |

|   - Psychiatry                                     ,NMMM~            |

|   - Health Informatics                         MMMMMMMMMMMMMMN       |

|   - Iowa Institute for Biomedical Imaging    MMMMMMMMMMMMMMMMMMM     |

|   - Iowa Informatics Institute             MMMMMMMMMMM MMMM MMM      |

|                                            MMMMMMMMMM I ?MMM  MM M   |

| han...@ui...<mailto:han...@ui...>                     MMMMMMM ,$M,        MMMM  |

| (319) 621 7185<tel:%28319%29%20621%207185> (cell)                        MMMM~     MMMM   MMMMMM |

| (319) 384 3538<tel:%28319%29%20384%203538>  ECE Phone (Primary)           MM    8MMMMMM       MM |

|                                               M    MMMMMMM, ,M~    M |

| 4316 Seamans Center                                MMMMMM     MM     |

| Iowa City, IA 52242                                 ,?               |

========================================================================

http://emailcharter.org

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Vxl-maintainers mailing list
Vxl...@li...<mailto:Vxl...@li...>
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers




--
David Stoup
R&D Engineer

Kitware, Inc.
28 Corporate Drive
Clifton Park, NY. 12065
518-881-4949 (W)
518-312-3946 (M)
518-371-4573 (F)