Frage von fleshmann:
This is my first post, so to have a first viele grüße ..
This forum had often the key stock tip, perhaps even synonymous with other topics ..
I have recently acquired a HC1E. because the time to experiment with my current project is rather tight, I'm playing the material from a DV to cut as smooth as to be able to (target medium is DVD, so the quality is sufficient).
Since HDV indeed has almost twice the size, I have some additional scenes captured as HDV, the quasi retrospectively without sacrificing anything to be able to zoom in ..
So I then begun to experiment yet:
With the 1.5.1 update on Appro can the HDV footage without problems add to the project. By the scaling factor of 53.4 pendant is quite congruent with the DV. Only a minimal but unequally disturbing Farb-/Helligkeitsabweichung is festzusetellen upon closer contemplation. Jerky motion could be eradicated by reversed-field dominance, however, APP seems to merge the fields in the HDV clip anyway - so I'm forced to erxportieren the entire progressive sequence, otherwise synonymous here the difference is visible ..
So what do I must do with the HDV clips to use it fully in my DV project to be?
I realize that HDV and DV material is generally not compatible ..
And again, many thanks in advance greetings
Antwort von Wiro:
Hello,
have just completed a few days ago a project in which exactly were the same constraints apply. HC1 footage was a 16x9-DVD create, with the footage contained, among other things, an interview, in which the person interviewed was a little too far away (too small) in the Picture. The person should look more closely in the film (to be zoomed in).
My approach (Appro 1.5.1):
As SD widescreen directly captured from the HC1, the said interview additionally as HDV footage.
In (SD) Project was then the (HD included) interview, in my case, brought to 77% size and movement to move something to get bigger head. Then the HDV footage, the field order reversed - that's it. That progressively Appro expects the field order, I can not confirm - everything went without problems, final synonymous on the DVD. Perhaps you are deluding yourself there.
That with the marginal Farb-/Helligkeitsabweichung synonymous, I have found. It seems simply to be due to that the HC1 with HD output and SD output reacts differently. The issued SD picture is somewhat stronger in the colors, I mean. But one must look very carefully. I have therefore increased in the interview scenes, the saturation of an idea to fit the skin color again.
Gruss Wiro
Antwort von Axel:
An interesting thread for someone like me, still in theory dealing with HDV. You write well and understand, so can you tell me to determine whether and why the field order is reversed in HDV. HBR and what it sets for a project in which both occur. If Wiro would not be an old hand, I would have said, let the stupid jokes that can not go at all.
Antwort von Wiro:
let the stupid jokes that can not even go Hello,
Galileo Galilei, as already reported to have said: "And yet it moves!"
Said Well, he has probably not, otherwise they would have chopped off his carrot. But he has thought of it. . .
;-)))
Gruss Wiro
Antwort von wolfgang:
It was then turned over to the HDV footage, the field order - done The synonymous surprised me a little. HDV has indeed, by definition, UFF, LFF DV yes.
The NLE has indeed before Rausrendern footage correctly interpret both species, so ought to for the respective source material indeed be set correct field sequence in the clip attributes.
A manual shaking changeover may be needed - but I would have expected only if the NLE would not recognize for some reason the correct field sequence of the respective source material.
Or is it that the NLE the correct field sequence of the material before the rendering interpreted correctly, regardless of what we now cease?
Antwort von Wiro:
Hmmm - I see it this way:
After the Project in DV is lower field footage with and I insert an upper half image, an algorithm must ensure that each time previously recorded lines played in the correct temporal order (to be rendered). But, it takes really MUs only lines 1 with 2, replace 3 with 4, etc. - or the entire grid lines in the 1st Field to the line and push down on the 2nd Field 1 row. That would fit properly. How this is solved in practice, I leave that to the engineers. We are only users of the tool.
Dont talk about is - just do it and report.
My movies is now including interviews were projected onto a large screen and worked just fine. On a tube well. That was the goal of my work. The questioner may help a little.
Gruss Wiro
Antwort von fleshmann:
yes, and it helps confirm ..
works in principle, the whole up to the above restrictions remarkably smoothly. since the Case with me but it bothers the half-frames, I have made on the basis of a short clips or even a comparison.
So, will definitely be the HBR of the HDV footage vice versa, otherwise the wrong order at a jerk to be expected in the movements occur. This is indeed synonymous s.sich an indication that APP is actually two fields. However, my impression is that export to a DV interlaced HDV progressive passages are shown. This becomes clear when I spend the entire sequence-progressive, because now no differences between HDV - DV material and more visible, at least in terms of image motion.
The subsequent color / brightness correction is, of course Frickel, but nothing's just nothing ..
Well, so be it - I assume that the camera-DV Converter shall be responsible for the HC1. I would not synonymous wonders if Sonyan has built in this space intentionally slight differences in picture "to keep the format as incompatible with the DV and so did not receive market unnecessarily s.Leben to ..
Thank schonmal and many greetings
Antwort von alexosnasos:
Well, so be it - I assume that the camera-DV Converter shall be responsible for the HC1. I would not synonymous wonders if Sonyan has built in this space intentionally slight differences in picture "to keep the format as incompatible with the DV and so did not receive market unnecessarily s.Leben to ..
Thank schonmal and many greetings SD and HD (HDV is synonymous HD) have completely different color spaces. The camera must do so otherwise it would be in addition to the standard. The editing software should be taken into account, however. Premiere I know this is not EDIUS Pro 4 and AvidExpress tuen the car.
Antwort von TheBubble:
Unfortunately you can not just swap straight and all the odd lines to change the field order to. This is because the lines are different in addition to the temporal offset synonymous in their spatial position.
To change the field order, you must complete for each field until the missing lines. These new lines will yield the Field s.der new position, the old "original" lines can now be discarded.
In practice, however, it is not always done so synonymous, where appropriate, must / should be an implementation of a kind "Deflicker" Applying a filter.
Alternatively, one could dispense with the wrong field order swapping and synonymous to a building by simply discarding of a field or a deinterlacing a "progressive" frame. So there are several ways to deal with the problem.
With color spaces, this has nothing to do.
Antwort von wolfgang:
After the Project in DV is lower field footage with and I insert an upper half image, an algorithm must ensure that each time previously recorded lines played in the correct temporal order (to be rendered).
Just as it is. I only wonder what is the fact that in this "mixed processing" apparently must manually adjust the properties of the HDV2 source material. Ok, the detection ability is right at the stop field sequence is always limited - in different NLEs.
Unfortunately you can not just swap straight and all the odd lines to change the field order to. This is because the lines are different in addition to the temporal offset synonymous in their spatial position.
However correct this is, is certainly aware of Willie. The NLE does indeed synonymous only the right properties of the source material to know - and then she has to carry out independently the veracity calculations and so on.
With color spaces, this has nothing to do. However, it has - at least in the context of this thread. And this is because the mixing of DV avi and HDV1/HDV2 synonymous mixing of material in different color spaces is. Just as the NLE really needs to recognize that the material is available in different Halbildfolge must recognize the NLE synonymous, that the material is available in different color spaces. And in consequence, the NLE has taken into account correctly the color spaces, otherwise you have (especially in the red) color space shifts.
Antwort von alexosnasos:
And then she has to carry out independently the veracity calculations and so on. What I wanted with out: There is not always a "right" way, different software can behave in different ways.
I was referring only to the swapping of interlaced fields, the colorspace plays here, or to apply a part that does not matter.
Antwort von TheBubble:
The message is of me, I forgot the sign.
I was referring only to the swapping of interlaced fields, the colorspace plays here, or to apply a part that does not matter. Conversion, or the mixing may say that does not use any video format, the full RGB range that can be a PC and can occur any slight differences.
Antwort von wolfgang:
What I wanted with out: There is not always a "right" way, different software can behave in different ways.
I was referring only to the swapping of interlaced fields, the colorspace plays here, or to apply a part that does not matter. Firstly: yes, various NLEs occasionally interpret material from various sources wrong - Vegas had some problems sometimes with Canopus material. In this case we speak of "normal" HDV2 material. Why is there the field sequence is not recognized - which is indeed a problem with mpegs soo not like avis - to know only the gods (and the developers ...).
Troublesome is the thing in any case - just imagine a bigger project with a couple of 100 clips, where you have to manually change the field sequence in each clip? Or do I understand this wrong?
In the second place in the context of this thread, the color space is a serious issue. One can only hope that the mixture of SD and HDV material here does not cause any problems. The field sequence can be so obviously still manually adjust, color spaces hardly likely.
Antwort von TheBubble:
Firstly: yes, various NLEs occasionally incorrectly interpreted material from various sources Unfortunately it's not just about recognizing the Halbbildanordnung of the film, when the order was once synonymous correctly identified, it must be reversed, however, for the output file, you can accomplish this with different inversion procedures.
Troublesome is the thing in any case - just imagine a bigger project with a couple of 100 clips, where you have to manually change the field sequence in each clip?
As hard as it might not be, because you usually correct order should be embedded in the file, and only if this information is missing or incorrect must be things along.
Apart from that, I hope that the use of half-frames at some point come to an end. For the early days of television in conjunction with CRTs, it made sense, in today's LCD or plasma displays IMO no more.
One can only hope that the mixture of SD and HDV material here does not cause any problems. The field sequence can be so obviously still manually adjust, color spaces hardly likely. I Neh, do you mean space with the subset of the RGB colors, for example, by the tv (PAL) will be used and which is smaller in scope than the example of PC graphics cards used in the field?
Antwort von Stephan Kexel:
I Neh, do you mean space with the subset of the RGB colors, for example, by the tv (PAL) will be used and which is smaller in scope than the example of PC graphics cards used in the field? The brightness variations have something to do with different sampling rates to luma and chroma. SD has since other frequencies than HD. When editing software did not handle it comes to brightness fluctuations when SD and HD (synonymous HDV) mixed on a timeline. This has nothing to do with RGB or YUV to. Video is always YUV.
A brief statement on the ITU 709 (HD) and 601 (SD) http://www.pcmag.com/encyclopedia_term/0,2542,t=ITU-R+BT601&i=45512,00.asp
Antwort von TheBubble:
The brightness variations have something to do with different sampling rates to luma and chroma.
With the sampling rates has nothing to do, in the YUV / YCrCb color model (and other similar color models), only the luminance channel carries the brightness information. Small differences in the conversion RGB-> YCrCb-> RGB can only by rounding errors, and different interpolation / approximation of the missing, subsampled as in terms of brightness, color difference values arise. The only difference is usually only Bsteh nor the fact that MPEG-2, the chroma values slightly s.anderen positions scans, as is the case for other 4:2:2 formats. Without that have investigated right now, but I'm assuming it can be neglected.
Video is always YUV.
Can not say so flat that a codec used by the transmission method, or dependent thing. Software is on the "secure" page, if RGB data is processed and leaves the conversion as the particular codec or other data source.
To get the bow back to relating to: brightness and color differences can really only due to different "allowed" color (or in the YUV or YCrCb color space are brightness and chroma). Whether this is the case I could, if interested, to find out. On the other hand, there may be synonymous differences, if the source material of different cameras used and no calibration was performed.
If, regardless of which one effect can be observed, the explanation is not so, then I'd be interested s.ein some sample images.
Antwort von wolfgang:
A brief statement on the ITU 709 (HD) and 601 (SD) http://www.pcmag.com/encyclopedia_term/0,2542,t=ITU-R+BT601&i=45512,00.asp Stephan has written to you the essential response - namely, that in 709 HDV, SD is available in 601 color space. Therefore, we can mix HDV, SD clips in a Project, then the NLE take this into account when encoding the material.
The rest is in my view, quite by s.Kern. I see it the way Wiro said: should have to worry about the developer - has to work the thing.
And again, I
will not have to manually adjust the field sequence in NLE None. This will simply be correctly identified and processed, as is the question of whether the clip is now available in 709 or 601. To sowas I will not even have to worry - but I need to know that there are these things.
Antwort von Stephan Kexel:
The brightness variations have something to do with different sampling rates to luma and chroma.
With the sampling rates has nothing to do, in the YUV / YCrCb color model (and other similar color models), only the luminance channel carries the brightness information. Small differences in the conversion RGB-> YCrCb-> RGB can only by rounding errors, and different interpolation / approximation of the missing, subsampled as in terms of brightness, color difference values arise. The only difference is usually only Bsteh nor the fact that MPEG-2, the chroma values slightly s.anderen positions scans, as is the case for other 4:2:2 formats. Without that have investigated right now, but I'm assuming it can be neglected.
You do not contradict themselves?
Video is always YUV.
Can not say so flat that a codec used by the transmission method, or dependent thing. Software is on the "secure" page, if RGB data is processed and leaves the conversion as the particular codec or other data source.
I mentioned talking about video and not on files. And as you can tell the whole flat! (There are special RGB camera's, I go here, do not assume that the jemenad use here.)
Software is on the "secure" page, if RGB data is processed and leaves the conversion as the particular codec or other data source.
About this issue has been around for years, the policy discussion which you should read the first time before making the above statement.
Antwort von TheBubble:
I mentioned talking about video and not on files. And as you can tell the whole flat! (There are special RGB camera's, I go here, do not assume that the jemenad use here.)
Not upset. All television is RGB, which is taken of the cameras, it is synonymous. Even when there is only internal YUV analog video. No matter how the signal is internal processes, interesting is that what comes back. And it came to editing software: This nunmal not work with analog YUV signals, but with files.
Antwort von stantorley:
I mentioned talking about video and not on files. And as you can tell the whole flat! (There are special RGB camera's, I go here, do not assume that the jemenad use here.)
Not upset. All television is RGB, which is taken of the cameras, it is synonymous. Even when there is only internal YUV analog video. No matter how the signal is internal processes, interesting is that what comes back. And it came to editing software: This nunmal not work with analog YUV signals, but with files. Wow, what wisdom ne. Since I now prefer to write anything.
Antwort von wolfgang:
And it came to editing software: This nunmal not work with analog YUV signals, but with files. I'm here now no expert, but a user? Gabs but not very much debate about whether the effects are calculated in RGB or YUV? That probably made some difference. And the files must surely be calculated in color spaces - I would suggest times.
;)
Antwort von TheBubble:
I'm here now no expert, but a user? Gabs but not very much debate about whether the effects are calculated in RGB or YUV? That's why I said yes synonymous
Software is on the "secure" page, if RGB data is processed and leaves the conversion as the particular codec or other data source.
It is true that Programs that wish to apply effects with the least possible computational effort (to be finalized very quickly) to do so in part without prior reverse conversion of colors to RGB (via the codec) to waive the computational effort.
I believe that we both just talk past each other a little. The whole issue is unfortunately too large to describe it in a few contributions in full and in detail enough.
Antwort von wolfgang:
Nope, the thing is not soo complex - as long as one does not lose itself in the technical details. The important thing is that the spaces must be properly taken into account well. Truism, but relevant if you have source material, which is present in different color spaces.
And for the practitioners among us who does not believe that time is to consciously make the output of HDV material with a high proportion of red to each ITU 709 (HD) and 601 (SD) - and then compare. The difference can be seen, especially in red
Antwort von TheBubble:
Nope, the thing is not soo complex - as long as one does not lose itself in the technical details. I am interested but for technical details and theory:)
Antwort von wolfgang:
This is so you are free - I think that is synonymous for exciting, synonymous like to test. But that does not mean that we should look pragmatically synonymous views on relèvent things - as long as you want to finish synonymous video productions.
The Diskusson the mixing of SD with HDV footage I do not consider unspannende, precisely because it identified the point, there needs to be noted. In Vegas, as I've watched a short time at least, the question of the fields. Drawing a mixture of SD and HDV material into the timeline, then Vegas, interprets the field sequence for both kinds of material properly - synonymous to a DV-avi Project. So I expect the synonymous of a yet more expensive NLE.
Antwort von fleshmann:
even,
I think it is a rather dubious synonymous zumutung need such a clear format to make adjustments of hand. it is synonymous mentioned that reverse premiere (play at least 1.51) at the rear of the clip again, the manual requires the field dominance. I is not conceivable situation in which I like an inverted "need" sequence would be ..
just me here is the problem of different color spaces have become clear, however, offer me synonymous here is my preferred NLE really no controls for alignment. My understanding is that such a possible yes synonymous (even the capture of the materials held?), Here are the possibilities for non-standard settings, being evil is limited ..
a shame but a lot of greetings
