UniqueTol Exclusion of Similar Points

I am trying to remove detected circles that are too close to one another. My original plan involved indexing through all of the centers (X Y stored in separate columns), determining the distances, and then using those to remove points within a tolerance.

for nn=1:height(location_table)
distances=sqrt(((location_table(nn,1) - location_table(:,1)).^2)+((location_table(nn,2) - location_table(:,2)).^2))
too_close=(0<distances & distances<tolerance);
location_table(too_close,:)=[]
end

I was never able to get the removal to work. It would end up breaking if spots were removed because the index nn would eventually get larger than the current table height.

I discovered the uniquetol command when searching for answers. However, in my use of it, it filters out spots that are not unique (ie, within the tolerance). However, I would want it to remove spots that all spots that are too similar (rather than leaving a representative one behind).

location_table=uniquetol(location_table, closeness_tolerance, 'ByRows', true, 'OutputAllIndices', true, 'DataScale',1);

I plan to do radial intensity line scans starting at the center of all circles (and proceeding past their perimeter by a variable) that make it through this filtering process. If spots are too close, then the scan (improfile) will cross over the border of the intended scan as well as a spot that is too close to it (which will skew the data). For example, circle 4 should be excluded because it is too close to other circles and its scans could be skewed. Uniquetold allowed me to exclude the nearby circles but 4 would ideally not be included either.

Answer 1

[dpb]

"...end up breaking if spots were removed because the index nn would eventually get larger than the current table height."

for nn=1:height(location_table)
  distances=sqrt((location_table(nn,1)-location_table(:,1)).^2+(location_table(nn,2)-location_table(:,2)).^2);
  too_close=(0<distances & distances<tolerance);
  location_table(too_close,:)=[]
end

The problem as you've discovered is that when you remove one or more rows, the height is reduced and so can't iterate over the original height any longer. The trick in these cases is to not actually delete the row(s) but mark them as deleted in an auxiliary variable; then when done, remove the marked rows.

N=height(location_table);                                       
marktodelete=false(N,1);                                        % preallocate flag array to delete
for nn=1:N
  distances=pdist2(location_table,location_table(nn,:));        % calculates pairwise distance for you
  too_close=(distances>0 & distances<tolerance);
  marktodelete=marktodelete | too_close;                        % update the flag array
end
location_table(marktodelete,:)=[];    % or location_table=location_table(~marktodelete,:); % keep not marked

However, wouldn't you want to delete the zero-distance ones as well based on your description if there is more than one element in thee too_close vector on each pass?

With uniquetol, you've change the search criterion to be based on each x,y being within a tolerance rather than the overall distance if that matters to you.

Without a representative dataset to play with, and being too lazy to try to create one <vbg>, I think you would need two steps -- keep the list of unique points as have and then locate any left that are within that same tolerance. To do that you've got to generate a new locations list for the remaining and then compare those to the pared list.

[Brett]

Hi, thanks for the response. Several things, when attempting the pdist2 version it is throwing an error:

"X and Y must have the same number of columns."

"[varargout{1:nargout}] = statslib.internal.pdist2(X,Y,varargin{:});"

When I switch back to my full typed version of the distance to test the rest of the code, it instead throws a new error later on. It seems in the process, the location table has been reduced to a single column of values. It seems like it removed out the x coordinates, but pasted out all y coordinates at the end in a single column (including the corresponding values that should have been removed).

Based on my initial method, the distance of 0 would be the distance from the point to itself. So I would think I want that removed or it would end up removing every last point. Hence the inclusion of the "distances>0" section in the conditional.

As far as the uniquetol, I was trying to do it based on the absolute pixel distance but I may have inadveratntyly changed it to a tolerance (I defined the closeness_tolerance as the exact pixel distance).

    location_table_input
    1.1905    0.2750
    0.6275    0.9874
    0.0949    0.2843
    0.9806    0.4360
    0.6296    0.6348
    1.4487    1.2308
    0.8683    1.9483
    0.7051    0.6294
    0.7334    0.6926
    1.9345    1.8027
    0.1305    1.9503
    
    
    location_table_output
    1.1905
    0.6275
    0.0949
    0.9806
    1.4487
    0.8683
    1.9345
    0.1305
    0.2750
    0.9874
    0.2843
    0.4360
    0.6348
    1.2308
    1.9483
    0.6294
    0.6926
    1.8027
    1.9503

[dpb]

"X and Y must have the same number of columns."

Yeah, my bad; there's a typo (fixed above), but

  distances=pdist2(location_table,location_table(nn,1));        % calculates pairwise distance for you

should be

    distances=pdist2(location_table,location_table(nn,:));        % calculates pairwise distance for you

"Based on my initial method, the distance of 0 would be the distance from the point to itself. ..."

Yes, but your complaint with uniquetol was that it left circle 4 after removing its neighbors.

If you want the same behavior with the distance, then if there are distance elements other than zero in each test, then the zero distance will be that one. Oh....but then you need your loop to be somewhat more intelligent so that it doesn't iterate over every element but then also skips those which have been marked for removal so you don't find the same group looking at the neighbors in turn.

Is there some way to a priori identify the base circles so that they could be selected as the iterated-over ones or are they all the same to start with?

You don't say how you found the circles; one alternative might be to instead of the x,y coordinates, return the centroid of each, thus reducing it to a 1D problem.

[Brett]

I found the circles with a simple imfindcircles with some adjustments to size, sensitivity, and edge. I have gotten your code suggestion to work with one minor adjustment. I was still having the issue with not removing the valeus from the y column and the concatenating like rearragnement of the array. The adjustment is below. Thank you for your assistance.

Original

location_table(marktodelete)=[]

becomes

location_table(marktodelete,:)=[]

[dpb]

Ah, yes! Again "air code" and forgot the second dimension...I should have recognized that.

One improvement would be to check if the element

location_table(nn,:)

in the loop has already been marked for deletion in a prior loop and if so, continue because it is in a group already identified. Oh! not having that is what will remove the zero-distance one -- when look at it from one of the others that will have been in the same group, then the first one that was in the group won't be the zero-distance one any more.

Unless the list is exceedingly long, the extra work probably isn't noticeable.