octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SOCIS] Your project has been selected


From: Juan Pablo Carbajal
Subject: Re: [SOCIS] Your project has been selected
Date: Mon, 22 Jul 2013 20:19:17 +0200

On Mon, Jul 22, 2013 at 5:30 PM, Carnë Draug <address@hidden> wrote:
> On 22 July 2013 07:08, Dennis Liu <address@hidden> wrote:
>> On Sun, Jul 21, 2013 at 4:45 PM, Carnë Draug <address@hidden> wrote:
>>> On 20 July 2013 14:50, Dennis Liu <address@hidden> wrote:
>>>> Is it too late to apply SOCIS 2013 as a student now?
>>>
>>> No. Not at all. Applications just started.
>>>
>>>> [...]
>>>>
>>>> Being as a user, I have a similar background and co-interest to one of
>>>> the Octave active developers (I have read his googlesummer plan here:
>>>> http://www.google-melange.com/gsoc/project/google/gsoc2013/carandraug/17001).
>>>> I am a student in Europe, heavily using microscopy and image analysis
>>>> for life science. So I am wondering if there is any potential work I
>>>> could do with the ND- image package. Or else? I am happy to start with
>>>> any image processing or graphics topics. Could anyone give me any
>>>> suggestion, please?
>>>
>>> If you want to work on supporting ND images, you could work on the
>>> functions for image registration and geometric transformation. I have
>>> also though about creating an ND image class, something that allows
>>> indexing with channel or wavelength names for example. Those are
>>> things that are not part of my project but I'm unsure if they're
>>> enough work for another full proposal.
>>>
>>> We have a list of the stuff missing in the image package [1], Octave
>>> projects [2], and GSoC project ideas [3].
>>>
>>> Some simpler things that may help you in getting started (from my todo
>>> list of stuff that is not in my GSoC project) are:
>>>
>>> * ND support in padarray (seems to already be working. Test and document)
>>> * implement bwareaopen (should be very easy. Possibly making use of 
>>> bwconncomp)
>>> * make the Hough transform functions matlab compatible
>>>
>>> Carnë
>>>
>>> [1] http://wiki.octave.org/Image_package
>>> [2] http://wiki.octave.org/Projects
>>> [3] http://wiki.octave.org/GSoC_Project_Ideas
>>
>> Hi guys,
>>
>> Thanks a lot for all of your support.
>>
>> Carnë, I guess I could start with functions for image registration and
>> geometric transformation. I am also interested in other things you
>> mentioned to me. If I really decide to work on these, I will discuss
>> with you first.
>>
>> From the list([1] http://wiki.octave.org/Image_package), I found there
>> were quite some functions yet to be implemented in the image package.
>> Are they all very necessary? What is the priority? How do we decide
>> which one to implement in general? It's driven by needs?
>
> The priority is what you want to do, be it driven by fun or need. At
> least for the image package we do not keep a development roadmap.
>
> The list on the wiki page is the complete list of functions that we
> are missing. Some are missing because they're just not possible with
> the current features of Octave. See imcontrast or roipoly for example.
> Others are missing because they are too easy to write, so those who
> need them write their own code rather than report them as missing or
> contribute them. For example, the functions im2single and im2int16
> were only implemented last year despite being among the simplest
> functions we have in the package. Indeed, even in code written for
> matlab it's more common to see "double (img)/255" than "im2double
> (img)", despite the fact that the second will work correctly for any
> type of input image.
>
> Anyway, moral of the story is, work in whatever you want to. You use
> Octave in your own work, what are your needs? It can even be things
> that do not exist in Matlab. For example, I wanted the multiple
> automatic threshold algorithms that have been implemented in ImageJ
> but Matlab only has Otsu's. I added them anyway as an optional
> argument to graythresh.
>
> Carnë

I would like to add that there is hidden bug somewhere in bwlabel,
bwmorph or regionprops.
To see the effect check the geometry package folder
/geometry/devel/Demos/curvedGraph/calcCurves.m

Note that the function will give you debug console. You can write

dbcont

and then press enter through all the intermediate fits. The final
image is the result, that is far from the expected one, which can be
found in the html subfolder in /geometry/devel/Demos/curvedGraph/  .

Note that I thought it may have been an issue with the
polynomialCurveFit (which was adapted from Matlab's cause there it
uses the optimization toolbox), but it passes my tests and the demo
looks fine. Also if you look at the intermediate fits during the
calcCurves function, you will see that some centroids are completely
off, I guess that is an bwlabel issue.

Cheers


reply via email to

[Prev in Thread] Current Thread [Next in Thread]