each color profile in color management still utilizes a single parent rgb translator from the very start of importing into after effects? if yes, i understand then; if not, im done reading this thread lol
each color profile in color management still utilizes a single parent rgb translator from the very start of importing into after effects? if yes, i understand then; if not, im done reading this thread lol
btw digital fusion is an RGB package afaik, so the issue is not presented.
That is more a question for Adobe than for this forum. I was just saying, "color management" is another topic from what I'm shining a light on here..Originally Posted by dbx
If you want to see how After Effects handles things, read their documentation:
http://www.adobe.com/designcenter/af...color_mgmt.pdf
Adobe outlines many potential work flows in the paper. It looks like now that After Effects supports floating point, linear light and 16 bit work flows, all kinds of stuff is possible. But you still need to get the data in!
I found this little tidbit interesting:
"The translation of colors from YCbCr to RGB is normally done by the codec used for a specific video format. This codec may translate the luma values to limited range RGB (16-235) or the codec may translate luma values to full range RGB (0-255). In some cases, a codec used in the workflow may have controls for how it will interpret luma values. In other cases, this translation is hidden from the user."
Notice how codecs enter the mix? This quote addresses exactly what I'm going on about. Adobe assumes YOU know what is in your data. They aren't gonna hold your hand. It isn't as easy as just picking a working space and having everything just work. In fact, if anything, it works the other way around. You know what the data is THEN you pick the profile. They seem to provide profiles for all possible combinations of data though. That's pretty cool. (Last time I used AE myself was about a million years ago. It's come a long way since then.)
The bottom line is if you want my little trick to work you need to figure out where to intercept the YCbCr to RGB conversion and make it do what you want it to do. (period)
I've been using AVISynth (It's already part of my 3:2 pull down removal pipeline anyway) , but I realize it's a little too hard core for some people. I don't know what else to suggest though.
Last edited by lordtangent; 2007 October 21st at 03:39.
Most of you will already know how the YUV model works, but I've written an article about it on my website. My website is dutch, but the article is english. There's also a video that visually shows how it works.
However, I got major issue's with Internet Explorer, it hates my xhtml. Entire paragraphs remain hidden until selected. So please use a real browser like Opera or Firefox.
http://www.rednet.nl/vision/articles/165
Your article is great. I like the sense of humor. And very good graphics BTW! You should consider putting them under Creative Commons and getting them on Wikipedia. IN particular I'm talking about range_yuv.png and range_ycbcr.png . I've never seen it visualized that way and it's a very good way to show the concept.
You really have your head wrapped around the YUV stuff. I love the way you visualize it and demonstrate it being re-constructed from the three channels. How did you calculate the colors for visualizing the Cb and Cr channels in RGB? Did you just figure out the color extremes using the rec601 math?
One technical mistake I noticed was at the end of your video. You say that YCbCr is 220 "bits" vs 256 "bits" for RGB. I think you mean CODE VALUES. Both are only 8 bit per component sample.
Also in the description of CMYK vs. CMY color model, in the graphic it seems like the "theoretical" and "actual" illustrations are reversed. In THEORY, CMY should be enough, but it isn't in practice and black also needs to be used.
For completeness, you might consider also adding HSV color model to your line up of color models. (It's not used in any practical way like RGB and YCC, but it's a common model used for picking colors and some image manipulations) Cleaning up the LAB/XYZ description might also be nice. (You might consider showing the CIE 1931 "horse shoe" or 3D "color cube" to visualize the color space.)
I'm being a little nit-picky, but you have to realize lot's of people who read the article might not have much background in what you are trying to teach them. It's important that everything be succinct and accurate.
Hey thanks for the comment.
You are right about the mistake in the video; I will change it when I'm back at my desk. But for the CMY/CMYK graphic, I really think it is correct. You see, in theory with CMY mixed you get black. But when you actually do it, you'll notice that the center is not black and you will need to add extra black. (Both graphics are CMY, maybe you're confusing the first one with CMYK?)
About more on color models, I've actually overdone myself because my basic intent was to write about YUV as compared to RGB. Then, because I made some graphics just for myself to visualise the different models (like some people (me too) keep writing on notepads when they're thinking), I liked the graphics so much I decided to include them and write a bit to refresh people's memories. HSV was also in my draft to explain how 'desaturating an image' works because it is mentioned in the video, but then there were two problems. One, I have not enough time and there is sooo much else I want to make or write about in my spare time. Two, there is sooo much info to be found about basics for everything (like color education), but afaik not so much about the part between basic knowledge and advanced knowledge, so my goal is to fill that part where I must trust that readers have gained basic knowledge elsewhere.
And after rereading the above paragraph I must say, if it somehow sounds harsh, that is absolutely not how I meant it!
For the color representation of Cb and Cr I used a program from school called 'Matlab' which is like a library of math of the world. (I'm still a student). There's an image toolbox and a library that converts between RGB and YUV. When you create a gradiënt on U or V and convert it to RGB, you'll see what colors they represent.
Greetings everyone,
I'm a new HV20 customer and just discovered these forums. Already I have found a tremendous amount of great information here - thanks to everyone posting.
I shot my first 24P video with the camera this morning. Not really great lighting situation etc. but that's OK because I mainly wanted to just get something imported to the PC to start working out a good video processing workflow.
We don't currently have a high-def TV and DVD/MPEG2 will be the target output medium for now, but we intend to archive all the captured video .m2t files of video we want to keep so that I have all of it to do more with later. We'll pretty much just be making home movies of our cats etc. to share with family and friends, and possibly a bit of youtube. I guess you could call me a video/DVD hobbyist with a preference for high quality and highly-compatible final "product".
So I found this topic and another talking about the range of color the HV20's can record (ie, the superwhite range). There has been a lot of good reading here -- I think I might understand the issue now, and have seen some need to pay attention to colorspace conversion in the past (such as proper use of the "Output YUV data as Basic YCbCr not CCIR601" in TMPGEnc) -- but I am fairly new to DV/HDV and the tools pipeline will be changing to get the video from the camera to the PC. I would like to try to keep that extra 10% of white range if the camera is recording/using it.
I got the video clips imported and de-interlaced using Farnsworth's avisynth/dgindex/etc. technique, and now I'm experimenting with settings in my MPEG2 encoder of choice (TMPGEnc 2.5+). (I know.. I know... it's really old, but it does good work with the right settings).
It looks like my toolchain will basically be:
- HDVSplit (which in turn will use ffdshow since for some reason it thinks I don't have any MPEG2 codecs on my system)
- farnsworth's IVTC method using DGIndex, TIVTC, and Avisynth
- TMPGEng, using the .avs script files as input files
I did have virtualdubmod going to frameserve to TMPGEnc (and usually how I do things anyway) but since I'm not looking for intermediate .avi files it seemed an unnecessary step, at least when I'm not trying to only feed selected ranges of frames to TMPGEnc.
So in thinking about this, it seems there are multiple places where a colorspace conversion could take place and possibly change the video stream, if I'm understanding this correctly. If I understand this at all, to keep the extra 10% white headroom, I don't want to ever clip/scale the RGB color values until the final MPEG2 encode, where I would set something to deal with the padded black?
These seem like places in the toolchain that could affect the colorspace:
1. ffdshow/libavcodec used by HDVsplit - ffdshow has a Levels configuration tab which appears to be how you configure input and output levels. It also has a "modify only luminance" option. If ffdshow is the first thing touching the video coming in from the camera, would I want to do anything here (for example, maybe set min16/max255 for input, and also min16/max255 for output), or maybe enable the Levels option and leave 0-255 as valid input and output ranges to tell libavcodec to NOT scale the colors? Or is ffdshow/libavcodec even doing anything to the video when HDVsplit captures it from the camera anyway?
2. DGindex - DGindex has its own configuration for converting color space with the YUV -> RGB option, where you choose either PC scale or TV scale. Based on the HTML manual, PC scale seems to be the option that doesn't clip the RGB, so if I understand correctly, this is what I would want here to still not step on the extra white headroom?
3. Avisynth - again it's possible to specify colorspace conversion here... if I use the
ConvertToRGB(clip, matrix="PC.709")
in the template.avs, wouldn't that clip the 235-255?
4. TMPGEnc - the final output encoder - You can choose to "Output YUV data as Basic YCbCr not CCIR601" - which is further described with "Then Y range of MPEG YCbCr is not 8-235 but 0-255. Since DV format movie has already recorded as CCIR601, better result can be expected if this option is enabled". So it sounds like I would probably want to have this checkbox on too, to keep TMPGEnc from scaling the input color? Would I also want to apply one of TMPGEnc's color filters, for example maybe to set a "custom color correction" profile that addresses the padded black?
Sheesh I guess I really don't understand this after all. Sorry for being so dense.
24junkie
On the question about whether ConvertToRGB(clip, matrix="PC.709") would clip the RGB -- I answered this myself by reading the avisynth docs. PC.709 keeps the full range.
24junkie
I can't seem to actually get ConvertToRGB() to work though. Here's what I've tried:
Template .avs file:
v=MPEG2Source("s:\video-capture\sasha-pharaoh-2007_11_03-11_45_22.m2t_.d2v")
a=MPASource("s:\video-capture\sasha-pharaoh-2007_11_03-11_45_22.m2t_ MPA PID 814 DELAY 106ms.mpa")
audiodub(v,a)
TFM(d2v="s:\video-capture\sasha-pharaoh-2007_11_03-11_45_22.m2t_.d2v")
tdecimate()
DelayAudio(-0.222)
ConvertToRGB("s:\video-capture\sasha-pharaoh-2007_11_03-11_45_22.m2t_.d2v", matrix="PC.709")
Result:
Script error: the named argument "matrix" was passed more than once to ConverttoRGB (S:\video-capture\sasha-pharaoh-2007_11_03-11-45_22.m2t_.avs, line7)
Template file:
v=MPEG2Source("s:\video-capture\sasha-pharaoh-2007_11_03-11_45_22.m2t_.d2v")
a=MPASource("s:\video-capture\sasha-pharaoh-2007_11_03-11_45_22.m2t_ MPA PID 814 DELAY 106ms.mpa")
audiodub(v,a)
TFM(d2v="s:\video-capture\sasha-pharaoh-2007_11_03-11_45_22.m2t_.d2v")
tdecimate()
DelayAudio(-0.222)
ConvertToRGB(v, matrix="PC.709")
Result:
Can open the .avs in TMPGEnc, but it no longer sees the file with a 23.976fps frame rate, it sees it as 29.97. This can't be good...If I remove the ConvertToRGB line altogether, it is seen again as a 23.976fps source. I tried moving the ConvertToRGB line higher up in the .avs file but TFM and tdecimate both refuse to work if I put ConvertToRGB above either, citing colorspace probs.
24junkie
I am able to use this in the .avs script instead of ConvertToRGB() and it does not modify the framerate or anything else I can find:
Levels(0, 1, 255, 0, 255, coring=false)
I bumped into a site that has a lot of video and codec tools
May be useful on this thread.
http://www.videohelp.com/tools/secti...eo-identifiers
One in particular is useful - codec_sniper.exe will list every codec installed on your machine and whether is is OK or broken.
so does Sherlock.exe but better info provided.
Last edited by HalD; 2007 November 4th at 14:28. Reason: revision
"Today's headlines are just whispers of history."
HAL...a BIG Thanks for that site. It's got a CRAZY load of freeware and trialware there. I just wanted to note that the MORGAN JPEG2000 software is only $20.00 at this site for anyone interested.
Edit: it seems he MORGAN version is not the 4:4:4 version...but...good find anyways.
hey all
Like 24junkie, I'm a new HV20 owner and I found this forum by Googling "HV20". This is a fantastic resource and Redsandro and lordtangent (and of course, others) I think you're doing a huge service to your fellow video enthusiasts.
I have one quick question, I Google'd "YUV color in premiere pro cs3" and the first result was http://livedocs.adobe.com/en_US/Prem...801A50136.html, and the first line is:
Adobe After Effects works in the RGB (red, green, blue) color space. Adobe Premiere Pro, however, works in the YUV color space.
I've read a few times in this thread lordtangent where you state Premiere Pro is frustratingly an RGB program only. Is this livedoc referring to something different?
Also, I'm very interested in following in your exact footsteps, and I'm wondering about when you stated that doing the color conversion "correctly" (for lack of a better word, since it seems this issue is still very fluid and an exact, correct way of doing things hasn't been pinned down yet) you'll end up with muddy blacks that can be fixed in post. Not expecting a step by step Premiere how-to, but how exactly would one begin to fix these blacks?
EDIT---
I also found this at http://www.dvpa.com/public/94.cfm :
Q: Does Adobe Premiere Pro 2.0 support YUV color space?
A: Yes. Adobe Premiere Pro 2.0 still supports the RGB color space and now also provides native support for YUV color, enabling you to preserve the native color space of the original video material. This support ensures higher quality in your final video productions because the source footage no longer passes through a lossy conversion to RGB color. It also improves overall application performance because the application isn't performing processor-intensive color conversions.
So, am I to understand that, if we capture from the HV20 in Premiere Pro, edit in Premiere Pro, and firewire back out to the camera from Premiere Pro, the issue of converting color is moot? (Obviously if you wanted to take your footage into an Autodesk application or some other RGB only compositor or something, this issue is still very important.) But for those of us who are shooting video that won't be composited with special effects plates in Smoke or After Effects, and won't need 3D elements added to it from Maya or any of that... are we safe?
Last edited by Michael Davis; 2007 November 5th at 00:21. Reason: Adding information
Also, Redsandro, I just got done with your article, and that video was VERY VERY impressive, and extremely easy to follow and understand. Bonus points if English is not your native tongue. Seriously, that was fantastic.
Michael,
Bly me, you are right! I was thinking of the old Premiere. It looks like they finally added native YUV processing in Premiere Pro. So, yes, you can totally ignore the RGB conversion stuff. Working in YCC might also speed up your rendering a little also, since you are working with about 1/3rd less data in 4:2:2 and there are no internal color conversions to slow things down.
I did find this. Premiere can still work in RGB also:
http://livedocs.adobe.com/en_US/Prem...aef7-7e38.html
I'm going to experiment with YCC work flow, but I think in the end I'll probably stick with my RGB work flow. I need RGB for other reasons.
You need to give it the handle to the clip you actually want to convert. It looks like you are giving it the name of the file on disk. That is not how it's used. Because of how ConvertToRGB24() likes to be called, you need to give it the clip explicitly. Also, you are not making the frame rate of the clip 24fps, but tdecimate() is blowing away frames. The clip is going to play back at 29.97, but with only the 24 progressive frames that are in there. This code should help. It addresses both problems in two lines of code. Just replace all your ConvertToRGB stuff with this.
Code:clip=AssumeFPS(24000,1001) # Full scale YCbCr --> RGB conversion ConvertToRGB24(clip, matrix="PC.709")
Lordtangent - thank you! I had tried using "clip" originally and was getting an error message about it being unknown, so started looking for other things to try. I'd seen clip used a lot of times in the avisynth docs among examples of commands but couldn't find anything describing it. So I figured it was something you should "insert your video clip name here". Thanks for the clarification about it being a file handle-type thing.
After much thought, and re-reading of your (and others') posts in this thread, it seems to me that maybe if I am wanting to preserve any "superwhite" in the stream, and if the main target of any video processed will be MPEG2 for DVD, then I should probably just make sure I leave the colors alone throughout the pipeline - ie, read them in via avisynth with the PC.709 profile, and make the other RGB color-using tools in the pipeline also leave them alone too (such as USING the "Output basic YCbCr instead of CCIR601" checkbox in TMPGEnc Plus). This way I keep any data that reads above 235 luminance, and the black will already be at 16+ because it was never below that in the original camcorder recording anyway.
I guess the remaining thing would be working on the video for use of video/images on the computer - grading the black so it doesn't look milky/washed out. It would be interesting to see how folks do this while keeping the "superwhite" data.
I shot almost an hour of our cats today and am simply blown away by the quality of video this camera takes.
Thanks to everyone!
24junkie
Thank LT. I, too, was receiving that matrix error... I must train my mind not to blank when confronted with scripts and text that looks like a programming language.
Sharp Shooter
Ha... well, it is a programming language...
I learned "Programming" myself by just making scripts first. (I'm a lousy programmer BTW... really all I can do are scripts, and simple ones at that.) But my point is, don't be scared of things that look like programming languages. Just take it step by step and try to make sense of the puzzle. They are really much easier to figure out than the kinds of puzzles people routinely do for fun. (I hate "puzzles", so I think I'm in a position to comment on this. I mean, Shoduku? OR WETF it's called Who actually ENJOYS that "game"?) There are puzzles to figure out that actually lead to something at the end of the day.
As a sidenote I must comment that I much enjoyed 'The Seventh Guest' and 'Myst' in the past..
Next thing to do for me is retry getting supers in/out of Avid. I thought I failed before, but documentation and BobbyMurcerFan both note that supers are handled.
Funny thing, in old gaming days I guess the public was easily impressed but you can clearly see interlaced video is used with a progressive product (video game) (see attachment).
Also Michael Davis, I'm Dutch so that's a ka-ching on the bonus points.
Some people don't like spiders; some don't like flying; other don't like heights.
I don't like programming languages. But I'll try to overcome it.
Sharp Shooter
At the very bottom of that page, it states:
I'm assuming "highest possible quality" means 0-255 RGB. (Maybe that's wrong, maybe it's a 24-bit color space that takes 16 gigs of RAM and a dual Xeon quad-core to handle.) So, if you can have a YUV (are YUV and YCC the same thing?) project running, and then you apply an RGB effect to the clip, I wonder what happens to the output? It seems in this case, it would be beneficial to convert all your sources to RGB, correct their blacks, and have everything in the RGB color space so as not to worry about color conversions of timeline effects occuring on the fly. So by all means, continue to keep us posted on your findings. If I were ever to do a project where I'd like to add some CGI plates or whatever, I want to know I'm doing it the best way possible.Choose Project > Project Settings > Video Rendering and then select the Maximum Bit Depth option to have Adobe Premiere Pro process an effect at the highest possible quality. Keep in mind that this option uses lots of processing power.
Also, finally, maybe a stupid question: are digital televisions in the YUV color space? Or will there be a day when everything is RGB and we don't have this problem any more. I know the FCC has decided to pull the plug on the NTSC signal in (I think) February of 2009. Will that be the death knell for color space conversions? (At least from digital video to CGI, we'll still have to worry about RGB to CMYK for print, I assume.)
YUV (Actually YIQ in the case of NTSC TV) was invented out of the desire get color into the old composite video system, but not break old B&W TVs. (the entire sytem was only B&W at first, so all the TVs in existance at the time were B&W). Georges Valensi is typically credited with the invention. You can probably imagine where this is going... if the B&W signal is treated as Luminance (i.e. "Y") then the color components could be tacked on as a separate sub carrier and not break old TV sets that only know B&W. As time progressed, it turned out that YUV (AKA it's specific variants, as YIQ, YPbPr, YCbCr, or just YCC) was useful for other things. For example, before the advent of digital, there was still a need to "compress" the signal somehow. YUV to the rescue! "Chroma sub-sampling" is possible in YUV type color models. (But not in RGB). When digital came along it turned out that chroma sub-sampling was useful there also. Less data in to the compressor simply meant it had less to deal with when doing the compression. I also sometimes improved compressibility because the chroma carrying channels could be compressed more heavily before the over all picture suffered too much visually. It's a simple form of lossy pre-compression really, but it set things up for the REALLY lossy compression down stream.
We probably will not see the end of YUV type color models any time soon as they are still used quite extensively even in digital video. MPEG2, MPEG4, etc. All use it. And they are the foundation of the current and next gen digital video equipment.
The funny thing is, the YUV type color model must always be converted back in to RGB before display since the color primaries of all display devices are RGB.
Last edited by lordtangent; 2007 November 5th at 17:43.
When exporting a frame with Avid and compare it to a manual AVS 709 frame, the color is very slightly off. AVS is a tiny little bit more green. It's not that AVS actually did 601 because the difference is too slight. Any ideas on this?
One of them has their implementation wrong. Or perhaps there is a precision issue related to one of the particular implementations. I've noticed similar shifts with other codecs and softwares. It's typically minor... but noticeable enough that when you see it it really starts to worry you. (This is what I was talking about with round-tripping stuff though color models willy-nilly. Color shifts like that will adds up and could really mess up your picture, and that's even leaving the whole issue of rounding error and lost precision out of the story.)
Other than writing your own software (or a plug-in for an established system) I'm not sure what the solution is really. We are at the mercy of the software providers.
One test you could do is try doing the conversion in a third and even four system, and compare the results. If you go by the notion "Majority wins", the software that ends up not converting like all the rest is probably the broken one.
Posting Permissions
Reply With Quote
