-
color space problems
Hello everyone,
I wonder if anyone has developed an effecient workaround for the following issue with standard PAL DV – PAL DVD workflow: we all know that native DV video is YUV and the resulting MPEG2 going to DVD is also YUV. In the meantime, Vegas is only working in RGB space (just like After Effects). The result of this is that everything goes fine with colors in a YUV-RGB-YUV workflow in Vegas for as long as the only thing I do to a source DV video on Vegas timeline is cuts. Once a frame has to be re-rendered, however, colors change. This problem becomes especially obvious in case of PIPs, titles and other overlayed editions making the original frame’s colors in the background look different as compared to the preceding/following frames where no editions/alterations occur.
One practical solution to that would be to apply a ‘null’ color filter forcing thereby a total re-render of the video and thus achieving a uniform look throughout the whole timeline, but I guess that’s rather weird both in terms of time it takes and, what is more important to me, general color deterioration it leads to. Even more so for those ‘semi-legal’ YUV colors that exceed Rec. 601 and/or Rec. 709 but still can be perfectly displayed on a regular LCD/CRT monitor. And even much more so, taking into account that standard PAL 4:2:0 sampling by itself leaves little color information to let it bleed any further.
One would suppose that the solution lies in using a more ‘colorful’ intermediary video format like YUV 10bit 4:2:2 that wouldn’t suffer that much from RGB conversion as standard PAL DV 8bpc 4:2:0 does. However, converting source video into anything like that using Vegas (even in a 32bpc project) seems to be of no avail. Could anyone give me a clue, please? At the moment, I just try to leave my source footage intact and limit my editions to cuts only at color-sensitive scenes (yes, you’re right — this is not a right solution, because there are always scenes that need to be properly white-balanced or color-corrected…but in most cases this would turn my bright orange sunset colors into something…so much differently looking yellowish…with no means inside Vegas (it least that I know of) allowing me to grade the colors back, so I’d prefer to leave everything as is). No such bypass is available in After Effects, though. YUV-RGB-YUV conversion occurs there no matter what your workflow is.
And last but not least, I think I have to say that I don’t do any broadcast video, so my first priority is whether or not colors are being visually adequately converted rather than whether or not they exceed ‘bradcast safe’ levels.
Couldn’t find any helpful info on the forum, so I would greatly appreciate any practical suggestions.
-
10 Replies
-
Gleb, I think you’ll find several articles on Glenn Chan’s site to be of interest, particularly the color space ones.
-
Thanks for the reply, Mike. I surfed through his site and, although found it very useful in that it explains color coversion basics, can’t see how this information can help me.
My question rather concerns the general problem of YUV-RGB conversion which in most cases can’t be done 100% adequately just because of the math (rounded-up figures, negative values treatment, etc.), no matter which RGB model (computer or studio) is used. Unless, of course, you can convert 8bpc YUV (DV) to something like at least 12-14 (16 would be the best option) bpc RGB, which would in such case be properly matched, processed and converted back to 8bpc YUV by any RGB video application. Vegas doesn’t do this. Actually, there is no such convertor that I know of, but maybe I just overlooked it.
To easily see what I mean, try doing this:
1. Import a DV footage (source)
2. Duplicate it and place two events on top of each other on your timeline
3. Add titles to any one of the two events
4. By soloing a track, output them one after another to a TV monitor (as far as I know, this can only be done in Vegas via your camcorder plugged to the PC’s FireWire; viewing events on your PC monitor doesn’t show the difference, so don’t bother).You will see the difference in colors between those two events. If you find a footafe with ‘semi-legal’ colors like overbrights, sunsets, etc. — you can assess how drastical the difference could be.
-
Gleb ~
Hmm! This one has got me curious. Over two hundred shows for broadcast on Vegas here and have never experienced the issue as you describe it. Have just tried doing exactly what you said. I am assuming you mean that the clip with the title has been rendered?
The set-up: Watching the clips on both the Vegas vector scope and WFM and an external hardware vector and WFM set plus observing the component output results via a Miranda DV Bridge Pro on a grade 2 broadcast monitor. The results: I see no difference to the actual footage on the Vegas scopes, the external scopes or the video monitor. None that I can measure even on expanded waveforms on the hardware scopes. The segment where the titles are though is a different story. The background video clip has not been affected in any way level wise but the scopes tell me the titles are through the roof. As one would expect.
I assume that you are using a true broadcast ‘monitor’ that has no AGC set-up on the vision circuits. The reason I ask this is that a lot of so called monitors aren’t true in the sense that they will adjust the video peak to peak level dependant on the levels coming in. Bearing in mind as you said that Vegas works in 8 bit RGB colour space you will find that any titles in a clip that contain white or other high luminance levels will push these to 110 on the waveform monitor and if the titles also have black in them the black levels will go down to -8 below blanking. This is the RGB 8 bit 0-255 video gamut. Totally illegal for broadcast.
The same applies to the chroma levels. Pure red for example will push the vector out to a screaming 148 instead of the broadcast max of 100. Push these sorts of levels to a monitor with AGC circuits and sure as anything you will see changes to your overall picture gamut because the monitor is adjusting based on the levels it sees coming through on the titles.
Try this experiment to see if you can chase this down. On your titles apply the Sony ‘Broadcast Colors’ plugin. If you are in PAL make sure the 7.5 IRE box is unchecked and that the Studio RGB [16 to 235] box is checked. From the drop down menu select ‘conservative’. This will now bring your titles to 1 volt peak to peak. Black being 0 and the whites and high luminance colours to 1 volt. Render out a clip with these titles in it and see if it changes your video clip gamut.
It’s a dirty way of doing it but by using the broadcast colour plug in at the ‘Video output FX’ plug point above your preview window you can apply these 16-235 levels to you entire program output, video, graphics the works. These 16-235 levels are the correct RGB levels to equate to the YUV colour space gamut. In effect it just clips anything above 100 and anything below 0 to give you a 1-volt p-p signal. In a perfect world you would ‘grade’ and colour correct and level correct each and every clip to meet the required standards. This we have just done on a two-year doco project that had the budget. For a weekly sports show that we work on it’s the quick and dirty method because of budget and time constraints.
Another caveat. I have seen in some camcorders that the video pass through mode, firewire to analogue; employs an AGC on the analogue processing side so this can affect what’s going through to the monitor. If both the camera and monitor employ AGC circuits you would never know where you are. Using Vegas’ waveform and vector scope monitoring is the only way to know if your levels are correct whether you grade every clip or use the quick and dirty ‘broadcast colors’ plugin. BTW we have found the Vegas scopes to be accurate enough for broadcast delivery.
Chris Young
CYV Productions
Sydney -
Wow! That was quite an in-depth answer. Thanks, Chris. Below are my comments:
> Over two hundred shows for broadcast on Vegas here and have
> never experienced the issue as you describe it.Here goes the difference between you and me. Like I wrote above, I do not do any broadcast video. If I did, I wouldn’t have noticed any problems either, because RGB 16-235 gamut cuts it all. But I’m doing video just for home DVD playback, which is not limited to just 16-235 levels but is instead PAL DVD YUV 4:2:0 (0-255 gamut or even wider, depending on the cam), which is the same as native DV. So my problem is to preserve colors to the most possible extent, leave them as they were.
> I am assuming you mean that the clip with the title has been rendered?
I meam that once Vegas has to render a frame, it does so by converting 8 bpc YUV into 8 bpc RGB, which is not sufficient since 8 bpc YUV stores noticeably more color information that 8 bpc RGB principally can. This results in a color shift. Posterisation. I don’t know how to call it — colors just deteriorate. Sometimes it’s not obvious (that is in a scene, for example, with colors very similar or identical to those RGB can reproduce). But sometimes, when colors are barely legal (if at all) in terms of RGB (studio or computer) color gamut, the difference is awsome. Again, if your video will go to the air, it doesn’t really matter becuase whatever your source colors are, they shall anyway be clipped to narrow studio RGB gamut. So in your case the problem has to be solved the other way: a cameraman shall shoot his video with that in mind and shall not allow colors exceed the ‘final destination’ broadcast color gamut.
> Watching the clips on both the Vegas vector scope…
It will only show you computer RGB colors and not the full native gamut of your DV video.
> …and WFM…
If you mean a FireWire monitor, that’s quite strange you see no difference. Is the monitor you output your video to via FW a TV monitor, not a LCD TV or computer monitor?
>…and an external hardware vector…
I’m not sure what signal this external device gets. If you plug it to your video card output, you’ll most probably get the same computer RGB colors, already clipped. As far as I know, Vegas is only capable of outputting the ‘true’ video signal through some special hardware cards (like BlackMagic, AJA, etc.) listed in the manual. I don’t remember exactly which ones Vegas supports and I personally don’t use any.
> …plus observing the component output results via a Miranda DV Bridge Pro on a grade 2 broadcast monitor.
I’m not familiar with that kind of equipment and this specific setup. Make sure that in both cases you get an output of what’s on Vegas’ timeline directly, without RGB intermediary conversion and without color clipping on the side of your external equipment.
> The results: I see no difference to the actual footage on
the Vegas scopes…You won’t see it there.
> …the external scopes or the video monitor.
That’s strange to me. I just plug in a regular CRT monitor via FireWire and see the difference clearly. Check what signal your external hardware gets. Try seeing a video that you know is ‘illegal’ in terms of broadcast gamut (overbrights will do perfectly).
> I assume that you are using a true broadcast ‘monitor’ that
has no AGC set-up on the vision circuits.Well, I’m actually using my TV set. Whether it’s ‘true’ or not — I have no idea 🙂 Same about AGC setup.
> This is the RGB 8 bit 0-255 video gamut. Totally illegal
for broadcast.But quite legal for me. I can see no reason to limit the colors in my video for as long as they can be reproduced by my DVD-player and TV.
>…you will see changes to your overall picture gamut
because the monitor is adjusting based on the levels it sees
coming through on the titles.Hmm…if it was the problem, then, if I understand your reasoning correctly, the video behind the titles must become brighter, more vivid as its levels are being pushed up? Is that right? In fact, the effect I see is quite opposite to that — colors get rather faded, lose their brightness.
> Try this experiment to see if you can chase this down. On
> your titles apply the Sony ‘Broadcast Colors’ plugin.
> …
> This will now bring your titles to 1 volt peak to peak.That will narrow down the entire color gamut of my video to just 16-235. While I’m looking for a way to retain it as wide as it was shot.
> In a perfect world you would ‘grade’ and colour correct and
> level correct each and every clip to meet the required standards.I tried that. But couldn’t get back those sunset colors as seeing on my DV tape.
> Using Vegas’ waveform and vector scope monitoring is the
> only way to know if your levels are correct…Again, there is no such thing in my workflow as ‘correct levels.’ They are correct for me if identical to those I see on DV tape.
> BTW we have found the Vegas scopes to be accurate enough
> for broadcast delivery.They should be. If I was doing broadcast video, I wouldn’t ever rise this question.
-
Gleb ~
Hi. Sorry, maybe in my reading I didn’t fully see what you were getting at. I think I got the gist of it now!
For what its worth the results as I outlined are as we see them. Just for reference the WFM is a Waveform monitor, which is used for monitoring video levels, primarily luminance levels. The Vector scope is designed for measuring chroma levels. The Miranda unit comes from Miranda Technologies, miranda.com, and is a unit that complies to broadcast spec and enables fire wire DV streams to be converted to full SMPTE ITU-R BT.601 (old YUV) spec for recording to VTRs that have YUV inputs. Another one of the Miranda units goes from fire wire to SDI and vice a versa.
In the strict sense of the word YUV should be expressed as YCbCr as it is the ITU-R BT.601 world wide standard for digital component video. I still say YUV but really should say YCbCr but old habits die hard.
But I’m doing video just for home DVD playback, which is not limited to just 16-235 levels but is instead PAL DVD YUV 4:2:0 (0-255 gamut or even wider, depending on the cam), which is the same as native DV.
PAL YUV 4:2:0, DV or DVD, is restricted to the 16-235 levels not 0-255 and herein lies your problem when you talk about colour shift or ‘posterisation’ as you call it. When you bring any YUV gamut signal, 16-235, 4:2:0 or 4:2:2 into an 8 bit RGB environment, or vice a versa you have colour space sampling takes place.
In this case the YCbCr gamut is converted to computer RGB 8 bit 0-255 colour space. In other words the YCbCr gamut range of 219 is represented across the 256 RGB gamut range of the computer. In this case the computer has the ability to represent all shades of the YCbCr gamut without any real visible artefacts. Your described ‘posterisation’ problem now develops when you now want to go back to the 8 bit YCbCr colour space with its narrower gamut.
For example you could have a nice graduated blue sky, or graduated sunset red sky, as you mention, which once digitised is now represented by the wider RGB 256 bit colour space. On conversion back to the 219 available in the YUV space there is no direct bit for bit representation hence the shades coming from the 256 colour space for which there is no direct equivalent in the 219 available are shifted up or down that 219 colour space to the bits that come closest to representing those 256 bit chroma levels. For a much more in depth understanding of this go to:
https://compression.ru/download/articles/color_space/ch03.pdf
Explains it far better than I could within this post.
This problem has a name and it has plagued digital broadcasting for years. It’s called ‘concatenation’ and in video terms can be summed up as:
“Concatenation is the name given to the linking of digital systems and compressions in tandem. Each compression encoding pass removes information and the compatibility of the final concatenated system can cause concern.”
Given that each encoding pass removes information we start to understand why we see chroma ‘banding’ or ‘posterisation’ as you put it, which is a pretty accurate description as that is how posterisation effects are created, by throwing away information. Do a few generations back and forth between YUV and RGB systems and you will soon see degradation in picture quality. Sadly the 4:2:0 colour space with its limited chroma sampling is possibly the worst at exhibiting these problems. It happens from the other end as well though because when creating graphics on 10 bit 4:4:4 broadcast systems we have to limit the colour palette for any graduations used otherwise we see very bad banding artefacts when going into any 8 bit system, NLE or linear tape suite. It’s even mildly noticeable going into a 4:2:2 10 bit Digi-Beta environment. To overcome these shortfalls stay 8 bit YUV or 10 bit YUV SDI the whole way depending on your system and you never loose information. For a lot of us though the costs involved in buying and running these high-end SDI solutions doesn’t work out economically with the ever-diminishing budgets we seem to have to work with. The 8 bit and 10 bit SDI standards are the accepted SMPTE/ITU standards that have been implemented over the years to overcome some of the problems you are witnessing. Vegas 8.0 has implemented a 32 bit floating point setting which when working in 8 bit video can help with some of the banding issues. Sony states:
When using 8-bit input/output, the 32-bit floating-point setting can prevent banding from compositing that contains fades, feathered edges, or gradients.
Anything rendered in fact. In practice I find this helps in some cases and not so much in others. Wish I could suggest some other answers to your problem but I have not yet found any way of getting around what you describe, well not unless I use SDI. Wish I could!Chris Young
CYV Productions
Sydney -
Chris,
Thanks for the reply.
>…and is a unit that complies to broadcast spec and enables
> fire wire DV streams to be converted to full SMPTE ITU-R
> BT.601 (old YUV) spec for recording to VTRs that have YUV
> inputs.Perhaps, this is that very stage in your workflow where video signal is being clipped to broadcast safe gamut cutting thereby all ‘illegal’ colors?
> In the strict sense of the word YUV should be expressed as
> YCbCr as it is the ITU-R BT.601 world wide standard for
> digital component video.The most correct abbreviation technically would be Y’CbCr, I guess, as the signal is gamma-corrected. But that doesn’t really matter in the context of this discussion.
> PAL YUV 4:2:0, DV or DVD, is restricted to the 16-235
> levels not 0-255…Why is that? Most DV camcorders output YUV 16-255 levels, don’t they? Anyway, there is no way to see the ‘true’ levels within Vegas as it analyses video AFTER YUV->RGB conversion, already clipped. As an example, on this page: https://aeclub.net/forums/index.php?showtopic=4686&st=30 (it’s in Russian, but in the lower part of the page there are screenshots clearly demonstrating what’s being discussed there) you can see what my Vegas vectroscope showed on an ‘illegal levels’ short video footage (native DV). Further down the page, there are screenshots from other people’s systems vewing that very same DV video through Edius and Adobe Premiere (working in YUV color space) vectroscopes (with defferent levels). All the files (source and outputs in different formats) were uploaded, so you can download them and try to see what’s going on.
> When you bring any YUV gamut signal, 16-235, 4:2:0 or 4:2:2
> into an 8 bit RGB environment, or vice a versa you have
> colour space sampling takes place.Color sampling with different schemes like 4:4:4, 4:1:1 or 4:2:0 is a different story with its own conversion problems. But in my particular case, color sampling for both the source and the output remains the same: PAL DV/DVD standard 4:2:0. I have no idea what happens to video in the sense of sampling scheme when it’s decoded by Vegas DV codec.
> Your described ‘posterisation’ problem now develops when
> you now want to go back to the 8 bit YCbCr colour space
> with its narrower gamut.Not really. The problem occurs well before that — I notice the color shift while my video is still on Vegas’ timeline (RGB) and it remains there when I render my output into MPEG2.
Technically speaking, I wouldn’t call any color space (YUV or RGB) wider or narrower — they are just different and, even though every particular color value of one of them can MATHEMATICALLY be matched to the other, in fact, not all colors of one space can VISUALLY be matched in the other (with the limit of the same bit depth for both). This is why, I guess, the original RGB analogue video signal taken from a camcorder matrix is converted into YUV space using 12 or higher bpc. On the backwards conversion of DV YUV into RGB, there wouldn’t be much problem if an output RGB video was 12/14 bpc, while 8bpc RGB that we get in almost every RGB video application simply can’t reproduce all the original YUV colors VISUALLY adequate. If previous examples are not enough, try this native DV video: https://www.videoediting.ru/tmp/16_235_Sun.avi. And, finally, a simple math exercise (as discussed in a YUV->RGB thread on another forum):
Quote:
Imagine we would like to mix two YUV colors 200:200:200 and 170:170:170. As a result, we should get something in the middle: 185:185:185. Now let’s see how it works when converting YUV->RGB (using standard conversion equations):YUV 200 200 200 -> RGB 249 140 380
YUV 170 170 170 -> RGB 185 139 290
YUV 185 185 185 -> RGB 217 140 335Mixing two RGB colors:
(249+185)/2 = 217.0
(139+140)/2 = 139.5
(380+290)/2 = 335.0Is that mathematically correct? Yes!
Does any of the resulting RGB colors physically exist? No!
UnquoteThere’s also a book by Dan Margulis (if I remember his name correctly) on LAB color space (mainly, for Photoshop users). He explains the way a visual difference occurs when converting LAB->RGB->LAB (YUV color space is quite similar to LAB in that context).
> For a much more in depth understanding of this go to:
> https://compression.ru/download/articles/color_space/ch03.pdfThanks, but this one is more comprehensive, I guess:
https://www2.tek.com/cmsreplive/tirep/2211/2008.03.04.10.28.33_2211_EN.pdf
(pay special attention to the ‘Bandwidth Considerations’ and the ongoing chapters).> Given that each encoding pass removes information…
In this particular case, it doesn’t necessarily have to. In fact, there would be little or no loss at all if 8bpc YUV was converted into >14 bpc RGB. Surprisingly, I couldn’t find an application capable of doing that. To my regret.
> Do a few generations back and forth between YUV and RGB
> systems and you will soon see degradation in picture
> quality.Actually, one conversion is more than enough for that. Not for all kinds of source video, though.
> Sadly the 4:2:0 colour space with its limited chroma
> sampling is possibly the worst at exhibiting these
> problems.You’re absolutely right.
> It happens from the other end as well though because when
> creating graphics on 10 bit 4:4:4 broadcast systems we have
> to limit the colour palette for any graduations used…
> otherwise we see very bad banding artefacts when going into
> any 8 bit system, NLE or linear tape suite.Can’t these be limited by a higher bit depth of CG project? I work in After Effects and same banding problem occurs (especially noticeable on color gradients) only in a 8bpc project (10 bpc is probably not enough either?). Rising the project bit depth to 16 or even 32 bpc eliminates it usually, although slowdowns the work and renders. As regards sampling — does it really make sense to create grafics with 4:4:4 sampling scheme so far as the final output is anyway going to be 4:1:1 or 4:2:0, as I understand?
> To overcome these shortfalls stay 8 bit YUV or 10 bit YUV
> SDI the whole way…I’d love to, but that would mean I have to eliminate Vegas from my workflow. Which I frankly wouldn’t want — both in terms of costs and…well, you know, like you put it, old habits die hard. I would prefer finding a way to convert my native 8bpc DV video into 14 (or higher) bpc video BEFORE importing it into Vegas. That would solve the problem, I guess.
> Vegas 8.0 has implemented a 32 bit floating point setting
> which when working in 8 bit video can help with some of the > banding issues.The bit depth of Vegas’ project only matters for the quality of compositing you perform therein, i.e. synthetic video going out of such project will look much better indeed (likewise, the bit depth of After Effects project does what I wrote above). However, Vegas seems to work with the video data received from DV decoder, which is already 8 bpc RGB by that time, so it doesn’t really make sense to increase the bit depth of a project in that context.
> Wish I could suggest some other answers to your problem but
> I have not yet found any way of getting around what you
> describe, well not unless I use SDI. Wish I could!Thanks for that, neither do I see any workaround that could effectively deal with this issue. If Sony doesn’t address this in next Vegas generation, I think I’ll be moving to Edius.
-
Very simple answer:
https://www.glennchan.info/articles/vegas/color-correction/tutorial.htmUse the curves method described and clip illegal colors. This is appropriate for DVDs if you want consistency in picture between different DVD players and TVs. Some DVD players and TVs will clip illegal colors… others won’t. If you have no illegal colors, then you don’t worry about that.
—
What’s happening:
As far as color spaces go, you can think of them as having a volume… the bigger the color space, the more colors it can represent (*some of these colors may be nonsensical, e.g. anything calling for negative light).Anything 32-bit, for practical purposes, is infinitely large.
Next largest in volume is Y’CbCr (often mistakenly referred to as YUV), then studio RGB (RGB with 16-235 for legal levels @ 8-bit), then computer RGB (0-255).Because cameras record in Y’CbCr and many/most/all record some really illegal values (bad design/engineering IMO), then you get clipping occurring when you work in studio or computer RGB. (Studio RGB clips much less.) Also, if you have a cross dissolve, you can run into problems like the one you have if you don’t render both sides of the dissolve.
In Vegas, the DV codec decodes to studio RGB internally so clipping happens there… a 32-bit project won’t “unclip” that.
-
I’d also add that I normally don’t read this forum, so if anybody wants something specific answered, they should email me… glennchan [@t] gmail
-
I’m not sure if I have the same problem, but when I tried to render an MPEG-2 DVD Architect file PAL DV, the orange colours came out blue.
WTF ?????
I then rendered out a 3mbps WMV file and all was okay.Strange. Thank god I have three video editing programs, so if one doesn’t work like it should, I use another.
-
Excuse my bad English
Your issue is very common. Due to the color difference encoding math, Y Cb Cr (and all the YUV encoding processes) can encode color levels that are fare above the RGB color space. Almost all the camcorders record Y in the range 16-255. For ex.: If Y=255 and Cb and Cr=128, this is equivalent to RGB 255,255,255 but if Cr and or Cb are not 128, this codes for a color that has the max RGB luminance but is not white and can thus not be converted to RGB because it is a color above 255. Even if you limit Y to 235, a big lot of colors can be above 255.
For ex.: my Sony has shoot Rec.709 YCbCr=244, 63, 207 (bright red part if a lava flow) = RGB 365.63!!, 219.75, 126.08. I have very often G or B=290. This is a conversion to RGB assuming that my YUV is 16-255 for Y, but if I assume it is 16-235, then the resulting RGB values are scaled a lot higher due to the conversion from 16-235 to RGB 0-255. In Rec.709 YUV, the max. encodable values are about RGB 400, but only 2 colors can be above 255 at the same time. The max color encodable level for a pixel depends on the levels of the other colors of this pixel.
If your TV or Pro monitor is XVycc (=x.v.Color) compliant (case with Sony, Panasonic ans Philips), those out of RGB space levels are correctly displayed without any clipping when you connect your camcorder HDMI on the monitor. At the moment, the only solution to see the whole signal on your external YUV monitor when you grade is to use Edius with an Grass Valley output card or with the very good Blackmagis Intensity Pro 4K. Edius import your YUV clip as is, send the datas as is to the external monitor and also to the output YUV codec without clipping!
The managment of the data levels in the Adobe programs is catastrophic. Never import YUV because it is clipped at 16-235 at import time. In Edius or in Resolve, lower the gain to have all the color peaks under 255 (=1023 in Resolve) and export in 16 bit RGB (for ex. in TIF, Edius can only export 8bit Tif’s ). This creates a darker RGB file but with unclipeed colors. Import this in Adobe and export from Adobe in 16 bit PSD or TIFF (in fact, it’s only 15 bit because the Adobe range is 0-32767 and not 0-65534). Now, you can reimport the clip in Edius or Resovle and gain it back up to his original level. Be aware that by doing so, the black level is not correct in Adobe because it is between 0 an 16 instead of 0, but this has no importance if the purpose is to only apply effects. Be also aware that Resolve import YUV as is but clips above 255 when you render, wich is not the case with Edius.
I am waiting for your reaction.
Reply to this Discussion! Login or Sign Up