Union fails on a complicated shape

[inventorArtist]

I've used Union quite a bit and it generally works great.

I have a case where the two objects I'm uniting are quite complex. After the union takes place a whole bunch tiny lines are left. They are open and they look like they are fragments left over from one of the objects. In cases where one object has a shape, then the other object has a shape withing it, you expect the smaller one to just be deleted. Instead it is only partially deleted leaving some little open lines lying around.

Has anybody seen this?

In the same document I am successful at uniting other objects.

Could it be running out of resources during the operation? Is there a way to find out?

I've attached the file. The two items to be united are in the Fix layer (and another copy in the FixCopy layer).

You can see the disaster that it creates when you view it in outline mode (View, Display Mode, Outline).

By the way the application is this. I have three layers A, B and C. I want to make sure the three layers have no overlap. So I subtract between AB, AC and BC. My C layer winds up a mess. So an alternative method is to subtract AB,  union AB together then subtract that from C. My issue above is in trying to union AB. If I union AB I get a mess and if I subtract both A and B from C I get a mess. Crazy eh?

Any thoughts?

[Moini]

Not sure what you're after, works for me as expected:
http://i.imgur.com/xdHqJ0r.png
http://i.imgur.com/MLtczPS.png

[Moini]

how about (ab)using Trace bitmap for this? It can create objects that don't overlap automatically (if you uncheck 'Stack Scans')

[inventorArtist]

how about (ab)using Trace bitmap for this? It can create objects that don't overlap automatically (if you uncheck 'Stack Scans')

Can I select the thresholds between the colors? I don't get good results with that compared to when I set the levels.

[inventorArtist]

Not sure what you're after, works for me as expected:

You removed the dark object from the lighter grey object?

If it's working for you but not me, that points a bit to my computer or software installation wouldn't you think?

[inventorArtist]

Here's a report.

I was able to solve the problem by making my objects A, B and C simpler. I did this in two ways.

First, when tracing I use Options/Suppress Speckles to reduce the number of object. Second after each trace I ran Path/Simplify twice.

I was then able to get through the process of removing the overlap between A, B and C. There was still a small amount of flaws but I was able to get to the next step in my process...

I should mention that I tried the whole process more than once and it still failed one time even with the two simplifying measures. So I must be on the edge of some resource pool of my computer.

Later I will try it on my desktop and see if the problem comes forward.

[brynn]

I'm having a hard time understanding what you want to do.  I can union the 2 objects without any problems. 

If you have a lot of other stuff in the file, that could be creating a performance issue.

But I don't understand why you want to union these 2 objects.  The gray object is completely covering up the black one.  You can't see the black anywhere outside of the paths of the gray one.  And when I union the 2 objects, the result is indistinguishable from the gray one by itself.  It looks like you could get the same result by simply deleting the black one.

It's like 1 + 0 = 1.  Right?

If you could give us some more details about the project, we might be able to suggest an easier route.  If you're using Trace Bitmap, and you just want a single result, what if you used a Single Trace option, rather than Multiple Trace (colors)?

[inventorArtist]

But I don't understand why you want to union these 2 objects.

Yes the grey object completely covers the black object. So I want to remove the area that is black from the grey. So you can then see both of them with no overlap.

In the trace panel if you uncheck the stack box, it gives three objects that don't overlap. But you don't choose the levels for each of the traces. So you don't get good results. So I do three traces of one then remove overlap.

[brynn]

To remove the black from the gray, put the black one on top, and then use Difference.  Although you are not out of bounds in wondering if the complexity of the paths could have an effect.  They certainly could.

In fact, after I posted my first reply, I was looking more closely, and I did see at least one sort of glitch with the Union.  A section which was supposed to be white (well, transparent really, but on the cat, white) had become filled.

Let me try the Difference.....  Well, except for the exact same place where I noted had been filled during Union, Difference works fine for me.  It's one of the little streaks of white in the eyebrow that gets filled (the eye on the right, cat's left).  You can actually see it better using Difference.

(To fix that, you'll need to switch to the Node tool, and find where a path is not closed properly.....or maybe inadvertently closed.  I can help, if you need it, finding that path.)

Regarding Stack Scans.  I could be wrong, but I don't think unchecking Stack Scans removes the overlaps.  It just means that the scans are tiled instead of all stacked up.  Without having the scans stacked, I would think it would be harder to realign them for the path operations.

Can I ask what the goal of this project is?  It seems too complex of a path to be meant for cutting.  It's just that cutting is one of the reasons people don't want overlaps.  Another reason is for putting designs on fabric (screenprint t-shirt for example).  And also, if you could share the original photo?  I'd be glad to try and find a better routine.  I'd be curious if a single scan option would work better.  Well, only if you want to share.  I don't mean to pry

[inventorArtist]

To remove the black from the gray, put the black one on top, and then use Difference.  Although you are not out of bounds in wondering if the complexity of the paths could have an effect.  They certainly could.

I will make up a video that explains what I'm up to and why. So you'll see exactly where it's going wrong (or I am)...

[Moini]

@brynn: please see http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Trace-Multi.html, and know that Tav only moved the images for demonstration purposes. Originally they were all lying on top of each other. Or perhaps try it out yourself

[brynn]

Well, I did warn that I could be wrong.  I don't know if something has changed since the last time I tried it.  But when I've tried it years ago, as far as I could tell, the only difference was that the scan results were tiled instead of stacked.

Oh, I see that they aren't tiled at all anymore!  So if the purpose of that option has changed at some point, over the years, it looks like it could have a better label.  Such as "overlap scans" or something.  Because technically, they are kind of stacked, the only difference being their z-order.

I don't know if I could find it....yeah, probably not.  It would be in some old backup somewhere, but I probably do have an old file or 2 somewhere, where I did not use Stack Scans, where the results were tiled.

But anyway, thanks for letting me know.

[inventorArtist]

I've not made the video yet but here is the project so you guyz don't get too stressed out about why I am doing this.

http://inventorartist.com/flexography/

I got the cat one cut out and tonight I'm going to try and print it.

If I get more furry animal portraits I'm gonna be likely hitting this issue again.

I'm realizing now that I made an extra step I didn't need. What I did was subtract A from B, then A from C and B from C.

But I really only need to subtract A from B and B from C. Duh....

The problem seems to occur when I do more than one operation with the same object... so is possibly a rounding error of sorts...

[brynn]

What Moini was informing me, if you uncheck Stack Scans, it automatically does all the cutting for you.  It removes all the overlaps, in one shot. 

(It didn't used to do that, when I tried unchecking Stack Scans many years ago.  And I haven't tried it since.  So I didn't know about the change.)

Or is that not exactly what you want?  I did look at your page, but it didn't tell me exactly what you're doing.

[inventorArtist]

, it automatically does all the cutting for you.

Yeah, I understood that but you can't choose the thresholds where it makes each division and it does a bad job (compared to what I can do)...

If they let you set individual thresholds for that feature it would be treat. So I wind up making each one myself and subtracting them...

[brynn]

What do you mean about thresholds?  I thought you were using Multiple Scans > Color.  Are you using a Single Scan a few times, with different thresholds?

Edit
In which case, I would have to ask why 

[inventorArtist]

Single Scan a few times, with different thresholds

Yes, that's what I'm doing because when you do the color or grey scan you don't set the levels. The levels the software chooses are usually no where near where I want them.

[brynn]

Aahh!  Well in that case, Stack Scans is irrelevant!  So then you must do a lot of trial and error!

Just a quick note.  Sometimes I have entered a much higher number of colors, than the actual colors I see in the file.  Of course you wouldn't use them all.  But sometimes that gives exactly the path I want, which I don't get if I use a small number of colors.  Sometimes you can even get decent paths from lower quality photos.

You still would have to do the cutting yourself, but it might allow you to produce the 3 paths all at once.

Anyway, good luck!

[flamingolady]

I have experienced the same issue of union not working as expected, started with with 91.1, never had this issue in prior versions.  Not sure why it works for some but not others.  I'm using Win 7, could that be the issue? And my objects were basic, so it didn't make sense. It was two simple objects, and it put the nodes on top of each other, rather than joining the paths, so it still 2 looks like two objects vs one, it worked like 'combine' not union.   wish I had taken a screen print.   I've always had issues when union'ing lots of nodes and/or union'ing 3+ objects, usually 'simplifying the nodes' works, and I now only union two objects at a time, then take that one and union it to one more.  I think it's a bug.