Vectorize an image using Labview

[ThiCop]

Hello VGans,

This is what I was looking for.

Is the drill of a fixed size or do you have multiple possibilities?

Please tell me what the options are.

I have understood that an even colored plane should be completely carved out to a certain depth.

It seems to be quite important that the spacing between the carving lines you produce/define allows you to completely carve out the plane.

This is then linked to how the amount of pixels in your picture maps to the physical process of carving.

Just imagine having

- a picture of 100 x 100 pixels

- a carver resolution of 0.001 m and so a smallest move of 0.001m

- a drill diameter of 0.001m

- an object to carve of 1 m by 1 m (x,y plane) and a certain depth (z)

If you consider the picture to (directly) fully map your xy plane, then each pixel of your picture would correspond to a 0.010 m by 0.010 m  (x,y) area.

If you only draw two (black) lines directly below eachother (without a white space in between), then directly translating to drilling might cause an issue.

it could be that you carve 2 lines below eachother with a width of 0.001 m (drill diameter) and a length of L.

This could mean that you still have 0.009 m by L area of non-carved space.

Is the point/possible issue clear that I'm trying to make.

Again a sidenote to make sure everything becomes clear:

- Is your carving approach going to be to first carve the least deep figure and then progress to the deeper ones?

To make sure I understand correctly:
- a white background is not going to be carved out.

- a black background is the deepest possible carving.

- a color is supposed to be somewhere in between that.

[VGans]

Hi!

So we have multiple drills. A few are way to big but we have two that we are considering using. The first one is 0,396875 mm (1/64 in), the other one is 0.79375 mm (1/32 in), both 2FL. But we were thinking about maybe buying some new ones.

Again a sidenote to make sure everything becomes clear:

- Is your carving approach going to be to first carve the least deep figure and then progress to the deeper ones?

     Not necessarely. Right now, when we draw something with our program, the only thing that is important to the machine is the order of the lines. If you first draw a blue line (0.3cm deep for example), then a red line (0.2cm deep) then a yellow line (0.4cm deep), the machine is going to carve the blue line, then the red line, then the yellow line. It does not follow an order of depth or from right to left for example. It only carves the first line, then the second line etc.

Therefore, the carving approach is mainly going to depend on the vectorization algorithm.

For example, we've been thinking that it could do pixel per pixel for example, where every pixel has a different depth (from right to left and from top to bottom of the picture). Or that it could first carve everything that is black, then go deeper and deeper etc.

This will only depend on how the picture is handled because the machine only sees sets of points.

To make sure I understand correctly:
- a white background is not going to be carved out.

- a black background is the deepest possible carving.

- a color is supposed to be somewhere in between that.

       That's the idea (even if it could be the contrary. I don't think it's that important. It can be easily changed in Labview).

About the issue you pointed out. First of all, the carving surface is only 10x15 cm2.

Then, indeed, it could happen. What do you think we could do to avoid that?

[ThiCop]

Hello VGans,

You should keep in mind the ratio between the drill size and the pixels per carvable cm (or per mm).

Once you know how these relaten, then you can define how you should handle each pixel (that can relate to a block).

For the pixel per pixel example this could the become something like this:

- Imagine you have a 100x100 cm (Carve area = 10000 cm²) carving surface and your drill has a 1 cm diameter (diameter).

- Imagine you have an image that has 25x25 (Image points=625) pixels.

- In this case ("Carve Area"/"diameter^2") / "Image Points" gives you the value 16.
This means that you will have to carve 16 physical points for each pixel point.

Please  note that this definition is far from perfect, since it also ignores the fact that the drill will give you rounded corners.

One way you could get around this is like illustrated.

However, I would not dare to call this a "good solution".

Concerning the approach it might be interesting to also consider an approach like this:

- Imagine that you have white, light grey, middle grey, dark grey, black with the related increasing depths.

- First carve everything that is white (or deeper)

- Then carve anything that is light grey or deeper.

- Then carve anything that is middle grey or deeper.

- ...

I have experienced that some types of devices prefer this approach and it sometimes allows for better accuracy.

It also nomally puts less "stress" on the drill and makes it less likely to break (by doing those small increments in depth).

However, this might not be applicable to all devices. (I have no experience with the specifics of this device you're using).

Included with this approach it would still be extremely useful to define carving regions (instead of point by point) that have a same depth or a deeper depth color.

One benefit of this approach is that it is easier to find connected regions that are "greater or equal to" a certain value.

The direct downside is that you will have more iterations.

Is the most important part of this project that it is fast or rather that it is accurate?

PS: I know that I am asking alot of questions, but I just want to make sure to have an open discussion to see that as much possible hidden issues are discovered.

In this case it is still very interesting to detect objects/particles.

[VGans]

Hi Thierry,

Thanks for all your help! 🙂

We have developped a vi that uses the solution you propose. (line per line). Indeed, it is not the best solution, and it is quite slower than when we just draw something on labview, but given the fact that the maximum carving surface is quite small, it is not such a big deal.

We've manage to vectorize the image and it works fine. we only have small issues with the colors, but we were thinking of working with levels of grey so that there are less different colors.

Concerning your second solution (carving per level), I don't know if it really is necessary because the machine automatically goes back to a 0 depth to a -x depth between two lines (so, for example: (x,y,z) 1,1,0 ; 1,1,-1 ; 1,2,-1 ; 1,2,0 for the first line, then 1,3,0 ; 1,3,-1 ; 1,4,-1 ; 1,4,0).

But we will see if we can make it work.

Finally, we were hoping to have a carving process that is not to long, but because the carving surface is so small, I think that accuracy is more important.

In the mean time, we have developped a Gaussian filter and we were thinking of trying to create a canny edge detection vi, so we can try both solutions.

Thanks again! Your input has been really helpful!

Valentine

[ThiCop]

Hello Valentine,

I'm happy that I was able to discuss the application a bit with you.

If you're ever planning on looking into the carving per level, then looking into the workings of 3d printing algorithms might also be useful.

It is up to a certain part the opposite of the carving per level (except for the fact that you cannot carve underneath your top surface).

The similarity lays (for me) in the fact that both need to define planes/regions to gradually build.

At your side you could define regions to gradually carve.

If it always goes back to zero depth after drawing a line, then maybe more complex approaches might not be that valuable.

If you ever need a sounding board or have questions, then don't hesitate to use the forum again.