zuloloxi / aforge

Automatically exported from code.google.com/p/aforge
Other
0 stars 0 forks source link

Add a more generic ICornersDetector interface #305

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
There is a specific interface named ICornersDetector in the AForge.NET, which 
has methods to return List<IntPoint>.

Most Corner Detector have their own data like scale and orientation, and their 
coordinates' type are usually float for sub-pixel precision.

So maybe add a more generic ICornersDetector<TPoint> is suitable for above 
situation:

public interface ICornersDetector<TPoint> : ICornersDetector
{
    List<TPoint> ProcessImage(UnmamagedImage image);
}

Original issue reported on code.google.com by pan...@gmail.com on 20 Jun 2012 at 7:31

GoogleCodeExporter commented 8 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
>> 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

GoogleCodeExporter commented 8 years ago
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