Hog III Novice

[quote=Dave Klotz]CORMACJACK

Go start another novice link and yOU

thanks for your polite reply,it's fantastic to see members being so friendly to those who who have not made the "grade".

Thanks marty and tom.

Appreciated Cormac

No worries Cormac....always here to help...none of us pretends to know it all. That's what makes this forum such a great resource!

Let's all just play nice in the sandbox now shall we kids!!:soapbox:

Quinn is quite right, and has beaten me to the punch again:beerchug: :friday:

....the "toothpick" movement could be very useful indeed for other areas.

as mentioned - XYZ positioning (make Pan & Tilt take shortest path...vs travel in XYZ coordinates.) amongst other things.

Hadn't really thought of Gobo modes though....good one! That's always bugged me too.

I didn't really want to go there yet till we dealt w/ HSI vs CMY....but the door has been opened.....

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.

If 3d space is mounted, might how about the movement of the surface with a track ball.
I think that the track ball is a sphere, too.
And, I want to use I-wheel when moving in it.

Though it is thought that 3D can be freely moved by this.

Thanks,

Akito

I hate to do this to you Tom,....but:rolleyes:

Page 15 of the printed Hog-3 manual v1.3.8-EN detailing how the HSI color model works:

- it states that the Intensity in HSI "...is identical to the dimmer control on most fixtures."
:notworthy:

Having said that..

I think we're talking about two totally different changes. While a true 3-D space might be useful...:33:

I think all we really need to do is make the "wheel" a "sphere" or maybe even just a "half sphere" with only a "white pole". As I mentioned before Hue moves like lines of lattitude, and saturation moves like lines of longitude. If a "half sphere" this changes nothing as far as color calibration only user interaction.:)

As far as being able to "see" the other colors, maybe there needs to be a split screen view of the new sphere as an option. I.E. view as normal, or do say a double view in the same window, one from the black pole, and the other like we are already used to seeing it...from the white pole. This would not be necessary with a "half-sphere" though as our current view of the wheel would be unchanged.

All we need to add then is a "mode" that allows for one of two options:
1 - "Normal" - Hue and Saturation move along the surface as already discissed
2 - "Toothpick" - This crossfades HSI color changes via a mechanical CMY path and goes directly from one HSI color point to another.
These should be "slot-bar" options somewhere...I suggested "Mode" or "Enable" earlier.


Regardless of any of this, I do like Akito's notion of mapping Hue and Saturation to the Trackball as we already have Intensity on the I-Wheel. Should be as simple as a trackball button option. As for knowing that the Trackball is now in "Color Mode" maybe the blue LED could fade in and out as an indication. A color sensitivity setting under control panel would be nice similar to the ones for P/T and pointer modes. This could be very useful even under the current model.
Nice one Akito! :beerchug:

Marty,

I understand that Intensity is part of the HSI colour model. My point is that there is never a time currently when tapping on the colour wheel will change the Intensity value of your fixtures in the Programmer. Our colour model is completely unaware of Intensity and the colour space that we use isn't designed to handle this. This means that we need to design a way to handle variable colour parameters other than the primary additive and subtractive mixing colours (RGB / CMY), like Intensity, White, Amber, CTO, and CTB. Our colour model, the visual representation of it, how we crossfade through it, and how we colour calibrate for it would all need to change.

The "mode" you refer to is actually a way to tell the console which colour space is being used for calculating the crossfade. The two options with our current model would be a fade that uses raw dmx values (cmy) or a fade that uses abstracted real-world values (hs).

I think that the trackball / i-wheel for moving through the colour space is a good one. If a sphere ends up being the best solution this seems to be a nice way to navigate through it.

Thanks.

Tom,

Agreed, if we go to a truly 3-D spherical environment, we would need a third wheel to navigate that space as to our "depth" if you will.

I really don't think we need to go there though. The more I think about a half-sphere model....the better it feels. Simply map our current wheel onto a half-sphere....no need to define "depth" because we are only travelling on the surface, until we take a "toothpick" path/mode.

[quote=teerickson]
The "mode" you refer to is actually a way to tell the console which colour space the fade is being used for calculating the crossfade. The two options with our current model would be a fade that uses raw dmx values (cmy) or a fade that uses abstracted real-world values (hs).

:arms: Yup!!! That's what I was originally talking about days ago. This is much needed to make HSI as it stands now really powerful!

On the issue of CTO & CTB, I rather like the way that they are handled now as Color Temperature adjustments....rather than actual color adjustments.

Yes color temperature affects the final color, but I don't think that they should be included in any model based on HSI because they effectively are changing the base white point.

As for iWhite and iAmber on LEDS....that's a bit tricker.:33:
- I kinda feel like iWhite should be CTB...since that's really more what it is. (White LEDS are really just blue ones that are being pushed)
- iAmber is the slippery one (I use the Pixel-line products quite often). I'm sure there's gotta be a way to mesh this into HSI somewhere between green and red. Defining those "seams" and transitions is really the hardest part. It is surely too saturated to be treated like CTO.

{EDIT*** Defining the transitional seams between Green-Amber-Red shouldn't be any harder than defining the ones already between CMY & RGB no?!?!}

[quote=teerickson]
I think that the trackball / i-wheel for moving through the colour space is a good one. If a sphere ends up being the best solution this seems to be a nice way to navigate through it.

Even if we don't have a sphere, I think this could be useful to us right now!:)

Thanks for sticking with us on this Tom, we've got a lot of ideas bouncing around on this thread!:beerchug:

[quote=Akito.H]If 3d space is mounted, might how about the movement of the surface with a track ball.
I think that the track ball is a sphere, too.
And, I want to use I-wheel when moving in it.

Though it is thought that 3D can be freely moved by this.

Thanks,

Akito
I also like the idea adding trackball control to Hue and Saturation like Marty said.
I guess, it would be nice to control hue and saturation simultaneously using your thump/trackball and other fingers on I-wheel...

Too bad there's only blue LED in trackball...it could change colour :)

Thanks for every reply.

I feel the thing that a advanced discussion is done here now.

The thing whose LED of the track ball is only blue is regrettable.
I want also to switch the color.

However, I do not like to change hardware.

Then, how about blinking for this 3d Color sphere mode?(As well as the Blind mode)

I think that it can achieve this function without improving hardware if it is this method.

Akito

Hi,

the idea about the trackball for the Hue/Saturation is a great idea. Also like it, with/or without the 3D Discussion (very interesting, and great ideas), but I also see the problems behind it.
But if possible go for the Trackball, the blink idea (or fade) is also good and doable :)

Tom

3D Space

it's gotta go on the encoder wheels. as the extra dimension's purpose could vary (W,A,CTO,XYZ...), the color wheel shouldn't try to expose anything more than common functionality.

at least for now.


Colour Calibration and Compatibility

i'm gonna leave alllll of that for your homies to decide, we're just going back and forth and the answer's utimately gonna come from them anyway...


Everything Else

true, they've always been parented, but definately not trapped...

somewhere between 803 and 1112, we went a little overboard with Qt.

now everything but the toolbars are trapped inside the "Primary Screen"s.
and nothing's got a titlebar, just a QWidget docked at the top to fake it...

so there's no maximize/restore without reaching all the way over to the other screen, no minimize (which was totally useful for restoring rather than re-opening in a different position), no dragging to move, and user-resize is disabled. probably all to get move/size/focus etc working (cuz the "primaries" still behave, *and* have 31 vertical pixels of non-client area???)

i'm gonna have to find some time to re-load and take screenshots of how great it was before going back to the stupid, stupid WHII-style "layout". (especially on a lonely laptop...)

Hey Quinn, you lost me a bit on that last part "Everything Else" :confused:

We talking about Hog-3PC for iPC now?

Quinn,

You said "there's no maximize/restore without reaching all the way over to the other screen, no minimize (which was totally useful for restoring rather than re-opening in a different position), no dragging to move, and user-resize is disabled. probably all to get move/size/focus etc working "

You can drag, resize, etc all you want the various windows within the Wholehog 3 system, you just need to unlock them first. In addition you can use the various shortcuts with the Open key to move, minimize, etc without having to "reach accross the screen". Please refer to page 87 (section 13.2.3) of the Wholehog 3 User Manual for further details on these functions.

thanks,

awwwwwwwwwwww!

well of course now that Move's working, Lock should too...

jeez, go me. :o

Marty,

I like your point about CTO and CTB.

They really are modifiers that would affect the colour temperature of the entire model and could be handled separately. It would still be very nice if the change was reflected in the colour picker, but this becomes difficult if we have multiple fixtures selected that have different CTO / CTB capabilities or values.

I think we still have some thinking to do about the easiest way to display and control colour, but we certainly have a good start here and we can continue this discussion as we have new ideas.