05-21-2010 06:18 AM
Hi,
I have problem with Geometric Pattern Matching (=GPM).
In a grey scale 8 bit picture of a glass panel I am looking for an edge of glass panel. The dominating colours are black (0) and white (255).
Template for the matching is extracted from the original picture of the glass panel.
The resolution of the original picture is 4096 x 5000 pixels (from 4k line scan camera).
If I work with 10x reduced pictures (410x500 pixels) the GPM works fine, finds the edge reliable
BUT if I work in full
resolution pixture, exactly the same, before reduction of resolution, I get number of matches = ZERO.
I am working in LV 7.1 and Vision Dev. Tools 7.1.
I don’t change any parameters of "learning" or "matching" or any others between tests with full resolution pictures and 10x smaller resolution pictures.
Thickness of the matched contur line is 13-15 pixels. Length of the mateched line is about 5000-6000 pixels.
I get no errors duering tests with full resolution pictures but the result is wrong. Time is no issue.
Is there any limitation or known issues in using GPM with big pictures (10-20 MB) ?
Thank you for any ideas or support
Marek_K
Solved! Go to Solution.
05-21-2010 07:06 AM
05-21-2010 07:19 AM
Hi
thank you for quick reaction.
For 4090x5000 pixels picture my template is part of it = 3289x1750 pixels.
Exactly extracted in graphical program.
For succesfull tests my picture is 410x500 pixels and template 327x241 pixels
both made by resampling of the big pictures in graphical program.
Alle of them is GreyScale 8 bit, BMP.
I can post the small onec, but the bot ones ... is 30 MB. Shal I post ? Will NI server accept it ?
05-21-2010 07:22 AM
05-21-2010 07:35 AM
Hi,
Here are 2 files: Glas_Mini.png, which is the reduced version of the picture form the camera
and GlasTemplate_MINI.png, which is the reduced version of the Template = glass edge.
With these two pictures GPM works!
I am using *.BMP files but NI Server has rejected BMP files so I have converted to PNG.
Marek_K
05-21-2010 08:03 AM
Hello muks
I have compressed:
* big picture and template
* small picture and template
* testing VI
and it took 355 kB onlyso I can post it.
I enclose.
05-24-2010 10:59 PM
Your template is almost as big as the image you are searching. This could be the problem. If the template is not completely inside the search image ROI, it will fail.
If reducing the image by a factor makes it easier to find the match, why not just reduce the image every time you search? You said time doesn't matter, and reducing image resolution doesn't take very long anyway. Once you have the match, you could go back to the original images and do a fine adjustment yourself (if necessary). You could move sections of the image one or two pixels at a time and see if the match gets better or worse. I would probably compare one line every 50 pixels or so.
Is there a rotation match, or is it just XY shifting? There are a number of ways to do a quick match like this when the images are about the same size. I would do a version of correlation but only use one line every 50 rows or columns. I would do X correlation with horizontal rows and Y correlation with vertical columns.
Bruce
05-26-2010 04:11 PM
Hello Bruce,
Thank you for your support. My intention was to use template as big as possible to achieve very high matching accuracy.
Especially angular accuracy. I did not expect, that big template will be an issue. Of course the template is smaller as the picture, it is a part of the picture. I have made many tests with Grey Scale Pattern Matching, with Rotation Invariant option, and it works well with 20 Mpixel picture and 4,5 Mpixel Template.
In the application I am worry to use GS Pattern Matching, because the width of matched line (edge) will be different for different tested products, from 8 to 45 pixels, and the template has the line width 1 pixel. GPM seems to me to be better for such case than GSPM.
Because of high accuracy I would not like to work with reduced images. Currently, in real life, my pixel has resolution 0.08 x 0.08 mm and I have to achieve measurement accuracy 0,2 mm. Resolution is one error source only. There are more.
The pictures the GPM works well with are 10x10 times smaller than my aplication pictures. I did not found any notices, in IMAQ documentation, defining conditions for template or resolution of template and matched pictures so I thought, that there are no limitations. If you know any conditions or definitions HOW to create the template that for sure is OK, I would be grateful for the info. As regards matching: there will be a mix of horizontal and vertical shift with up to 15° rotation. So I expect, that correlation will not solve my problem.
Marek_K
06-02-2010 08:36 AM - edited 06-02-2010 08:36 AM
Hi All,
I would like to sum up the issue of locating geometric pattern match given here. As you know the geometric shape is irregular. There is actually only one straight line and the rest is a curve of higher order. It does not represent a good candidate for geometric template.
All the details can be found in Start > Programs > National Instruments > Vision > Documentation > NI Vision, open NI Vision Concepts Help.chm and go to Machine Vision > Geometric Matching > Geometric Matching Technique
There you will find:
The feature-based geometric matching technique works on the assumption that the shape of the pattern in the template can be reliably represented by a set of geometric features. This technique should be employed only when the pattern in the template and in the inspection images can be consistently and reliably represented by geometric shapes such as circles, rectangles and lines.
Thank you for your cooperation, Marek_K.
Best regards,
Sebastian
06-03-2010 08:31 AM
An alternate method is to locate the two ends of the line. Assuming that the print of the line is invariant along its length, finding the two end points you can then calculate the angle of the line much more accurately than with a single match. Each end point has a high degree of X & Y information giving you a very accurate position from which you can calculate the angle extremely accurately.
Mike