Frage von Predator:
Huhu, \u003cbr /\u003e\u003cbr /\u003e I have so far used CineForm to render my master files in order to pass on a.einen external encoder, but after I tried DNxHD, CineForm I want to take no more. DNxHD is a good piece of what artifacts and banding better terms. \u003cbr /\u003e\u003cbr /\u003e But I'm not sure I want in the Select your render settings or ITU RGB levels. The files look virtually identical, differing only slightly in Vegas histogram. I would like but as far as possible avoid unnecessary color conversions. \u003cbr /\u003e\u003cbr /\u003e My camera takes in YUV (; SonyFS100), the Vegas would have to convert to RGB, but as far as I know do it all NLEs. \u003cbr /\u003e That means that I would have to render out a.besten in the RGB and then type in my external encoder (; around in my case, Tmpgenc X264 Blurays
Antwort von Predator:
Just got the issue passed. \u003cbr /\u003e Frameserving without intermediate codec.
Antwort von dienstag_01:
\u003cdiv class=\
Antwort von Predator:
Yeah, that was until now, however, only bit color depth in Figure 8. \u003cbr /\u003e Did Vegas 11 tested (and made the update) with the latest version of DebugMode Frame Server and lo and behold: 32-bit video level to be sent a.Tmpgenc clean. \u003cbr /\u003e\u003cbr /\u003e RGB 24 has more than YUY as the output format of the frame server. This can be seen in the histogram in Tmpgenc synonymous. This is totally distorted by YUY issue. \u003cbr /\u003e\u003cbr /\u003e Vegas -> frame server directly into TMPGEnc -> Bluray X264 -> perfect quality!
Antwort von WoWu:
@ Predator \u003cbr /\u003e\u003cbr /\u003e Among the names: YUV is the analogous term for YCbCr. \u003cbr /\u003e You are so so in REC 709 (16/235). \u003cbr /\u003e ITU is simply an abbreviation for ITU-R 709th \u003cbr /\u003e Setting should not be RGB, but ITU. \u003cbr /\u003e\u003cbr /\u003e If you are looking for with the RGB color space umrechnest 1-255, you prolong you the color space, but win nozusaetzlichen colors but get dithering and should know what your goal is for this format, otherwise your content (eg for youtube & Co) on re- trimmed back 709th Here you amazed you the Highest Color space again and get Bandingprobleme. \u003cbr /\u003e\u003cbr /\u003e My tip: You come from 709 and it should stay and not go over RGB. (And let all this back-and-forth convert).
Antwort von Predator:
Yes, only the frame reserves necessary to go over RGB. \u003cbr /\u003e\u003cbr /\u003e I do not know if you know Vegas is a peculiarity of this program, in the preview monitor to display the full 0-255, instead of 16-235. The image we are working to drueberlegen thus shown to be weak and you have a level filter, so ne kind of LUT to. This may render it in front of the issue and remove nice in REC709. \u003cbr /\u003e\u003cbr /\u003e The problem is that the frame's image server outputs exactly what it looks like in the preview. Say, if I have a 709 then open my image in TMPGenc, \u200b\u200bit looks dull, it is erroneously decoded as 0-255. \u003cbr /\u003e\u003cbr /\u003e So you have to spend 0-255 (with active filter level). Probably better and get updated very often more expensive encoder, which can be said explicitly: source is 16-235, but TMPGenc can not do that. \u003cbr /\u003e\u003cbr /\u003e The
Antwort von Belize:
\u003cspan style=\
Antwort von WoWu:
But even if the preview monitor RGB display, which is of course completely normal, then he has still only values \u200b\u200bof 709th \u003cbr /\u003e The preview will be represented in only 709 of RGB, because he changed not even the table of values. And if there noWerte of above 235, are shown noWerte. \u003cbr /\u003e Only if you hergeht and convert to RGB 709, the color space is indeed changed. \u003cdiv class=\
Antwort von dienstag_01:
@ WoWu \u003cbr /\u003e If your system is probably no difference between the preview on the computer monitor (eg the Color Correction) and your external preview monitor?
Antwort von WoWu:
No, both are 709, if we work for TV and when we work with LTU for CINE. \u003cbr /\u003e And this correlates with the C1 synonymous a.Fully engage video monitors exits, which in the case CINE projector slightly different, because the white point is shifted slightly and the drift of the color synonymous sites. \u003cbr /\u003e But of course we work sloppily around not synonymous. Once workflows are set so that they agree.
Antwort von dienstag_01:
\u003cdiv class=\
Antwort von Predator:
I think you understand the Wowu wrong. My monitor and my plasma TV are calibrated. Since nothing a.Fully engage notches food is twisted. \u003cbr /\u003e\u003cbr /\u003e Click here so that Sigale be misinterpreted. \u003cbr /\u003e\u003cbr /\u003e Look: 100% error-free workflow in Vegas was so far: \u003cbr /\u003e Import files. Files are displayed as 0-255 despite 16-2xx (235 + Super Whites) are. This is completely normal in Vegas (Thanks for the tip with the external preview). (For example, is represented equally in Premiere 16-235, big blooms better because simpler.) \u003cbr /\u003e\u003cbr /\u003e Now place over it a LUT that displays the image as if one would look at it in the 16-room size 235 or use the hint with the external preview that can be set to REC709. \u003cbr /\u003e\u003cbr /\u003e In the end, after cutting and color correction, removed the LUT nan and again renders as neCineform AVIals master. This works correctly. \u003cbr /\u003e\u003cbr /\u003e Because the external encoder to decode AVI 16-235. \u003cbr /\u003e\u003cbr /\u003e But when the external encoder frame server decodes the signal unfortunately 0-255, so just like the Vegas preview window. In the final rendering compresses the external encoder is then combined to 16-235. A DVD or BD will look exactly as intended. \u003cbr /\u003e\u003cbr /\u003e If I would send 16-235 a.Fully engage encoder, it would me the 32-215 or so to squeeze ... the result will look accordingly ... \u003cbr /\u003e\u003cbr /\u003e There is only one interpretation error, forcing me once of the 16-235 at 0-255 and back again. But that does absolutely nothing out. The Cineform-way looks shclechter, although it remains all the time in 16-235
 |
Antwort von WoWu:
\u003cdiv class=\
Antwort von WoWu:
\u003cdiv class=\
Antwort von dienstag_01:
\u003cdiv class=\
Antwort von Predator:
\u003cdiv class=\
Antwort von WoWu:
\u003cdiv class=\
Antwort von dienstag_01:
\u003cdiv class=\
Antwort von WoWu:
\u003cdiv class=\not. \u003cbr /\u003e\u003cbr /\u003e But it's really not a problem and requires noBehandlung \u003cbr /\u003e\u003cbr /\u003e The workflow Vegas -> CineForm -> X264 from TMPGenc \u003cbr /\u003e\u003cbr /\u003e looks worse (there are minimal banding artifacts and added) as \u003cbr /\u003e\u003cbr /\u003e Vegas -> frame server -> TMPGenc from X264 (which is not distinguishable from the original material) \u003c/div\u003e\u003cbr /\u003e\u003cbr /\u003e But you write it yourself: \u003cbr /\u003e\u003cdiv class=\
Antwort von WoWu:
\u003cdiv class=\
Antwort von dienstag_01:
I do not think that this is drifting apart. \u003cbr /\u003e You have to understand that we are working on a computer monitor (but not for the computer monitor). So you have to do something with the ad, otherwise the blind flight.
Antwort von Predator:
\u003cdiv class=\would have to the the encoder can only say: Stop, that's REC709 material! It is not. \u003cbr /\u003e\u003cbr /\u003e But it's really not a problem and requires noBehandlung \u003cbr /\u003e\u003cbr /\u003e The workflow Vegas -> CineForm -> X264 from TMPGenc \u003cbr /\u003e\u003cbr /\u003e looks worse (there are minimal banding artifacts and added) as \u003cbr /\u003e\u003cbr /\u003e Vegas -> frame server -> TMPGenc from X264 (which is not distinguishable from the original material) \u003c/div\u003e\u003cbr /\u003e\u003cbr /\u003e But you write it yourself: \u003cbr /\u003e\u003cdiv class=\completely different topics. At the entrance we went to the post DNxHD codec. Since I got noHilfe, I've discovered and the possibility of weitergegoogelt Frameservens what I wrote in post second Since the incoming mail is totally irrelevant. The only refers to DNxHD and as ITU is certainly the right choice, as you write! Thank you! :) \u003cbr /\u003e\u003cbr /\u003e I've decided against synonymous DNxHD, Weil comes at irregular intervals to render the image errors. A frame is torn, as if it would be interlaced. Zeimlich bitter property for a broadcast codec ... \u003cbr /\u003e\u003cbr /\u003e I'm here now in the business degree tries the server frame with premiere. Here he works probably correct. TMPEGenc shows exactly the same image as the Premiere preview window and this is indeed 16-235. So with premiere
|
Antwort von WoWu:
Bit confused that's now :-)) \u003cbr /\u003e But why do you let any "interpretation of 255" on something?
Antwort von WoWu:
\u003cdiv class=\
Antwort von Predator:
\u003cdiv class=\
Antwort von WoWu:
But you come of the FS100 but in H264. \u003cbr /\u003e Can Vegas because no H.264? \u003cbr /\u003e Somehow I can not believe it, because the synonymous convert to DNxHD is junk, because the codec uses a 20-year-old DCT, whereas in the AVC variants a truly impressive new edition applies. \u003cbr /\u003e In this respect, the whole workflow is not optimal. \u003cbr /\u003e\u003cbr /\u003e (Sorry, I just noticed ... is not more DNxHD) \u003cdiv class=\
Antwort von Predator:
\u003cdiv class=\
Antwort von WoWu:
But unnecessarily. \u003cbr /\u003e MPEG has raised the profile such that in the wost case, the maximum bit rate specified by the request is not clear. And you no longer work as the maximum amount of macro block with the disposal of related tools can. \u003cbr /\u003e Needed such an extension would only, if within the time frame would be enlarged to macroblock amount. (Sometimes used for slow motion, or more frames as provided in the standard).
Antwort von Belize:
In Vegas Pro SonyAVC give for the BD-output data rates up to 26 Mbit / s. If it noBD be, or not necessarily be avoided in DVD Architect Neurendern the need may well be taken MainConcept AVC. In version 11, the program has been improved significantly MC-encoder again (and he lets virtually any data on rates, but this is only a very limited extent in AVC of significance). When you author runs over TMPEG, so could possibly be an alternative MainConcept AVC. \u003cbr /\u003e Consider when SonyAVC also that it is the information about the average data rate, not the MaxUnd for safety, I would (whether MC or Sony AVC), both the GPU-processing off as synonymous GPU rendering support, if It's about quality
