Kevin Reid AG6YO

I updated my answer to mention the negative color component problem.

But I am not familiar with best practice for adapting to out-of-gamut colors, so I cannot comment very much there.

For a simple example of how tone mapping interacts with color, if you start with a real-valued nonlinear function and apply it to to each RGB channel independently, then you have an overall tone-mapping function that desaturates bright colors, which is in one sense an accident of the math, but it also generally produces perceptually good results compared to trying to preserve color and remap only intensity.

I'm not sure of the proper terminology here. Tone-mapping in the general case does include possible color shifts, but it might be more correct to talk about “gamut mapping”.

But, most of the pixels in your current scene shouldn't end up greater than 1 in the final output. Your current scene doesn't contain e.g. the sun, or any bright reflections. The point of not clamping is to avoid disrupting what individual rays are doing, but individual rays each have a very small contribution to the final image.

Then in the final stage, when you do need to store the output in an actual image that will be displayed on an actual screen, if you are not writing a HDR output file, you need to perform tone mapping which decides how to handle the greater-than-1 (“overexposed”) values. Clamping to a maximum of 1 is the simplest possible tone mapping function.

In general, you should always be using non-clamped rather than clamped RGB (at least, not clamped to max 1) for any value representing light passing through your scene. The 1 value does not mean anything physical whatsoever; it only represents the maximum output of the display device (in SDR) or the arbitrary “reference white level” (in HDR).

It shouldn't matter whether you accumulate rays in XYZ or linear RGB as long as you don't do anything at all non-linear to it before you average.

Regarding the difference between the two procedures you describe, I'm not sure, but the obvious potential culprit is "Convert to sRGB. Clamp to [0,1]. Average.". Clamping is a non-linear process, so you should average before you clamp.

By "sampling" I meant: sampling from that distribution, however you do it. Either strategy should work. I do not have any actual experience with sampling in path tracing and cannot advise you what would be better there.

“a function to convert directly from wavelength to RGB” — That function is just combining the two operations “determine the intensity of D65 at that wavelength” and “find the RGB representation of this color of monochromatic light”. That’s a reasonable thing to do since they both depend on wavelength. The disadvantage is that it bakes in D65, so you can’t specify an arbitrary SPD for each light source, only change the RGB components of the result (which is basically doing the white-balance step I mentioned) and so you don't have control over the behavior within the scene of the full spectrum.

@TomClabault “Also, is there a way to avoid "sampling" the distribution?” — No, because each ray’s direction is wavelength-dependent, so you can’t use one ray for more than a single wavelength, so you’re always sampling in some sense.

"If I choose D65 as my distribution, it's rather the diamond that is going to match the background, correct?" — Yes, that's correct. But if you hard-code just D65 then you will still have a problem if you want to work with non-white light sources. Starting with the SPD as the definition of the light’s color means everything is consistent. (I added a paragraph on why you shouldn’t start with RGB.)

Well, whatever color name one uses, to my eye, the added color in the flame does look like copper. So, no mystery about the color — just that nobody's said how the copper got there.

(and judging by the way the metal crumpled in-place just before the fireball, it indeed hit the ground square on, too hard)

And, his word on the landing trouble: "Fuel header tank pressure was low during landing burn, causing touchdown velocity to be high & RUD" — twitter.com/elonmusk/status/1336809767574982658?s=20

I was wondering about the green (and searching space.stackexchange.com about it) myself and found a prior mention of "Vaporized some copper" ( twitter.com/elonmusk/status/1093428938871779328) but not any explanation of where the copper came from.

(For the record, I've just created a private chat room to discuss the matter.)

I see. I pinged Mike but he isn't online at the moment and I don't have context.

(looks like chat.stackexchange.com is having some problems.)

Sure, that makes sense for a comprehensive canonical answer.

@MikeWaters I understand rclocher3 to be proposing writing a canonical question: that is, one written to be more general than a typical example of its kind. "I'm receiving a signal I don't recognize. How do I find out more?" — rather than a question with specific recordings, frequencies, etc.

Of course, I could and haven't…

I wish someone would post an argument for or against.

I would have recommended creating a meta question to gather arguments & votes for/against before adding the tag. It's not too late now.

(and therefore whether they should read or ignore those questions, if they're reading rather than writing)

It's not objective enough to have a clearly defined scope so that people can understand which questions it belongs on.

I mean the tag shouldn't exist; it's not a very useful classification. Something being a "beginner question" depends on where you're beginning from.

@MikeWaters I don't think that tag is a good idea. meta.stackexchange.com/questions/59077/…

You're welcome. Bye!

Sometimes working on that simplification process can even let you find the problem yourself!

I'd recommend that you post a new question to catch the attention of someone who is. However, before you do that, please try to simplify your code — it'll make it easier for someone to help you. Try to make a smaller example that demonstrates the same problem (all one class in the output), even if it doesn't even attempt to compute the answer you actually want.

So it is. Unfortunately, I'm not very knowledgeable about the uses of classifiers.

OK, are you all set now?

That should fix the error.

(It's a property on the collection, not the individual features.)

That way you get the band_order property preserved.

var samples = addClass(A_samples, 1)
    .merge(addClass(B_samples, 2))
    .copyProperties(A_samples);

Oh, I see.

Er, sorry, that was irrelevant, since stack isn't being used as training data.

Oh. stack is not from Image.sample()

Though, I notice the documentation says "This argument is optional if the input collection contains a 'band_order' property, (as produced by Image.sample)." Since we're in fact using Image.sample, I don't know why that isn't applying here.

Yes, same idea for any classifier.

Or if you wanted to train on all of the bands it would be {features: samples, inputProperties: bandnames} since you already have var bandnames. But I'm not a ML expert and can't tell you whether training on all the bands is a good idea or a bad one.

change this to .train({features: samples, inputProperties: [<insert your property/band names here>]})

var cls = ee.Clusterer.wekaKMeans({init:3, nClusters:9, maxIterations:100, seed:587})
                              .train(samples);

to list the properties you want your classifier to be trained to classify based on

You need to specify the inputProperties parameter to train()