Hog III Novice

Marty & Quinn,

Since you have both touched on some similar issues that affect this discussion, I'm going to reply to both of your posts at once. Hopefully I'll catch everything you guys mentioned.


3D Space

Quinn - I'm curious about how you were thinking of handling this, if not in 3D. We're adding another dimension to our colour space, so I think it would either have to be a 3 dimensional model or our current colour wheel with a separate fader for the third dimension as Josh mentioned.

I still need to think on this one a bit, but my current thinking is that our current wheel would map on to one hemisphere of a sphere and a similar wheel with black at the pole instead of white would map to the other hemisphere.

Marty - You say that we just need a simulated 3D model. My concern with this is that we still need to maintain a very easy way to pick a colour. We obviously can't implement a solution that makes it more difficult to pick a colour than it would be to dial one up with the encoders.


Crossfade Paths by Colour Space

I'm not horribly worried about this because it seems to just boil down to "are we fading our abstracted HSI values for a crossfade around the sphere or are we fading the raw CMY / RGB parameter values for a linear fade".

We would want to implement a way to specify on a per-fixture per-cue basis which colour space would be used for a crossfade.

Quinn - You asked why CMY doesn't know what HS is doing. The answer is that it usually does, but the problem is that there isn't a 1:1 relationship between positions in the two colour spaces. This is even more true now that we have fixtures like RGBA LEDs. I can mix a beautiful amber with red and green or I can just use the amber LED. If you give me RGBA values I can always tell you what the corresponding HS values are, but if you give me HS values I may be able to mix that colour a few different ways using RGBA.


Colour Calibration and Compatibility

I don't have an official answer on this one, but I'm sticking with my original assumption.

Quinn - You say that the current colour wheel maps to the outside of the sphere and everything else is "quick interpretation ala XYZ". That can't really be the case if we're talking about additional colour parameters. If we're building this to help us handle White and Amber LEDs or CTO and CTB wheels then we will be redesigning the way that colours and their associated fades are determined. This also means that since these new features require an additional dimension in the colour space that our colour calibration model needs an additional dimension in the colour space which may require re-calibrating fixtures.

I still think that a change like this (a complete rework of our colour model) sounds like something that would certainly break backwards compatibility. While that may not sound like a big issue to you, we have many shows on tour or in permanent installations that this can be a big issue for. There is a ton of planning and thought that goes into something like this and we certainly can't take it lightly.

If we do need to re-calibrate fixtures, this also is a large undertaking. Acquiring, cleaning, re-lamping, and measuring a fixture is already a sizable project, but a change to the colour model means changes to the calibration routines which is another significant consideration.


Everything Else

Marty - You asked about our current HSI model taking intensity into account. Currently we have a HS model. Intensity is in no way taken into consideration when working with the colour wheel or HS colour mixing. We would need to add the support to handle a concept of intensity in the colour model.

Quinn - What problems are you having resizing or maximizing the colour wheel? It's always been a MDI window as far as I know.


Hopefully this answers most of the issues you presented. Let me know if that's not the case. I think this is a good discussion and that it's really worth working out the details.

Thanks.

Marty & Quinn,

Since you have both touched on some similar issues that affect this discussion, I'm going to reply to both of your posts at once. Hopefully I'll catch everything you guys mentioned.


3D Space

Quinn - I'm curious about how you were thinking of handling this, if not in 3D. We're adding another dimension to our colour space, so I think it would either have to be a 3 dimensional model or our current colour wheel with a separate fader for the third dimension as Josh mentioned.

I still need to think on this one a bit, but my current thinking is that our current wheel would map on to one hemisphere of a sphere and a similar wheel with black at the pole instead of white would map to the other hemisphere.

Marty - You say that we just need a simulated 3D model. My concern with this is that we still need to maintain a very easy way to pick a colour. We obviously can't implement a solution that makes it more difficult to pick a colour than it would be to dial one up with the encoders.


Crossfade Paths by Colour Space

I'm not horribly worried about this because it seems to just boil down to "are we fading our abstracted HSI values for a crossfade around the sphere or are we fading the raw CMY / RGB parameter values for a linear fade".

We would want to implement a way to specify on a per-fixture per-cue basis which colour space would be used for a crossfade.

Quinn - You asked why CMY doesn't know what HS is doing. The answer is that it usually does, but the problem is that there isn't a 1:1 relationship between positions in the two colour spaces. This is even more true now that we have fixtures like RGBA LEDs. I can mix a beautiful amber with red and green or I can just use the amber LED. If you give me RGBA values I can always tell you what the corresponding HS values are, but if you give me HS values I may be able to mix that colour a few different ways using RGBA.


Colour Calibration and Compatibility

I don't have an official answer on this one, but I'm sticking with my original assumption.

Quinn - You say that the current colour wheel maps to the outside of the sphere and everything else is "quick interpretation ala XYZ". That can't really be the case if we're talking about additional colour parameters. If we're building this to help us handle White and Amber LEDs or CTO and CTB wheels then we will be redesigning the way that colours and their associated fades are determined. This also means that since these new features require an additional dimension in the colour space that our colour calibration model needs an additional dimension in the colour space which may require re-calibrating fixtures.

I still think that a change like this (a complete rework of our colour model) sounds like something that would certainly break backwards compatibility. While that may not sound like a big issue to you, we have many shows on tour or in permanent installations that this can be a big issue for. There is a ton of planning and thought that goes into something like this and we certainly can't take it lightly.

If we do need to re-calibrate fixtures, this also is a large undertaking. Acquiring, cleaning, re-lamping, and measuring a fixture is already a sizable project, but a change to the colour model means changes to the calibration routines which is another significant consideration.


Everything Else

Marty - You asked about our current HSI model taking intensity into account. Currently we have a HS model. Intensity is in no way taken into consideration when working with the colour wheel or HS colour mixing. We would need to add the support to handle a concept of intensity in the colour model.

Quinn - What problems are you having resizing or maximizing the colour wheel? It's always been a MDI window as far as I know.


Hopefully this answers most of the issues you presented. Let me know if that's not the case. I think this is a good discussion and that it's really worth working out the details.

Thanks.