Floh Peters
Forum Replies Created
-
Please send me one of your scaled files to floh (at) mac (dot) com. I will have a look
-
If the source image is not in an 4:3 aspect ratio, scaling to 640*480 will distort the image. Try scaling proportionally to 640*whatever or whatever*480, depending which scaling gives you the number on the “whatever” property that is larger than the expected value. Then crop to 640*480, e.g. by creating a rectangular selection with a fixed size of 640*480 and cropping everything outside the selection.
-
Problem is that probably quite a bit has changed in the file import since V5.5. But if you are sure that your image is 640 pixels wide and 480 pixels high, it should import correctly into Media 100. Maybe you can post a screenshot of your import settings here?
-
If you are working in 640*480 in Media 100 (you only should work in 640*480 when working with the old Vincent hardware and not with P6000) you need to scale your image to 640*480 in Photoshop as well. They should import correctly into Media 100 then.
-
[David Issko] “Why can there not be one setting? Many people are being caught out by this issue as it is not widely known or understood. “
Oh, the mysteries of QuickTime and ColorSpaces. This whole 0-255 and 16-235 is only one part of the huge amount of QuickTime problems, including Aspect ratio problems, gamma shifts, setup problems, limited dynamic range,…
Here ia a short explanation:
Most video material these days is stored in YCbCr files. Most of our video codecs are in this format, including all the Media 100 codecs, ProRes, Uncompressed,… In the early days of video editing, some systems worked in RGB, though, which seemed to be the natural way for Computers, since most image manipulation on Computers was done in RGB in the early days.
Still, QuickTime is a very RGB-centric tool, and most of the processing in e.g. AfterEffects is done in RGB. Now the native YCrCb files (which is the video space also used e.g. for SDI signal transmission and for recording on DigiBeta decks) have to be converted into RGB if they are passed around in QuickTime applications. Inside Media 100, the whole conversion is handled by Media 100 (in case the image needs to be processed) and therefore shows no problem. In most other applications (excluding e.g. Apple Color) the conversion from YCrCb to RGB is done by the QuickTime architecture, which handles a RGB signal to the applications.
Now there are 2 standards on how a YCrCb signal gets converted into RGB, or to be more exact on where white and black levels get mapped to. As you probably know, a YCrCb signal can have parts that are below black and above white. You can see a signal going over 100% Luminance on your Waveform monitor, and you can see it go below 0%. These signals are stored in YCrCb QuickTimes, and these above 100 and below 0 levels are preserved, since they are a part of the native YCrCb colorspace.
Now the question is what to do with these signals when converting to RGB. The “StudioRGB” conversion, implemented in Avid and Media 100 for example, defines that the 0% black gets mapped to RGGB16,16,16, while 100% white gets mapped to RGB255,255,255. The advantage is that even in AE you have access to your signals above 100% and below 0%, e.g. if you want to recover crushed whites or blacks in AE in a colorcorrection step. Plus, you have the benefit that if you process a file through AE, if you do no colorcorrection you will end up with your exact same image, with the below 0 and above 100 values.
Apple decided to take the opposite approach, which maps everything between 0% and 100% to RGB 0-255, or the full RGB spectrum. The benefit is that you have a little bit more detail in your RGB converted file. But if you have a signal that goes above 100% or below 0%, you cannot recover this in AE or other QuickTime apps, since the signal gets clipped immediately on YCrCb to RGB conversion. Plus, if you simply render a file through AE without applying any effect, you will also lose this data.Changing this is really difficult without breaking many workflows. Ideally QuickTime would be reengineered in a 32bit float colorspace, I guess, with lossless conversions and access to all data. But still it would break many assumptions and workflows, so I am not really sure how to get out of this problem. It is somewhat similar to e.g. the field order issues we have, with some codecs being upper field first and some lower field first. This absolutely makes no sense, but you simply cannot change it overnight, since hell would break lose.
“Good” QuickTime tools (like e.g. BitVice, and partially AfterEffects) have the option to support both Colorspaces, giving you the choice for your source material. It would probably even be better if QuickTime “knew” about these different ranges and would compensate for that. On the other hand, each time QuickTime tries to compensate for some Gamma issues it ends in total chaos and in all kinds of broken workflows. There is a reason why most hi-end film-pipelines are dealing with Cineon or DPX files instead of with QuickTime…
-
Sounds like some sort of codec mismatch. What codec did you use for Acquire and for Render?
-
[joseph stillman] “then readjusted the settings to ProRes422HQ and its better but not quite there yet.”
It is not going to be better than that as long as you use Compressor. Compressors MPEG2 encoder is not that great. The exported file from Media 100 in ProRes is nearly identical from your source material (it is recompressed, but I bet that nearly nobody will be able to tell the difference). If you then used the hi-quality encode setting in Compressor and you set the field order correctly, there is nothing you can do to improve the results from Compressor.
You could try BitVice for MPEG encoding, which should give you better results.
-
[Jack Shepard] “Thanks for the answers Floh. It is rendering more than just the ColorFx though. It is going back rendering the entire piece of media it appears. And some of these clips are 10 minutes to an hour long. Any idea on why it is doing that? “
The system has to render everything that either has an effect applied to it or is placed on a different track than VaVb for export. So either you have a ColorFX applied to everything, or a TimeFX, or another effect, or you placed your material on a track above the VaVb track.
-
[Jack Shepard] “1) When a byref file or self contained file comes out where the brightness level has shifted and become washed out is that due to mixing codecs? “
Yes. Apple Codecs (ProRes, DVCProHD,…) work in a 0-255 RGB range, while Media 100 codecs work in 16-235. So if you are editing in one and rendering into another, you will see brightness jumps if you export by ref. But this means that you not only have ProRes and DVCProHD, but also a 3rd codec (a Media 100 codec) to explain your brightness jumps. No problem inside Media 100, but not good for by ref (or self contained) exports. You still can do a QuickTime export into a codec of choice, though.
[Jack Shepard] “It was exporting fine but I added some Color FX and now it wants to rerender all the footage upon export (it’s a LOT of footage) so the render time is enormous. Is this due to me switching codecs once again?”
If you want to export ColorFX, they need to be rendered. This is not related to codecs, but to the fact that although you can play the ColorFX in realtime, they need to be rendered before exporting.
-
Do you have Media 100 EDLs, or Media 100 timelines? If these are EDLs, they should import fine. If these are timelines, you can export them from Media 100 as EDLs to import them into Avid…