Open GoogleCodeExporter opened 9 years ago
>> Most Corner Detector have their own data like scale and orientation,
I would say this about Feature Detectors ...
>> and their coordinates' type are usually float for sub-pixel
Changing integers to float is an easy change.
>> So maybe add a more generic ICornersDetector<TPoint> is suitable
>> for above situation:
What about polymorphism then? Imagine a have a method, which takes corner
detector (or maybe feature detector) as parameter, applies it to some image and
then wants to go through every point of interest (it does not care about
scale/orientation/whatever, for example). Such method could be defined
something like
void UseDector( IDetector ).
Since you make interface generic, such scenario will not work. Another usage
scenario: suppose someone wants to have list of detectors. He could do so by
doing
List<IDetector> detectors = new List<IDetector>( );
Again it will not work.
Original comment by andrew.k...@gmail.com
on 20 Jun 2012 at 1:43
Hello there,
I would also be interested in something like this. What about adding two new
interfaces:
interface IPoint
interface ICornersDetector<out TPoint> where TPoint : IPoint
Then mark IntPoint as implementing IPoint:
struct IntPoint : IPoint
Then redefine the plain ICornersDetector to be
interface ICornersDetector : ICornersDetector<IntPoint>
Now we can list generic detectors with List<ICornersDetector<IPoint>> or plain
detectors as List<ICornersDetector>
We can also have a method which takes a corner detector with
void UseDetector(ICornersDetector detector)
and it can even implement a more specialized overload in case the user gives a
more elaborate detector:
void UseDetector(ICornersDetector<SomeElaborateFeatureType> detector)
Can you see more flaws? If it doesn't seems fine perhaps we can think of
something else.
Regards,
Cesar
Original comment by cesarso...@gmail.com
on 21 Jun 2012 at 12:09
>> interface ICornersDetector<out TPoint> where TPoint : IPoint
Covariant parameters seem to be .NET 4.0 feature, which we still did not
convert to. Will see what we can do.
Original comment by andrew.k...@gmail.com
on 21 Jun 2012 at 9:48
I think it would work even without the covariant parameter, wouldn't it? It was
just for future reference. I also didn't test this design, it was just an idea.
Perhaps another idea would be to add an interface specific to feature detectors
and don't mess with the ICornersDetector at all. Or even leave it as it is.
In Accord, to overcome this problem, I resorted to explicit interface
implementation:
https://code.google.com/p/accord/source/browse/trunk/Sources/Accord.Imaging/Inte
rest%20Points/SpeededUpRobustFeaturesDetector.cs
The mechanism involves implementing the ICornersDetector.ProcessImage
explicitly:
List<IntPoint> ICornersDetector.ProcessImage(UnmanagedImage image)
{
...
}
So I can define my own ProcessImage without conflicting with ICornersDetector's
requirements
public List<SurfPoint> ProcessImage(UnmanagedImage image)
{
...
}
This approach works without interface changes and without requiring generics.
But it may be somewhat confusing if one is not familiar with the technique.
Original comment by cesarso...@gmail.com
on 21 Jun 2012 at 3:08
Original issue reported on code.google.com by
pan...@gmail.com
on 20 Jun 2012 at 7:31