Bug with colour generator FCP 6.02

Try this in your FCP to confirm or deny.
Drop a colour generator onto the timeline.
Edit the colour by clicking on white, from the colour dropdown.
Mouse over to the RGB slider-it reports 254,254,254.
Close then reopen generator,
manually type in 255,255,255, hit OK
reopen the colour generator and read the values,
on mine I get 254,254,254!

This also affects mattes, and any generator or filter that
allows you to enter a colour parameter.

OSX 4.11
FCP 6.02

That's correct, the color range is 0-254.

All the best,

Tom

In an eight bit color space, ala photoshop, 3ds max etc
there are 256 steps in eight bit from 0-255, or 1 to 256
whether you are base zero or base 1 respectively.

I submit that 255 (0-254 as FCP reports) steps is mathematically incorrect,
and please check this against any other normal program...

Photoshop has an RGB range of 0-255 (eight bit) per channel.
3ds Max (which I've been using since 1991) has a RGB range
of 0-255 as well.

This has to be a bug, or some programmer missed the boat!

Also, if the maximum value is only 254,254,254 then this is not
pure white, but a grey!!!


As a quick Mac check, I loaded Motion and the sliders go to 255,
as they should!

If this is an oversight on the programmers end, shame on
them.


Tom Wolsky Wrote:
-------------------------------------------------------
> That's correct, the color range is 0-254.

That's correct. FCP only goes 0-254. It's not an RGB application; it's in YCbCr. HSV is 100%.

All the best,

Tom

This still does not explain that if you bring up
the RGB sliders and move them all the way to the right,
at first it says 255,255,255, when you click on OK
and reenter the sliders they say 254,254,254.

If a program offers you RGB sliders (and FCP does)
why would they only go to 254?

This makes zero sense, and Apple Motion's RGB (not YCbCr sliders)
go from zero to 255.

I am not recanting from my position.


Tom Wolsky Wrote:
-------------------------------------------------------
> That's correct. FCP only goes 0-254. It's not an
> RGB application; it's in YCbCr. HSV is 100%.

I'm not asking you to recant anything. I'm just telling you the way the application works by design. Not much point in comparing it to a different application, even if they're made by the same company.

All the best,

Tom

Fine, but in every application EVER (with the exception of FCP)
the RGB sliders go from 0-255.

Maybe this question is better asked on apple.ca discussions,
as I want to find out WHY they did this.

Thanks for your time
over

Tom Wolsky Wrote:
-------------------------------------------------------
> I'm not asking you to recant anything. I'm just
> telling you the way the application works by
> design. Not much point in comparing it to a
> different application, even if they're made by the
> same company.

Mark,

This is most likely a bug and it exists in version 7.0.2, as well. Good catch.

If you use the Apple system-wide color picker tool with some of the generators (if not all that have color settings) to set an RGB value of 255-255-255, the displayed values on re-opening the color picker move from 255 to 254. Switching to another "slider" sub-tool of the color picker will show that the "white" is still at 100% (say, on the grayscale slider).

So, if you manually set the color to true white (RGB 255-255-255), it maintains that color value, even though subsequent visits to the RGB slider sub-tool shows the values changed to 254-254-254.

Now, if you actually set the RGB values to 254-254-254, they will stay put (at those values).

This behavior also occurs for the Text and Outline Text generators (I didn't test everything that uses the Apple color picker), so there _may_ be exceptions to this behavior. (It also happens with the Color and Color Solid Matte generators.)

Using the Boris Title 3D generator, you can specify an RGB value of 255-255-255 using either the Boris colored RGB entry cells, or using the Apple color picker (by clicking the color swatch). In both cases, the values don't change. So, this seems to be unique to Apple's generators, etc.

To verify the veracity of my statements, you can use the DigitalColor Meter, which is located in the main Utilities folder (in /Applications). Or, you can create some instances of a particular generator and export a still image of one of its frames and check the RGB values in GraphicConverter, PhotoShop, etc.


-Dave

P.S. - I also took a quick peek at the FXScript source for the Text generator. By default the text color is RGB 255-255-255.

P.P.S - This behavior may be affected by the sequence codec in use and render settings.

If you guys are definitely sure this is a bug, the best place to submit it is [bugreport.apple.com] (requires a free developer account). They read every single report and will ask you for extra information if required. And the more people reporting a bug, the higher up the priority list it goes.

My software:
Pro Maintenance Tools - Tools to keep Final Cut Studio, Final Cut Pro X, Avid Media Composer and Adobe Premiere Pro running smoothly and fix problems when they arise
Pro Media Tools - Edit QuickTime chapters and metadata, detect gamma shifts, edit markers, watch renders and more
More tools...

We can call that a bug if you want, but it's such a minor one I'd be amazed if it gets any attention. The difference between 254 and 255 in 8-bit RGB is way inside the margin of rounding error for the rendering pipeline.

Just for fun, I did a test. I laid down six frames of color solid, from 250/250/250 to 255/255/255. I exported two Quicktime movies, both uncompressed 8-bit, first with 8-bit rendering and second with 32-bit "high precision" rendering.

When I took them into Nuke to check the color values of each frame, they differed. Not by much; either by zero or one, frame-to-frame. But they weren't identical.

All this means is that you get rounding errors when you work in 8-bit integer. We all knew that. If you care about the difference between 254 and 255, Final Cut Pro is not the application for you. It's not meant to be that precise in its rendering pipeline.

We're talking about a difference of less than half a percent. It's just not important.

Err.. Yea, I didn't even read the thread much... C'mon. You're working in 8 bits. Why'd you care if the saturation on your text is off by 1pixel?



www.strypesinpost.com

I guess I should probably be a good citizen and explain what I mean by rounding errors.

RGB goes from 0 to 255. Digital luminance, according to the CCIR-601 spec that started it all, goes from 16 to 235. The values between 0 and 15 and between 236 and 255 are reserved for superwhite and superblack, luminance values that can't be represented in 8-bit RGB at all; they're off-scale high and low, respectively. Since an 8-bit integer value literally cannot be less than zero or greater than 255 ? the numerical encoding does not permit it ? room had to be reserved in that range for off-scale values, so the range between white and black was compressed.

So when you dial in that color solid to 255/255/255, what you're actually doing is telling Final Cut to give you maximum luminance, which maps to 235 in 8-bit digital values.

And when you dial it to 254/254/254, Final Cut has to map that to a value in digital luminance. But there's not a one-to-one correspondence between digital luminance values and RGB values; one scale has 256 values on it, and the other has 220. So 254/254/254 RGB is actually between 234 and 235 on the digital luminance scale. Since an 8-bit integer, by definition, cannot be a fraction, Final Cut has to round off. Whether it truncates to 234 or rounds up to 235 is an implementation-dependent detail I'm to which I'm not privy.

If you force Final Cut to use 32-bit numbers, by turning on the "high performance" video processing option, then the program can more precisely represent those fractional luminance values internally ? but it still has to convert to either 8-bit or 10-bit integer values when you output. So round-off error will occur. The virtue of a 32-bit pipeline is that you lose less precision overall when you stack up mathematical operations one after another. It doesn't save you from round-off errors. It just mitigates them somewhat.

So bottom line? The way your footage looks is more affected by the layer of invisible dust on your monitor than it is by the difference between RGB values X and X-1.

I personally hate it when anything defaults to 255/255/255 in a video application because it's illegal for broadcast. Would much prefer it to default to a legal value.

Ah, but that's a nuanced point as well. Because 255/255/255 is not a superwhite value if, like Final Cut, your application maps full-range RGB values to Rec. 601 compliant luma values.

This can bite you if your graphics guy decided to be all smart and work inside 16-235, and your application subsequently crushed that range further by mapping 0-16 and 255-235 for you.

Not that I've ever been that stupid graphics guy or anything. Mmm-mmm. I've never done anything that dumb, not ever. NOT EVER.

No - I mean the text and colour generators inside video apps should default to 235/etc.

I had a graphic I sent out a while ago that was a 'White on White' theme. Terrible to work on to begin with, so I was extra careful. Then at the station someone decided to bump it up before broadcast and it shimmered like hell on TV. Very embarrassing and not even my fault.

Yea. Pure white text in FCP is broadcast legal. Check it on the scopes. FCP will map 255 in an 8 bit RGB scale to 235, which is white point on an 8 bit YUV scale, and perfectly legal. Although I tend to prefer somewhere around 90% white.



www.strypesinpost.com

Yeah, Final Cut maps 100% luminance to 235 digital luminance, which is 100 IRE on an analog scope.

When you feed it RGB data as image sequences or whatever, you can choose whether to map 255 RGB to 235 luma (the default) or whether to bring in 255 RGB as 255 luma/109 IRE/whatevs.

All things considered I wish all applications, not just Final Cut, had great big labels on the controls that said "THIS IS LUMINANCE, NOT AN RGB VALUE, DOOFUS." Or vice-versa.

It is? It certainly didn't used to be. I'll check this out.

Sequence settings, video processing tab, select "process maximum white as white". That's the default. If that is set to "super-white", then maximum RGB white be mapped up to 109 IRE.



www.strypesinpost.com

I'm fairly sure, but would love to be corrected, that that video processing setting only applies to imported RGB material, not to generators. Am I crazy to think that?

Yeah but the .. OK I just tested this by opening a text colour box in FCP and PS, and using the colour picker to choose 255 white from PS and the white changed from 'Generic RGB' to 'Device RGB', both at 100%. Over my head now. All I know is in earlier versions the default white in text used to jitter like crazy.

Theres also a drop down menu in the colour picker now that lets you choose Generic Grey gamma 2.2 profile. The default is Generic RGB.

> that that video processing setting only applies to imported RGB material, not to generators.

Nope. I just tried it. Pop on a generator, set it to super white, render. Presto, blazing highlights. Not sure why you'd want that, but it's an option.



www.strypesinpost.com

Good to know. Thanks for that, man.

Since you guys jumped on this old thread and got "excited," I'll add a few more bits to the mix...
;-)

Luminance shouldn't be used in discussing digital video (see Charles Poynton's article "YUV and luminance considered harmful" on his website poynton.com).

Also, what makes the 254 value "insidious" is that in the digital realm of the ITU specs. for SD (601) and HD (709), the 0 and 255 values are used for synching only (see Charles Poynton's article "CONVERTING BETWEEN R?G?B? AND 4:2:2" for more info). So, 254 is the highest value allowed in digital video (8 bit) "space."

Until I read, and re-read, a bunch of articles on this stuff (don't ask me why), I, too, thought like many others that we should be specifying (235,235,235) for maximum digital white in apps like FCP. That is the digital video value, as Jeff mentions, not the RGB "space" values we enter in various applications.

And, as Gerard mentioned, depending on whether you have your "whites processing" set to white or super-white, you get different values on the scopes. The scopes are a nice tool for visualizing this stuff. So, not only do the "RGB" values from 0 to 255 get mapped into values of 16 to 235, you may also get "round-off" or "truncation" errors, (and how much) depending on your processing/rendering settings (as well as sequence codec setting).

All of this technical stuff aside, the Apple color picker in FCP (for Apple's plugins) should be displaying things properly, as it does when you use the Boris text generators.

Thanks, Jeff, for the more detailed explanation. I avoided opening that kettle here (I always try to stay as non-technical as possible in my posts)... I have advanced degrees in engineering from a past life (20+ years ago), so when Jeff goes "techno" on us, my head starts to "hurt" again (as it is now)... don't use that part of my brain unless I absolutely have to...
;-)


-Dave

If you ask me, the whole point of 10 bit and 8 bit, as well as rendering in float, is so that you preserve as much detail and to prevent rounding errors that may result in posterization or banding when you post process your image. But c'mon, look on a broadcast monitor and hardware scopes and tell me the station won't pick up your series unless your subtitles is at 235 rather than 234. I'd rather the engineers at Apple spend their time fixing the other stuff and beefing up other areas of FCS (like letting us import tracking information from Mocha into Color).



www.strypesinpost.com

That said, does anyone know if the gradient generator is 8 bit or 10 bit or float? I'm guessing it's 8 bit, as vignettes tend to band in FCP, but it's merely a seat of the pants observation.



www.strypesinpost.com

strypes Wrote:
-------------------------------------------------------
> If you ask me, the whole point of 10 bit and 8
> bit, as well as rendering in float, is so that you
> preserve as much detail and to prevent rounding
> errors that may result in posterization or banding
> when you post process your image. But c'mon, look
> on a broadcast monitor and hardware scopes and
> tell me the station won't pick up your series
> unless your subtitles is at 235 rather than 234.
> I'd rather the engineers at Apple spend their time
> fixing the other stuff and beefing up other areas
> of FCS (like letting us import tracking
> information from Mocha into Color).

I'll probably fail at being clear enough, and I am not trying to belabor the point, but I never suggested that this issue with the color picker (used in Apple's generators) would cause any problems, at all.

In fact, in my testing, the 254 values showing up are a "glitch" in the color picker displayed values (and only in the RGB slider version). If you set values to 255, then later re-open the RGB color picker and see 254 shown, the actual value remains 255. So, the actual value hasn't really changed (as can bee seen in exported frames or with the Apple DigitalColor Meter application).

And, for text, most training sources and books recommend using the Boris generators anyway (Calligraphy), which may explain why it's not a well-known issue.

As a bug, it's gotta be an easy fix, as it is a display glitch with the Apple color picker (values don't change to 254 from 255).

And, yes, the difference between those values for 8 bit codecs, and with the mapping to the digital video 8 bit color space, is negligible, all things considered.

I hope we can put the 255/254 part of this discussion to bed (the color picker display bug for Apple generators), as it doesn't really keep one from getting a 255 value...

I believe that this entire thread is quite informative and should be a good reference for the future.


-Dave

The very fact the colour picker is inaccurate bugs me,
As someone who started in 3ds max, if I wanted 254,254,254
I would have typed it in-but I didn't, I discreetly typed 255,255,255.

Besides the white (and only 255,255,255 is white).
254,254,254 down to 1,1,1 are all greys, and 0,0,0 are black.
(Not NTSC but RGB)



As an animator its as annoying as rotating an object 5.625 degrees
and have the units report back that it rotated it 5.63 degrees.
(Trust me 3ds Max or Maya have theie annoying bugs)

Stickler, yes, but that's the way I see it.





D-Mac Wrote:

>
> All of this technical stuff aside, the Apple color
> picker in FCP (for Apple's plugins) should be
> displaying things properly, as it does when you
> use the Boris text generators.
>

mark@avolution Wrote:
-------------------------------------------------------
> The very fact the colour picker is inaccurate bugs
> me,
> As someone who started in 3ds max, if I wanted
> 254,254,254
> I would have typed it in-but I didn't, I
> discreetly typed 255,255,255.
>

To be clear (and, sorry for stating this again)...

When you type in 255,255,255 it DOES take this input and use it. It is only the display of the RGB values in the RGB Slider color picker that is wrong. The actual value IS set to 255,255,255 (at least in my testing, both using the DigitalColor Meter and exporting stills). Switching to a different color picker displays the correct values (e.g., the Grayscale slider shows 100%, not 99%).

So, if you use the RGB Slider color picker and select 255,255,255, you GET those values. Yes, it's a nasty and confusing display bug.


-Dave