@halirutan Got any concrete ideas on how to use those distance transforms to get a result that guarantees each color is a single connected component?

@Rojo Consider the easy case first: You have 3 components and you can assign one component red, one green and one blue. My idea was the following, every pixel inside a component, gets the true component color only. As soon as you have a pixel outside the components, you calculate a mixture of the three colors depending on the distance of this pixel to each component.

For n objects, you can of course assign unique colors for each component. However, it is possible that two outside pixels can get the same color accidentally.

The underlying problem is, that for n objects, you get an n-dimensional distance vector {d1, d2, ..., dn} where each di is the distance to object i. Since the colorspace is not n-dimensional you won't get a unique color for all distance vectors.

@Rojo Let me finish a quick example.

@halirutan As far as I think I understand, you suggest building an n-color-channel image where the i-th channel corresponds to the distance to object i. And if the pixel was already determined to be part of the i-component, it will only have values on the corresponding channel. Or alternatively, a separate image keeps the information on the already segmented pixels.

@halirutan Am I following you so far?

@Rojo The basic behavior can be grasp by the following. Assume you have 5 object, that are incidentally arranged like the vertices of a pentagon. Now, we choose 5 different colors:

The following is not absolutely correct, but if we give each vertex of the pentagon one the colors, we get:

So inside the vertex points, you will have the specified color. Everywhere else, it is interpolated.

Right

(nice plot btw)

@Rojo The problem is that RGB is only 3 dimensional, so in reality and depending on the position of your objects it can happen that some points get the same color.

Yeah, but assume we had 3 colors for now. Then there's the task of assigning a single color to each pixel in a way that there's a single red puddle, a single green puddle and a single blue puddle

(we started, say, with 10 nodes, of 3 colors)

@halirutan Do you see simple good solutions to that part?

@Rojo First, you need to separate the puddles with MorphologicalComponents

This gives you an image, where each puddle gets an unique ID number (as pixel value).

Yes

What image are you suggesting to do this with?

I should build some dummy data. Gimme a min

The real data I have is quite messy, 3D, and would take a while.

@Rojo Post your example picture again you already posted.

@halirutan imgur.com/a/3UCvM

The top one is the solution. The bottom one is the input

Not "the" solution. One out of many

(There should probably be some black colour between the 2 vertical green segments on the input image, to prevent them to be joined just vertically)

@Rojo So you first need to join the green lines to give smeared version I see in the top image?

@halirutan The smear is lazy painting

All the stuff between the green contour lines should be green. Same for blue and yellow

@Rojo That is more tricky.

I thought you have something different. I thought you have something like this:

@halirutan Yes, I need to generate "reasonable" ways to join those colors

And the real problem is 3D, and not too contrieved. The problem will always have reasonable solutions, easy to find if one were to do it manually.

@Rojo Hmm, I thought your "puddles" are something like this, where each white object is one separate puddle

AHhhhhh

I see

and you want to assign each object a color and interpolate colors in all the black parts.

Perhaps one could join with lines into single connected objects, and then go about deforming them

@halirutan Yes. Exactly. Allowing for the black parts to remain as "background" too

@Rojo hmm

@Rojo Let's assume you can group the objects into groups of same color (this might be tough depending on your real data).

(especially, if this should work in 3D as well)

@halirutan in 3D I think it's easier. And the data is supposed to be nice for this, at least most of the times. If it's not, then if should be solved on a previous step.

If it's not, I'm happy enough with a function that returns "go to hell"

In other words, we can assume nice data

@Rojo Let's say you can automate the hard job of doing this:

img = Import["http://i.imgur.com/P6v6YlZ.png"];
bin = Binarize[ColorSeparate[img, "HSB"][[1]], {0.24, 0.6}]

Now, we have only green objects.

Yeah. That part will be done.

@Rojo Then one idea is the use the convex hull of these objects to get one closed object.

But it won't look like you have drawn it.

And then modify the solutions for each color to avoid overlap?

and then smooth

such that the modifications don't disconnect the stuff

Humm

Oh man.. this kind of doesn't sound as it will be working very well.

@Rojo Or you calculate the convex hull of all pairs that have a certain maximal distance. This might look like

But it is again very fragile.

Yeah, but the idea of solving it incrementally by pairs might be a good one

In short, if you have the non-overlapping objects of your already connected puddles, my idea of how to color the black space between them might work. For the task of connecting, I have no bright idea.

@halirutan Yep

@Rojo Well, maybe I have another. I need a couple of minutes for that.

Maybe with graphs, or with some topology thing, one could enumerate the different ways to connect the parts with lines. Then deform. Then use your idea to "fatten"

Also, partitioning the image into small chunks, solve there, then use bigger chunks, etc, might make sense.

@Rojo Above, we have 4 green objects. Get the center of each object with ComponentMeasurements. Draw a line between from one object to the next, but only if they differ in the x-coordinate. Then, use Dilation and as kernel, you use one of your objects.

Nice

This will simulate the following: Take e.g. the bottom right object as pencil and draw with it to the central object.

Do the same for the top left object. And then draw the center object to the right object.

Should give exactly what you have drawn by hand.

Basically, you need to make the pencil adaptive. You start with your starting object and end with your ending object.

Yep

If I just choose randomly which color to start with, and add some noise to the solution, and in every step I just take care not to go over the other colors that have been already established, it might work

xkcd.com/166 made me laugh (as always don't miss the hover text)

I would wish it wouldn't be so "efficient" way of running Mma into using vast amounts of CPU time and RAM just by doing a Reduce on something like ForAll inside Exists on relatively simple geometric statements...

I am unable to find any significant difference in timing for the code and examples given here:

I am using v10.1 under Windows x64. Can others reproduce this timing result? If not this question should be closed.

@kirma Are you seeking a way to limit either CPU time and/or RAM usage, and abort, or simply lamenting the state of affairs?

@Mr.Wizard Lamenting the facts a) that such problems lead to more or less infinite-memory expansions in a way or another and b) that apparently (geometric) intuition of the system on such problems seems to be so absurdly low.

The problem at hand was like, "what angles of a line drawn from a specific corner of a non-convex polygon leave interior of the polygon (the first time) through a specific side of the polygon?"

Clearly one can't rely on Mma to cope with such a problem stated in relatively obvious way.

@Mr.Wizard I can reproduce it in 10.3, 10.4, 11.0

Did you know that you can demonstrate the non-linearity of the human ear with an audio sample that can be generated using a single line of Mathematica? szhorvat.net/pelican/combination-tones.html

@Szabolcs "Since this is a non-linear effect, turn up the volume." <- nice!

@ChrisK On Facebook someone said that the neighbours were complaining ...

@Szabolcs Very cool! I'll share with my kid who's just learning trig identities in school

Kinda irritating that an failed, returned-unevaluated function is reevaluated inside Set:

Clear[f];
f[x_?NumericQ] := Exp@Exp[100 (1 + x)];
res = NIntegrate[f[x], {x, 0, 1}];

Is there a way to save a result without having the function reevaluate after initial failure?

@MichaelE2 Can you explain what you mean?

@halirutan Execute res = NIntegrate[f[x], {x, 0, 1}]; and simply NIntegrate[f[x], {x, 0, 1}]; You'll see two error messages in the first case

Ahh, OK. Let me see

@MichaelE2 And then we have

With[{res = NIntegrate[f[x], {x, 0, 1}]},
 realRes = res
 ]

:)

@halirutan Cute. I think I found a way with RuleCondition, which I never really mastered:

res = Hold[NIntegrate[f[x], {x, 0, 1}]] /.
  i_NIntegrate :> RuleCondition[i]

A bit roundabout, but does what I need.

@MichaelE2 I think the situation is misleading. If you look at NIntegrate[f[x], {x, 0, 1}] // Trace, you see that many messages are generated and in the usual case only one makes it to the surface. I'm not sure why using = changes this behavior.

Very confusing

@halirutan Trace output, for me, is easy to misread. Does this clarify?:

Clear[glurg];
glurg[x_?NumericQ] := Exp@Exp@Exp@Exp[Pause[0.1]; 1 + x];
res = NIntegrate[glurg[x], {x, 0, 1}]; // AbsoluteTiming
NIntegrate[glurg[x], {x, 0, 1}]; // AbsoluteTiming

@MichaelE2 In any case it is curious. Usually, NIntegrate should collect all Overflow messages and generate one message of its own. I have no idea what happens.

@halirutan traceView2 shows two evaluations of NIntegrate. I suspect the return value of Set is being evaluated. It's not just limited to NIntegrate. res = Plot[x, {x, 0, Null}] fails twice.

@MichaelE2 Hmm, that is odd

doesn't show this behaviour and I wouldn't expect it.

Ahh, let me try something..

i = 0;
Plot[x, {x, 0, i++; Null}]

@MichaelE2 it really is evaluated twice. After this, i is 3 on my machine. With res= it is 6.

@halirutan Yes, if you put a Print[x] statement inside the def. of f or glurg, you see the sampling is done twice, too. (I changed it to Pause above, because I thought the timing showed it just as clearly.)

Do you think it's a bug? Your f example shows it's not always the behavior.

@MichaelE2 I don't now whether it has further implications. For me it is at least very unexpected and does not follow the rules of the normal evaluation chain. Initially, I thought that only the messaging/error reporting mechanism is flawed but as it is now, it can introduce bugs that are hard to track.

@MichaelE2 The question is, does this only appear in some very high-level function or can we reproduce it with simpler functions too? Obviously, your initial f generates a system message as well, but is never evaluated twice when you call

res = f[2.3]

@halirutan The same happens with Identity@NIntegrate[..] and Identity@f[]. -- Yes, I've been suspecting it might have something to do with high-level functions that have complicated parameter checking.

If it indeed also happens in simpler functions, than an f with side-effects will compute the wrong output.

@MichaelE2 Yes, I have already found that Identity shows the same thing.

Maybe someone with a good overview of the questions like @Mr.Wizard can tell if there is already a question reporting this issue.

@Mr.Wizard Consider a simple f that throws an overflow message and is used in NIntegrate, did you ever came across a question that reports why the NIntegrate call is evaluated several times? Consider this simple example

f[x_?NumericQ] := Exp@Exp[100 (1 + x)];
NIntegrate[f[x], {x, 0, 1}]

Throws exactly one message and is evaluated only once. Now look at this:

With[{res = NIntegrate[f[x], {x, 0, 1}]},
 realRes = res
 ]

(or on all the other examples above)

@halirutan Thanks for your help. :)

@MichaelE2 Hehe.. I wouldn't call it help :) but no problem.

Is there anyone with earbuds around? If yes, try this:

Play[{Sin[300 2 Pi t], Sin[500 2 Pi t]}, {t, 0, 1}]

Listen to only the left stereo channel. It will be a low tone. Listen to only the right channel. It will be a high tone. They are not mixed.

Now try this:

Audio@Play[{Sin[300 2 Pi t], Sin[500 2 Pi t]}, {t, 0, 1}]

On my computer (macOS Sierra), both the left and right earbuds play both the high and low tones simultaneously. In other words, the sound is downmixed to mono before playback.

Can anyone reproduce it?

@Szabolcs Same for me (OSX El Capitan).

According to an appropriately minimalist definition, my computer is auto-generating complete games now. My hope is that by taking an abstract approach I'll avoid traditional genres and giving up.

@MichaelE2 Thanks! Reported to WRI and confirmed.

@halirutan I have a notoriously poor memory so I'm not sure why you would turn to me. :^) I cannot at the moment recall something like that, for what it's worth.

@Szabolcs I still believes it is 2 channels, though: AudioChannels@Audio ... gives 2.

So, weird.

@rcollyer Yes, that's right. It's only the playback that's buggy