Adjust Color Pallettes

There should be an automated function for this. I have indicated a few times before that this is a missed opportunity from ETC's side to improve the software for touring companies that are having to deal with a different type of F.O.H.-led fixture each night. There have been workarounds for some time (e.g. having a fake franken-fixture with every color parameter imaginable somewhere in the group during plotting), but a real solid solution from ETC would be much appreciated!

This sounds like a feature request. Feel free to add it here!

Thank you.

Thank you for your answer. I've made a feature request, but I am unsure how it should be implemented, so it is hard to request an exact feature. My solution (see below) has its disadvantages. That is why I bring it up here to discuss it in a place where I know some of the smartest ETC Eos operators are watching ;-)

community.etcconnect.com/.../save-colors-in-prophoto-colorspace-in-color-palettes

i think there are actually two feature request lurking here:

- the one you made to have universal color palettes.
- and one to fill up palettes, presets and cues when you changed the patch and a channel has now previously inexistent parameters.

I will once again chime in saying the way by type palettes are handled is poor, the "by type" data shouldn't need to be attached to a channel, and while we're abstracting type data away from a channel, we should add abstract global approximations as well.
When you change a channel type in patch there should be an option to let you clone data to new params (much like the preserve native toggle alters the way repatching works).

Good points. Maybe universal color palettes is the right translation for my problem. I was thinking that the solution was in how the palettes are stored. I was thinking maybe this could work how I thought how Virtual HSB would work. It seems this last thing is only about how colors are represented on screen. 

My logic is that a mix of six colors results in a point in a colorspace (x, y) and that when you recall the same coordinate for a fixture with eight colors, the resulting color from both fixtures would be first of all quite close and secondly all the color parameters would actually have values (just like they would get by touching that same point in the color picker.)

The problem (according to @NickGonsman, to whom I spoke at Prolight & Sound in Frankfurt) is that not all fixtures have the same color gamut, some cover a larger area in the color space then others). Since the problem mostly occurs if you replace a fixture with less colors with a fixture with more colors, I am not sure why this should be an obstacle. Also even when you only get close to a color, it is easy to update that color palette.

Good points. Maybe universal color palettes is the right translation for my problem. I was thinking that the solution was in how the palettes are stored. I was thinking maybe this could work how I thought how Virtual HSB would work. It seems this last thing is only about how colors are represented on screen. 

My logic is that a mix of six colors results in a point in a colorspace (x, y) and that when you recall the same coordinate for a fixture with eight colors, the resulting color from both fixtures would be first of all quite close and secondly all the color parameters would actually have values (just like they would get by touching that same point in the color picker.)

The problem (according to @NickGonsman, to whom I spoke at Prolight & Sound in Frankfurt) is that not all fixtures have the same color gamut, some cover a larger area in the color space then others). Since the problem mostly occurs if you replace a fixture with less colors with a fixture with more colors, I am not sure why this should be an obstacle. Also even when you only get close to a color, it is easy to update that color palette.

I just don't buy into how that's a problem. I absolutely don't expect Eos to perfectly handle a new fixture without me tweaking the params (though Eos probably has the best shot, their color engine is the best in the business). But I only want to fix the color palette once, I don't want to also have to touch every palette and cue to just say this new param should also be in and have the palette.

I reread my notes and to be honest the answer Nick.Gonsman  gave was a little more complex. The thing is that with the introduction of the color recipes (metamers), there are now multiple ways to arrive at the same CIE x, y coordinate. This color mix would get lost. The question remains if this is more problematic than having empty color parameters all over your cue list and palettes.

I would prefer to get a color that is at least in the ballpark (maybe while offered the choice between Brightest, Spectral, and Hybrid)

I think a color that is in the ballpark with all params cloned from the applied CP is obviously better. Again, I only want to have to fix the palette, even if it's just changing the metamer, rather than touch the cues and data where it's stored. We're going to have to adjust the palette no matter what when we introduce a new type of fixture, we should minimize extra effort to the extent possible.

The only case where maybe that shouldn't happen is if different CPs are affecting different params at the same time. Which to be clear, I have never seen used (except outside of cooling fan, which really should not be a color param).