From: Nicolas B. <nic...@en...> - 2005-06-13 21:00:16
Attachments:
structuring_element.patch
|
Hi, I've found useful to add two utility functions to create in a convenient and efficient way (at the cost of two static objects in vil_algo) the most usual structuring elements : a cross (c4) and a square (c8). Maybe you will find then useful enough to be integrated, personnally I hate creating temporary variables for this kind of usual parameters :-) Regards, -- Nicolas Burrus |
From: Joseph L M. <mu...@le...> - 2005-06-14 10:57:52
|
Nicolas, The usual way to proceed with significantly modifying a core library is to ask the responsible developer (I think in the case of vil, that is Ian Scott) for an opinion on the suggested change. I think for minor improvements like this one can just go ahead and make the change. There isn't really any mechanism for staged integration. Joe -----Original Message----- From: vxl...@li... [mailto:vxl...@li...] On Behalf Of Nicolas Burrus Sent: Monday, June 13, 2005 5:00 PM To: vxl...@li... Subject: [Vxl-maintainers] Usual structuring elements Hi, I've found useful to add two utility functions to create in a convenient and efficient way (at the cost of two static objects in vil_algo) the most usual structuring elements : a cross (c4) and a square (c8). Maybe you will find then useful enough to be integrated, personnally I hate creating temporary variables for this kind of usual parameters :-) Regards, -- Nicolas Burrus |
From: Ian S. <ian...@st...> - 2005-06-14 11:25:20
|
Nicolas Burrus wrote: > Hi, > > I've found useful to add two utility functions to create in a convenient and > efficient way (at the cost of two static objects in vil_algo) the most usual > structuring elements : a cross (c4) and a square (c8). I think vil_algo_structuring_element c4,c8; c4.set_to_disk(1.1); c8.set_to_disk(1.5); will have the same effect. > Maybe you will find > then useful enough to be integrated, personnally I hate creating temporary > variables for this kind of usual parameters :-) I don't have any strong opinions on the matter, as its a relatively minor change. I'm usually a little suspicious of static objects - since I'm worried that we're all going to have to write multithreaded code in the near future. Do you want write access to the repository? You seem to have grasped to quality levels we expect for the core libraries. Send your Sourceforge account name to the list along with a description of your interest in VXL, and the kind of work you do, and we'll give you access. Ian. |
From: Nicolas B. <nic...@en...> - 2005-06-15 11:02:10
|
On Tuesday 14 June 2005 13:25, Ian Scott wrote: > > Do you want write access to the repository? You seem to have grasped to > quality levels we expect for the core libraries. Send your Sourceforge > account name to the list along with a description of your interest in > VXL, and the kind of work you do, and we'll give you access. I would be glad to contribute to vxl more easily, and to stop bothering the list with minor changes twice a week :-) My account name is nburrus. I'm mainly working on salient structures detection in images and sequences, with a focus on statististically founded methods. I'm actually creating a global scriptable framework including various visualization and processing algorithms, but relying when possible on existing libraries such as vxl, megawave, boost or QT to do most of the job. So I will certainly write some code that is general enough to fit into vil, vgui and maybe vidl in the future. Maybe some less fundamental imaging code could go in a contrib library. I will also work on Python bindings, but I don't know if this should be integrated into the vxl package though. Thanks, -- Nicolas |
From: Ian S. <ian...@st...> - 2005-06-21 08:52:48
|
Nicolas Burrus wrote: > My account name is nburrus. I've added you to the developer list. All the usual warnings apply, but the most important are 1. Make sure the code builds and tests on your platform before submitting. 2. If the Dashboard sends you an email that refers to code you wrote or modified, please fix it ASAP. 3. Keep an eye on the dashboard to make sure your code isn't producing warnings, or other problems. 4. Keep an eye on the vxl-maintainers and vxl-users lists. As for modifications to core. We generally run all proposed changes to core past the vxl-maintainers list. However, fixes for bugs, compiler errors and warnings can be fixed quietly. Welcome to VXL maintainers. Ian. |
From: Peter V. <pet...@ya...> - 2005-06-15 15:40:56
|
I'm also normally somewhat suspicious of static objects. Didn't we "decide" to avoid those things in core vxl? This said, there is maybe an other way of creating those two objects, e.g. through two dedicated functions (or even two methods) or maybe even one function that takes one of the textual arguments "cross" or "square". Or even through a dedicated constructor taking those values as parameter? -- Peter. |