Creating and editing color palettes

Tnsquint1Tnsquint1 Registered User
I am a little embarrassed to have to ask this, but I need help developing a reasonable strategy for dealing with color palettes on the Hog 4 platform.

My goal is to get to a point where I always start with a custom generic show file so I am not constantly recreating color and beam plaettes, views, custom effects, etc. As a point of reference, in the Hog2 days it was simple enough to select a single fixture of each fixture type to create palettes that would be recognized by any number of those same fixtures. I realize that the GLOBAL, PER TYPE and PER FIXTURE options are far more powerful but somewhere along the line I get fouled up. This problem is exacerbated when I have to start editing those palettes which I have to do all the time.

My plan would be to start with one instance of as many different fixtures as possible to create my standard color palettes. I would assume all of these palettes would be recorded PER TYPE. Whenever I start a new event, I would then merge whatever new fixtures might be necessary to my standard show file before moving on to actual prgramming thereby increasing the number of fixtures in that generic file. I am again assuming I would merge these palettes using PER TYPE.

By the way, I am aware that the HOG OS more or less requires one to stay in a single color model per fixture type. I like the idea of the HS model as it certainly makes the effects engine and detailed programming far more powerful. I am not convinced, however, that HS is truly the best model choice. I am also not entirely sure if using white and/or amber LED's with the HS model constitutes mixing color models.

Since moving into Hog 3 and now Hog 4, I have constantly run into issues with colors that will not update or that just play back incorrectly. I am fairly certain that some problems may occur due to my potentially forgetting to choose PER TYPE when recording. There have been times that the only way I can "repair" a specific color might be to use the "PER FIXTURE" option.

As I mentioned in another thread, I would like to have more than one standard color palette so that I can switch back and forth between them based on current usage. I want to make certain, before I invest any time in the process of creating a standard show file, that I am doing things in a way that will work. To some extent I have the same problem with beam parameters. It does not seem like this should be that difficult but it has been driving me nuts. Any thoughts?

Comments

  • inthe128inthe128 Registered User, Hog Beta
    edited January 2014
    I was hoping to see some answers to your questions, like you I seem to have some difficulties very much like yourself regarding colour and beam parameters.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    Color and Beam palettes are record as global as a standard. So for example you create them with one fixture(type), then they are available for all other fixture(types).
    As soon as you edit or merge some fixtures they will get more complex, you can see this when you open the palette.
    So your way/idea of adding in per type/fixture is correct.
    Please remember: If you store a palette only for color mixing and store later also some color wheel-infos into this palette they won´t be back-referenced in existing cues. (Andy this is your issue, I know)
    About HS vx. CMY, i prefer HS, because it is more accurate and efx are easier to create. Also when talking to other departments like print or graphics, HS is a "global" language.
    When dealing with LED with amber or white, I also stay in HS and create some more palettes including white/amber values and have white/amber always be part of my HS-Preset even if they are at 0%.
    Maybe we get back the calibrated colors ony day or an option to calibrate fixtures ourself. Then the whole process would be easier, because the console knows the available colorrange of the fixtures and we would only need to change type and repatch
  • inthe128inthe128 Registered User, Hog Beta
    edited January 2014
    I am no sure this is so black or white...excuse the pun.

    I have had auto coloured buttons changing colour completely, in the case of a fixture that had inverted RGB values, so my yellow palette went blue, the palette when selected gave yellow, but programming using yellow gave blue...... In that case making a copy of the fixture and fixing the values would have been a better choice of outcome, but I often wonder why programming using palettes, sometimes seems hit or miss.

    Also and certainly using fixtures that might have a white or amber channel, but also fixtures with colour correction channels can be awkward. Often I make an edit, looks good on stage and then only to find when I have updated, merged the colour goes back to what it was. All combinations of editing seem to not give back what i just re-recorded.

    I seem to have problems regarding Robe fixtures when using gobo rotation, as they seem to have fixed as gobo 1 and index/rotation as gobo 2, as I programmed with a fixture that has index/rotation on gobo one, I find even though I update gobo palettes and rotation palettes, the rotation never plays back although the programming is referencing the slow rotation palette.

    We talked about this Marc I know, but I was less than happy arriving at a gig and having a Mac 500 do pink and not amber in programming, but being able to select amber from the palette, output window shows amber, the eye see's pink.

    It seems to me and certainly when you have a show picking up whatever is at the gig that you need to do a CMY fixture, the a colour wheel fixture, then an RGB + W, + Amber, rather than doing programming with one type of fixture, which I have always managed on other console's.

    I feel not in control sometimes, in my mind i expect a any programming using palettes to reference what is in the palette on an edit without question, blue is blue whatever the fixture type. I feel somewhere along the line I am missing the point of the current system and thus it causes a lot of problems, although I am learning a lot about editing fixtures... :-)
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    Thanks for the information. I believe I am tracking with you on this. Oh, and happy New Year by the way. Let me ask this:

    When editing a color palette (which is where everything goes right down the tubes for me) can I select a type of fixture whether a single fixture or all of a particular type, modify a color (using the appropriate color model of course) and then press "RECORD" "PER TYPE" press the appropriate color palette in the directory "MERGE"? I have a tendency to do this to make quick updates to colors when I see something I don't like. Is there a better approach?

    To clarify, almost every project I do is programmed in advance in pre-visualization. Once onsite I am then going over the entire set of cues (which could be in the thousands) with very limited time. So I often just start running through things I know I have to touch up quickly such as focuses, beam edges, strobe rates etc. and often times I am just doing that on the fly as I run cues and addressing the issues that come up. That is why I find myself editing random colors on the fly as opposed to simply going through the entire palette range with all fixtures.

    On other notes, when you say that you have additional palettes for White and Amber, do you mean those values then can be "piled" on to your HS palettes? For example, if I have a WHITE palette in HS (0% saturation and any hue) for an RGBAW fixture, do you then have a second palette that has a white value of 100% an amber value of maybe somewhere between 50%-80% or so that you can add to the HS palette in your programming? Does that then cause the same problem as mixing color models in your programming?

    To me that is one serious issues with the Hog OS that I had hoped would have been resolved in the 4 series and that is color modeling. I have never understood why you can't move seamlessly between models. It has always seemed to me that if I entered a hue value of 0 and a saturation value of 100% and then decide to switch to CMY that the values should simply be C-0, M-100, Y-100 and vice versa. This is, of course not the case and is where a lot of color issues come into play with the desk. I, like you prefer the idea of HS mixing as effects are FAR more powerful and intuitive with a 2 parameter model then a three parameter model. Depending on the type of rig, there can be a lot of other potential benefits as well. I have found that, regardless of what the manual says, I get a lot of unwanted transitions in HS. When cross fading between saturated colors you are, in effect, simply changing the hue value so for example a blue to yellow cross fade will take you through a saturated green as opposed to cross fading between C/M and Y.

    Any suggestions, tips etc. are appreciated. Perhaps my entire approach is incorrect.
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    Marc,
    I re-read your post and I believe you are stating that you are adding white and amber (and as 128 mentioned, color correction) values to your HS parameters. I would like to do this as well but it seems that fixtures want to then insert CMY values instead. Are you successful with this?

    I think I am struggling with the same or similar issues as 128. I have often just assumed in editing that I have inadvertently forgotten to use PER TYPE but I have no way to really know that. Perhaps that should be a record default preference? "Record all color palettes as ______". "Record all beam palettes as _________". That might solve everything.

    From my perspective I just want to get back to where I was prior to the Hog 3 where I had a generic show that already had every fixture I normally used pre-programmed before I ever started on a show. The only time I ever created color or beam palettes was if I was using a new fixture...easy. This very simple programming process has become a huge time suck and source of frustration to me on an otherwise very elegant desk.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    Andy, do you remember which fixtures caused this? Beacuse this would be a bug, never had seen this that inverted CMY/RGB caused this.

    I agree that auto-update of colors sometimes did not work correct, i had this as well, but never find a good repro. Will try to figure that out. So that development could investigate.

    Your problem with Gobo rotation is indeed the same thing like adding a colorwheel to a colormixing palette after creating the palette and already programmed cues with it.
    The palette references to Gobo 1 and you are doing something wth gobo 2 which is different. So this is something which can be solved be editing the library. I agree as well like said in other posts, that other console provied the option that if I add infos to a palette like adding focus to a gobo palette or colorwheel to a cmy all programmed cues have this updated infos. It has two sides: what about if you have created some looks with a gobo, gobo 2, focus/zoom, iris in it... typical background pojection for example: Now you store a focus in the used gobo and gobo 2 palettes... How should the reference work? From palette gobo 1 or gobo 2? Also your look might get destroyed because of another focus value... So this might cause a lot of problems as well.
    The safe way is what you are saying Andy, this is something what is going to the fact that we use real-world values. A CMY real world is something else than a colorwheel real world. I agree that the reference to the palette is something to thing about, but also keep the bad sides of this in mind (discribed above).
    For you blue is blue, but for the console blue without colorwheel infos is something else the blue with color-wheel infos.
    I know that you would like to see the auto-update of all cues when adding parameters to a palette. I see the advantages of it but also the dangers described above.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    Scott

    you dont need to do a per type for colors. The console does it for you.
    Try this:
    Patch some StudioColor, Cyberlights and Studiobeams

    Create some CMY colors with a StudioColor.
    They are now available also for the other types. (open the colors and you see that it is a global palette)

    Now select the Cybers, change the values and merge them into the palettes
    Open tha palettes, you should see all fixtures except cybers and cybers

    Now the same thing for Studiobeams...
    Same result. In Color and Beam the separation per type is automatically done by the console.

    About HS, I have to check, I think so.... Was a while that i used rgbwa fixtures....
    Hope that my memories are not wrong. If so, I´m sorry
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    See some screenshots here:
    https://www.dropbox.com/sh/xa3tnh0utfzn9h5/Pgz-BUizBe

    I took the auto palette red (step 1)
    Merged some other values step 2-5 (always took all fixtures, but works also of you just take one fixture)
    Only merging, NO per type option selected

    In Step 6 I edited one single fixture, here I took the per fixture option to be sure that it wont change for the whole type.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    Tnsquint1 wrote: »
    On other notes, when you say that you have additional palettes for White and Amber, do you mean those values then can be "piled" on to your HS palettes? For example, if I have a WHITE palette in HS (0% saturation and any hue) for an RGBAW fixture, do you then have a second palette that has a white value of 100% an amber value of maybe somewhere between 50%-80% or so that you can add to the HS palette in your programming? Does that then cause the same problem as mixing color models in your programming?


    Yes, I have a user kind that gives me seperated color parameters for HS, amber and white.:
    https://www.dropbox.com/s/6htemxy4rq16xs0/Screenshot%202014-01-02%2013.58.06.png

    So I create first my HS Colors and then some amber/white palettes to add on top of it.

    See screenshot:
    https://www.dropbox.com/s/mkjlea50ouofk8c/Screenshot%202014-01-02%2013.45.12.png
    Color 81 is a HS color, Color 82 is an amber/white color

    Also when working with this userkind you can create HSAW palettes, color 86 was created using this userkind, HS stays active even if you bring in white and/or amber:
    https://www.dropbox.com/s/w80iikk6hkyy3s7/Screenshot%202014-01-02%2013.55.33.png
  • inthe128inthe128 Registered User, Hog Beta
    edited January 2014
    MLorenz wrote: »
    Andy, do you remember which fixtures caused this? Beacuse this would be a bug, never had seen this that inverted CMY/RGB caused this.

    I agree that auto-update of colors sometimes did not work correct, i had this as well, but never find a good repro. Will try to figure that out. So that development could investigate.

    Your problem with Gobo rotation is indeed the same thing like adding a colorwheel to a colormixing palette after creating the palette and already programmed cues with it.
    The palette references to Gobo 1 and you are doing something wth gobo 2 which is different. So this is something which can be solved be editing the library. I agree as well like said in other posts, that other console provied the option that if I add infos to a palette like adding focus to a gobo palette or colorwheel to a cmy all programmed cues have this updated infos. It has two sides: what about if you have created some looks with a gobo, gobo 2, focus/zoom, iris in it... typical background pojection for example: Now you store a focus in the used gobo and gobo 2 palettes... How should the reference work? From palette gobo 1 or gobo 2? Also your look might get destroyed because of another focus value... So this might cause a lot of problems as well.
    The safe way is what you are saying Andy, this is something what is going to the fact that we use real-world values. A CMY real world is something else than a colorwheel real world. I agree that the reference to the palette is something to thing about, but also keep the bad sides of this in mind (discribed above).
    For you blue is blue, but for the console blue without colorwheel infos is something else the blue with color-wheel infos.
    I know that you would like to see the auto-update of all cues when adding parameters to a palette. I see the advantages of it but also the dangers described above.

    I agree Marc with much of what you say, how cue information interacts from palette information is more complex here due to real world values, while it helps a lot of fixture swapping, speeding up many aspects of taking hold of a show with different fixtures, it does on the same token slow other things down to the point of not getting it to do what you want or spending time editing fixture files.

    We talked about finding a fixture to program with that has everything so to speak, so it has two rotating gobo wheels, or its a CMY fixture with 2 colour wheels. Perhaps my need to have a core show which is never used in real life, a show that gets cut to the bone or I need to replicate fixtures, swap fixtures to the degree of making an RBG par can be a VL3500 wash in todays show etc is a tough one, certainly my last console was better at this by a long way, however in other ways its not anywhere near as good as the Hog.

    I have to re-program this show anyway, but still wondering the best way to do this. I have the problem with the colour wheel one not allowing the encoder to select colour in the current show and I have found a few fixtures where the colour slot info is out, so thats another fixture file edit to correct that. Now i found a way to have the encoder function for colour and still merge stuff from the original show i am keen to start again, but still thinking of the best way to do this and not have so many problems.
  • inthe128inthe128 Registered User, Hog Beta
    edited January 2014
    Just a note on the rotating gobo thing:

    To my mind if the fixture has its rotating gobo on gobo 2 as an example, thats fine. The cue has a break up with slowly rotates. I update a gobo, say slot 2 on gobo wheel 2, then update the slow rotation palette. In this case I would expect the cue to replay both palettes, the rotation appears not to follow programming even if the original information was derived from a fixture where gobo 1 has the index/rotating gobos, I just think it should.

    Regarding less than good fixture files, I have sent a few in for checking, had one with 4 pan channels and no tilt channels, easy fix when you opened the file up, inverted zoom channels of a few Robe fixtures, also the Robe DLX had 0>255 when it should be 255>0 on colour. You might remember I had some mini-scans that really caused some arse with the split fade and strobe channel, in the end that was a badly written file and once I made an edit I got the best way to deal with split functions.

    Is there an official way to send in fixture problem requests. I would like a way to send comments and see that they have been received, confirmed as a problem and re written, anything I have sent in I have not had a reply to.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    Andy, what about if you create (or let me create it for you) an ANDY-Light... a Spot that has 2 rotating Gobo Wheels, CMY, 2 Color Wheels and the other needed features.
    With that fixture (maybe based on a VL3000 plus adding these other features) you build your base show...
    I know that slot colors are sometimes are not correct, might be due to revisions in hardware, software or DMX charts. There is no real easy solution, but this is not a real development bug, it is more a thing of communication between manufacturers and lib-creation or even making/providing correct DMX-Charts.

    I´m still thinking of an easy or good way to alter palettes with or without the option to have influence on existing programming.
    Maybe a record-option that when you merge into an existing palette that this will allow existing cues to be referenced to all values. This would help in all your color problems or if you have recorded a NC without any CTO infos in it and would like your NC now be a bit warmer because of TV recording or so, then you only would need to add CTO to your NC palette and all cues will have it into.
    Ok, a work around for this situation would be to edit the CTO default, but still I understand your request.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    inthe128 wrote: »
    Just a note on the rotating gobo thing:

    To my mind if the fixture has its rotating gobo on gobo 2 as an example, thats fine. The cue has a break up with slowly rotates. I update a gobo, say slot 2 on gobo wheel 2, then update the slow rotation palette. In this case I would expect the cue to replay both palettes, the rotation appears not to follow programming even if the original information was derived from a fixture where gobo 1 has the index/rotating gobos, I just think it should.

    Regarding less than good fixture files, I have sent a few in for checking, had one with 4 pan channels and no tilt channels, easy fix when you opened the file up, inverted zoom channels of a few Robe fixtures, also the Robe DLX had 0>255 when it should be 255>0 on colour. You might remember I had some mini-scans that really caused some arse with the split fade and strobe channel, in the end that was a badly written file and once I made an edit I got the best way to deal with split functions.

    Is there an official way to send in fixture problem requests. I would like a way to send comments and see that they have been received, confirmed as a problem and re written, anything I have sent in I have not had a reply to.

    You know all direct contacts you need ;-)
    You can also send me a list and I can pass it on
  • inthe128inthe128 Registered User, Hog Beta
    edited January 2014
    MLorenz wrote: »
    Andy, what about if you create (or let me create it for you) an ANDY-Light... a Spot that has 2 rotating Gobo Wheels, CMY, 2 Color Wheels and the other needed features.
    With that fixture (maybe based on a VL3000 plus adding these other features) you build your base show...
    I know that slot colors are sometimes are not correct, might be due to revisions in hardware, software or DMX charts. There is no real easy solution, but this is not a real development bug, it is more a thing of communication between manufacturers and lib-creation or even making/providing correct DMX-Charts.

    I´m still thinking of an easy or good way to alter palettes with or without the option to have influence on existing programming.
    Maybe a record-option that when you merge into an existing palette that this will allow existing cues to be referenced to all values. This would help in all your color problems or if you have recorded a NC without any CTO infos in it and would like your NC now be a bit warmer because of TV recording or so, then you only would need to add CTO to your NC palette and all cues will have it into.
    Ok, a work around for this situation would be to edit the CTO default, but still I understand your request.

    Marc: Incorrect fixtures I know are not always going to be an HES thing, is the official fixture files not created by and outside company and HES has a way to created requested fixtures themselves? I have to use a selection of lamps that once downloading the DMX chart does not give a correct result.

    I send in to email addresses, but would love an online form which would give some idea to status of the request and also allow anyone with the same problem to see if that fixture is in the system for update.
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    It sounds like perhaps I have been over-thinking what should be a relatively simple process. I will have a RHFB3 in the office later this afternoon and before I start on new programming I'll spend an hour or so experimenting. My output will be the Pre-Viz so I can put in as many types of fixtures as I want which will help.

    Thanks for the insight!
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    Scott,
    if you would like to try with a FB3, keep in mind that there are no userkinds. So if you would like to create the HSAW stuff there you must set keep parameters seperated in the preferences.

    Andy, jhmemmm, the germans would say: JEIN ;-)
    The problem is that the number of nes fixtures is increasing so fast that it is hard to keep track and also sometimes it takes really long to have a good lib-file, for example we are working on a good lib for the JB Sparx since 8 weeks... Daily-business gets into the way, urgent requests, dmx-layout changes and so on

    I agree that such a database would be great to have....
    But this would need an extra person just taking care of that database, and manpower is like always a problem. I think if possible they would love to do stuff like that...
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    Copy that and thanks for the up. I just want to get the general work flow sorted out. I really appreciate your help.
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    My programming time became far more limited than I had anticipated so I just plowed through it as quickly as possible. I only had media servers and a bunch of Mac 101's so I simply selected all fixtures, dialed in the color using the HS model and pressed record and the appropriate directory button. Easy. What I found interesting was going back to view the directory, once completed, in spreadsheet format. I found a few of the colors were recorded as GLOBAL while most were not. So odd.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    What did you see when you open the palettes that where not shown as global?
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    I knew someone would ask that and I honestly do not recall. I won't be in front of a desk again until Thursday. I'll post back when I can view it again. Nothing but meetings until then.
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    Actually, in spreadsheet view the only thing the Hog3 spreadsheet view shows me is yes/no under the "global" column. For whatever it is worth only OPEN, RED and SCARLET appeared as global colors. Those were the first three that I created, however, I continued creating all other color palettes in the same fashion and never hit CLEAR on the programmer.
  • MLorenzMLorenz Registered User, Hog Beta
    edited January 2014
    What do you see when you open the palette itself

    Pressing i.e "RED" and then "OPEN" or espacially a palette that doesnt show the the global indicator.
  • Tnsquint1Tnsquint1 Registered User
    edited January 2014
    Unfortunately, that project is completed and no longer have access to the desk. I can ask my operator to check it this weekend.
Sign In or Register to comment.