Color Mixing inverts along with image inversion

[Christian Choi]

Color Mixing inverts in color inv mode - opposite from v1.2. Color mixing preferably should stay in tact when inverting movies so you can use your color mixing palettes to further color the inversions

Christian Choi

[samsc]

Color Mixing inverts in color inv mode - opposite from v1.2. Color mixing preferably should stay in tact when inverting movies so you can use your color mixing palettes to further color the inversions

Christian Choi

how about both?

[litemover]

how about both?

It's up to you, when I invert an images color, I often color it further and found it awkward to try to backward mix the colors in my palettes. It also seems I can't achieve the same degree of coloring as I used to in 1.2 for some odd reason everything looks washed out. Prolly my imagination from trying to mix backward.

CC

[samsc]

It's up to you, when I invert an images color, I often color it further and found it awkward to try to backward mix the colors in my palettes. It also seems I can't achieve the same degree of coloring as I used to in 1.2 for some odd reason everything looks washed out. Prolly my imagination from trying to mix backward.

CC

Did you set up your screens correctly?
Calibrate them - change the dispay gamma ( the default is 1.6 on macs )

http://chaldee1.gotadsl.co.uk/~richa...hread.php?t=80

OS9 handles colour differently to OS 10.3
Apple also changed the way it handles colour in 10.3
Colour rendering depends on the output device - not catalyst.

[samsc]

It's up to you, when I invert an images color, I often color it further and found it awkward to try to backward mix the colors in my palettes. It also seems I can't achieve the same degree of coloring as I used to in 1.2 for some odd reason everything looks washed out. Prolly my imagination from trying to mix backward.

CC

i think the invert modes compress the hilites into a narrow range.
I added invert modes with colour the right way round.

[litemover]

Richard,

Maybe you have done it the right way around but the fact of the matter is that you are employing 2 different color mixing systems RGB(additive) and CMY(subtractive) now, whereas the better and less confusing way across the lighting platform was to just use the one more employed by lighting (subtractive) as you did before.

Here is exactly what is happenning in a more detailed description:

The standard (uninverted) color mixing system in the current and V1.2 Catalyst is based on the subtractive color mixing system i.e. cyan, magenta, yellow where 2 FILTERS combined = secondaries(RGB) and all 3 combined = black; however, since it is a video system and not white light being subtracted via filters to render color, the card's default must be additive color mixing (RGB). You must have cleverly devised a system which reversed and employed the standard lighting color mixing standard so that the colors would match up with encoders and logically mix more like a lighting fixture for us lighting folk. This all works Dandy in the Standard Catalyst *RGB default* mode even though it is really CMY not RGB.

Now, when the image is inverted, The color mixing system reverts back to True additive color mixing AKA - RGB where all colors mixed together = white and the encoders turn to red, blue, and green. This is the problem/bug.

In V1.2, the inverted color mode wouldn't affect the subtractive color mixing system and would actually color the inverted media without it approaching whiteout, instead it would darken the inversion.

In conclusion, you did do it the right way around, which is the problem, it needs to be back to the wrong way around in order for it to work properly and maintain continuity with the default color mixing system.

This fix would aid greatly with the Catalyst user's current color mixing palettes AND more importantly, not to wash out to white so quick by mixing in secondary colors.

Hope this helps, sorry if my first description was so vague.

Christian Choi

[samsc]

no.

nothing in catalyst is cmy.
its all rgb.
its all rgb because the output device is rgb.
it makes no sense at all in computer->projectors to talk about cmy.

but computer cmy is simply 1-r, or 1-g, or 1-b.
there is nothing complex about this.

what you saw with inverted colours was simply a little bug, i liked the result, so i left it in.

i added inverted colour modes that do this correctly yesterday.

---

what you need to be very very wary about is talking about lighting cmy or printing cmyk or computer cmy in the same way- they are quite different.

operating in different image colour spaces is totally different from whats going on here internally in catalyst.

[litemover]

no.

nothing in catalyst is cmy.
its all rgb.
its all rgb because the output device is rgb.
it makes no sense at all in computer->projectors to talk about cmy.

but computer cmy is simply 1-r, or 1-g, or 1-b.
there is nothing complex about this.

what you saw with inverted colours was simply a little bug, i liked the result, so i left it in.

i added inverted colour modes that do this correctly yesterday.

---

what you need to be very very wary about is talking about lighting cmy or printing cmyk or computer cmy in the same way- they are quite different.

operating in different image colour spaces is totally different from whats going on here internally in catalyst.

Thank you Richard for changing it back,

Firstly, I appreciate your candor and advice, Richard, but I very clearly understand The differences between lighting CMY and computer RGB to produce CMY secondaries etc, so I hardly think that I need to be "very very wary" as I've been mixing colors for a very very long time now and know very cleary what is and was going on in this situation.

Now, weather or not Catalyst, computers, or projectors ever output CMY in a computer sense without being mixed by RGB levels to produce this illusion hardly matters to lighting designers, lighting programmers, or any end user or Catalyst that only knows about what is going on visually on the stage - which translates that the color mixing coming out of the projector, video wall, plasma screen, or catalyst, visually - is Cyan on one channel, Magenta on another channel, and yellow, on the other.

Lastly, if it "was a simple little bug that you decided to just leave in because you liked the effect", that's your perrogative, you wrote the proggie. For all I care, leave it in as you like it but please understand that I reported it to here because *it was a bug* that I noticed and *this is the bug report forum*. I don't care to participate in a helpful effort if I'm to be repaid by a sour response.

My time is very valuable, as is all of ours, and I don't charge for my advice or perspective on this product. It's a genuine interest that I have and something that I care about the future of. I hope to keep it that way.

Sincerely,
Christian Choi

[samsc]

Thank you Richard for changing it back,
Christian.

I have to explain this to people other than yourself.

You know whats going on.

Others dont.

Dont feel patronised.

I have to try and take a more general explanatory tone for those who dont understand.

----

This is for you:

The difference between a bug and functionality in this case is non-existent.
There is no 'correct' way for this function to operate.
There is no reason why it has to work the way it does.
I didnt 'change it back' - i added another colour fx that works the way you describe.
All these things are conventions that become established or changed through usage.
For me -- v1 is not the right way to do anything. It is not a standard or benchmark.
Software establishes its own conventions.
when i can incorporate differing operating conventions - i try to do so, but i have to also try and limit the confusion that arises from adding features.
For me - none of this is at all ideal.
DMX is such a limitation. Trying to do things with a handful of channels, and avoiding too many modal states is very hard.

I am a mediator between the users and the underlying technology.
Sometimes i have to tell users how it really is, sometimes i can hide all that from them.
And in this case the underlying technology is an rgb system.

I had wished that i could set the defaults on the fader to 128 and allow users to add or subtract colour like they can in photoshop -
but the underlying technology did not work on the last generation of graphics cards- and i could not do this - and it was a very low priority to make this work.

This is how it should have worked - you should have been able to do something like the colour balance function:

[samsc]

This is how it should have worked - you should have been able to do something like the colour balance function:

And this colour balance function would need 10 dmx channels to simulate.

10 channels just to do colour balance?

What would we call them - and how would we display such functionality with 8 characters names on a hog 2 display?

RedHigh
GreenHigh
BlueHigh
RedMid
GreenMid
BlueMid
RedLow
GreenLow
BlueLow
PresLumn
???

How the f**k would the user figure out what these do?
and how they interact?
And as i cant reuse the names, i would be stuck with these function names that only worked for 'color balance'

---
Its hard trying to make something usable.
there are a lot of compromises.
sometimes they need explaining. sometimes not.