Talk:Test Image Generator Program
From Tigwiki
From Glenn Chan March 23 2007:
Regarding differences in saturation algorithms... one factor that affects
the end result is whether or not the algorithm maintains constant luminance
(this requires linear light processing / undoing gamma correction in the
image). There is a webpage on my website with pictures (roll-overs) that
illustrate this:
http://glennchan.info/articles/technical/saturation1/saturation1.html http://tinyurl.com/342anq
Glenn Chan Toronto, Canada Currently pursuing software development*
From Ted Langdell, March 24 2007
You'd think that with the length of time that Non Linear Editors have been around... that someone would have created a "Universal" graphic that would produce proper color bars when opened or plopped into the timeline of any NLE.
Rob's thread regarding the TIG (test image generator) caused me to drop the test chart he'd posted into an FCP timeline just to see what happened.
It was WAY out of whack for NTSC video. There may be a way to create something using that software to get the aspect and pixel dimensions correct, but getting the luma and chroma to be correct may prove to be elusive.
The results on my waveform and vectorscope got me questioning whether other test signal files produced accurate results... so I spend part of Friday finding out.
--- With Final Cut Pro 5.1.4 on a 3GHz MacPro (Intel) I set up a standard NTSC DV/DVCPRO timeline as commonly used for editing DV footage over Firewire and then conducted some experiments with different "SMPTE Color Bar" graphics files.
I say "SMPTE Color Bar" to imply they're unproven.
The FCP timeline was sent via Firewire to a Sony Digital8 camcorder and also a Sony DSR-11 DVCAM deck and from there to picture, waveform and vectorscopes. (Tek 1485R and 520A respectively.) NTSC Bars created by FCP displayed virtually the same from both devices. *within a degree of chroma phase or 1-2 IRE
As a control, the timeline contained the standard NTSC Bars and Tone as supplied from FCP 5.
Still images from that file were exported as various still image files: .jpg, .psd, .qtif (Quicktime Image Format) and .tga.
I also placed a stillframe of bars made by FCP using the "Make Freeze Frame" function within FCP.
On that still and all the exported/imported image files, the PLUGE's below 0IRE bar was eliminated.
In putting all the stills into a timeline and comparing against the original SMPTE Bars video clip, there some interesting developments:
In all cases, the RGBYMC vectors stayed as they were supposed to: within the appropriate boxes., with a slight shift on some vectors but no shift took the points outside the "legal" boxes.
The I & Q vectors changed noticeably on all the exported stills. The I vector moved about 15 degrees counterclockwise toward blue, and its amplitude was markedly reduced. See photos.
There was a slight bit (under 5IRE) of shift in the crossover area around 50IRE when stepping through the exported files that had been reimported back into FCP.
On the 768x576 .png Rob sent or posted to the TIG... the I & Q patch luma level, was significantly boosted. The RGBYMC points were boosted out of their 2-degree boxes, but the I and Q vectors didn't get as whacky as the other stills did.
I also checked two files generated by "Test Pattern Generator" a free utility from Synthetic Aperature, the makers of Color Finesse.
This utility runs on Mac OS9... (no giggling) and is intended to allow one to create various patterns including SMPTE Bars with or without 7.5IRE setup... gray scales, convergence charts and overscan charts in various heights and widths.
The file WITH setup moved black up to 10IRE, made the lightest PLUGE chip brown, raised the crossover point about 7 IRE, reduced chroma level, and affected the amplitude of the I and Q vectors.
It's RGBYCM, I and Q were on the right vectors, but down in level about 5IRE. 100% white was on target.
The chart it made with no setup the boosted the I & Q patch luma level to 25 and 15, (it should be 0,) changed the I vector a few degrees toward cyan and dropped the I level a tad.
My conclusion: The "Imported" Bars I tested are not good for critical reference purposes, at least within the parameters above.
If your NLE or CC software outputs SMPTE Bars that are correct, don't bother trying to reinvent the wheel.
Results might be different... might... for someone with an AJA, Blackmagic or other card capable of outputting video from NLE software... or Photoshop to an NTSC monitor.
If someone HAS that ability (Photoshop to NTSC Monitor) I'd be curious to know what they see on an external Waveform/Vectorscope if they open the files and output through the card.
Getting a file with the correct dimensions, bar widths, luma, chroma, I & Q that works in ANY NLE would be useful.
Maybe someone can figure out how to do that in Photoshop. Translating pixel width to correct NTSC horizontal timing... x pixels = y microseconds... ought to be interesting.
Paging Mr. Chan... Mr. Friesenhahn
Ted.
(Rob... I have some Wave and Vector photos to illustrate the above but haven't time just now to process them. I will when I get a chance and will post to the Wiki if anyone wants to see the results.)
T
Ted Langdell Ted Langdell Creative Broadcast Services Marysville, CA Main: (530) 741-1212
From Joe Owens March 24 2007
Quote:
"Getting a file with the correct dimensions, bar widths, luma, chroma, I & Q that works in ANY NLE would be useful."
It would be like a universal TSG, but even those come with a jillion selections -- I think you're asking for a "one-size fits all" bra. Some things that are indigent to one format are illegal in others -- for instance composite I,Q flags are totally illegal in RGB and can't be re-created properly because they require negative values, or values that when modulated create chrominance below 0 IRE.
"Maybe someone can figure out how to do that in Photoshop. Translating pixel width to correct NTSC horizontal timing... x pixels = y microseconds... ought to be interesting." One line of SD NTSC is 63.5 microsec... subtract 10.2 mikes for blanking, (= 53.3 microsec), divided by 720 (remembering these are non-square pixels) yields 74 nanosec per SD pixel. How would this be useful, again?
If my math is correct.
Joe Owens
Presto!Digital Colourgrade
302-9664 106 Avenue
Edmonton, Alberta T5H0N4
+1 780 421-9980
jpo@prestodigital.ca
From Lewis Saunders March 24, 2007
Ted Langdell wrote: Still images from that file were exported as various still image files: .jpg, .psd, .qtif (Quicktime Image Format) and .tga. [snip] Results might be different... might... for someone with an AJA, Blackmagic or other card capable of outputting video from NLE software... or Photoshop to an NTSC monitor.
I'm not sure if this has any bearing on the inaccuracies you saw, but Final Cut monkeys with imported stills in an attempt to match CG images with video originated ones, which will have been created with a different display gamma in mind.... more information here: http://docs.info.apple.com/article.html?artnum=93794
Lewis Saunders Freelance Shake London
From Richard Jackson March 24 2007
Ted -
If you're trying to make RGB files and get to SMPTE levels (or if your conversion path passes through RGB-land), then you can't get there from here!
Remember that "computer" 8-bit RGB-space covers only a portion of the available BT-601 YUV values. For example, R = G = B = 0 means "Black". There is no way to express "blacker-than-black" without using negative RGB levels. Likewise, you can't express "whiter-than-white" in standard 8-bit computer RGB-space because R = G = B = 255 means "white - and you can't make a higher level. This is why video that contains overshoots in YUV space (but is still within allowed YUV ranges) will get clipped at 100% white when translated to 8-bit RGB levels.
This is why standard 8-bit RGB levels can't express the blacker than black pluge bar. Also, in the SMPTE Color Bar pattern, the -I and Q bars have a luminance level of Black but +/- 20 IRE of chrominance - which also can't be represented by 0-255 8-bit RGB levels.
[Technical aside: it's not the fault of "being RGB" - the problem lies in the range of levels defined by standard 8-bit "computer" RGB. There are other RGB formats that allow for blacker-than-black and whiter-than-white levels, but it's the common 8-bit RGB range that is the typical bottleneck when translating file formats]
To correctly show all of the SMPTE bars and levels, the test signal needs to be created in BT-601 YUV space (which DOES allow for blacker-than-black, and chrominance levels independent of luminance) and kept there through any encoding/decoding/translation paths. This is what FCP does with its internally-generated color bars: they create the frame in YUV-space, then translates from YUV to DV directly without going through an RGB step.
Having said that, there is one "gotcha" in Final Cut Pro's YUV path: when they do 8-bit YUV rendering, they use their own special luminance level range that puts Black at 0 instead of the typical BT-601 "16". This means they have lots of extra room for whiter-than-white overshoots, but no space for blacker-than-black. I suspect that's why your pluge disappeared...
- Richard Jackson
CineSys Design
