Newsmeldung von slashCAM:Canon 5D MarkII with limited dynamic range? Of rudi - 20 Jan 2009 10:51:00 Since a few days to heat up the minds of the network that the clips of the Canon 5D MarkII very quickly become the clipping in the highlights and shadows tend. We had already suspected, but in the linked blog is now proven that it is once more to the problem of the conversion of YUV to RGB act. Here the YUV values 16th .. 235 "to the RGB scale 0 .. 255 displayed. YUV values under 16 and over 235 are covered under the table. Holger Scheel had
dies seinerzeit schon bei DV -Codecs untersucht and beschriebenAlso geht jetzt mal wieder die Suche nach einem Codec los, der YUV nativ s.das Editing program weiterreicht, bzw. beim Umrechnen nach RGB den Wertebereich nicht künstlich aufbläst. PC-Anwender dürften aufgrund der breiten Choice hier schnell fündig werden, Apple User, die ja gerne of solchen technischen Feinheiten nichts wissen wollen, sollten dagegen mal näher hinschauen, ob z.B bei der Umwandlung nach ProRes so was irgendwo einstellbar ist. Profi-Colorist Stu Mashwitz seems in any case dies seinerzeit schon bei DV -Codecs untersucht and beschriebenAlso geht jetzt mal wieder die Suche nach einem Codec los, der YUV nativ s.das Editing program weiterreicht, bzw. beim Umrechnen nach RGB den Wertebereich nicht künstlich aufbläst. PC-Anwender dürften aufgrund der breiten Choice hier schnell fündig werden, Apple User, die ja gerne of solchen technischen Feinheiten nichts wissen wollen, sollten dagegen mal näher hinschauen, ob z.B bei der Umwandlung nach ProRes so was irgendwo einstellbar ist. Profi-Colorist Stu Mashwitz
This is an auto-generated entry
Here is the link to the news with links and images on the pages Slashcam Magazine
Antwort von joey23:
Why should Apple users of such "niceties" not want to know? Strange statement.
Antwort von Axel:
What is meant is that the relaxed ProRes workflow with many FCPler makes too carelessly. On the rescue of the values over 235 will never be out here anyway, there was "Wolfang Video Forum provided us. But
Masch's joke
has indeed found, with Color, which is to FCStudio is one of them.
Antwort von MarcBallhaus:
The data used in the Cam YUV 4:2:0 and therefore not in RGB. Somehow I do not quite understand where the problem lie? For my words more in the settings of the cam, because you have the contrast to -4, not to 0 for a neutral outcome to obtain.
MB
Antwort von Axel:
Somehow I do not quite understand where the problem lie? Garnicht It is perceived as a problem, and it affects all video, not just the Mark II machine wit, the creator of Magic Bullet Suite and chief of the securities firm
Orphanage (Sin City) is a fanatic, but how to get involved in the link s.dem Previous Picture-and-after look, it is worth with the matter to be addressed.
YUV to RGB, the scaling of the values (YUV) 16 - 235, with the original dynamics of information falls under the table. To be avoided in Final Cut Pro, as Masch writes joke, just the Apple 10-bit uncompressed codec and render settings
When rendering of shooting always use the highest quality - in the original
rendering in high precision YUV, which admittedly is only when there is a YUV --
codec.
Antwort von Marco:
The problem lies in the
de coding. So in my experience exactly what Rudi writes. On Windows systems are cut codecs that after decoding the signal necessarily clip, but rather rare. Almost all the kits correctly or can optionally switch. On my Mac was the most even less understandable. Perhaps I had only too often synonymous pitch (the codec offering) or I brauch noch 'ne while.
Marco
Antwort von deti:
In the Instructions for Camera is quite clear in it:
Recording and Image Quality
...
The movie will be recorded in the sRGB color space equivalent optimized for movies.
...
This is synonymous implicitly states that the full 8-bit space is exploited, right?
I understand all the excitement, not of people who should know better.
Deti
Antwort von MacPro:
In the Instructions for Camera is quite clear in it:
Recording and Image Quality
...
The movie will be recorded in the sRGB color space equivalent optimized for movies.
...
This is synonymous implicitly states that the full 8-bit space is exploited, right?
I understand all the excitement, not of people who should know better.
Deti What is it "very clear"? This means only the transfer function is used (Primärvalenzen, "Gamma", white point), but nothing about the type of coding (vs. YCbCr. RGB, full scale vs. Video scale)
Antwort von deti:
What is it "very clear"? This means only the transfer function is used (Primärvalenzen, "Gamma", white point), but nothing about the type of coding (vs. YCbCr. RGB, full scale vs. Video scale) So if I understand correctly, defines only ITU-R Recommendation BT.709 finds that the so-called "studio-swing levels" are used. sRGB allowed out of the 8-bit and not familiar with this rule. Canon would have written that the Camera is s.ITU-R BT.709 holds, then I would like to thank values beyond the interval between 16 and 235 synonymous greatly surprised.
Deti
Antwort von Marco:
The real problem is apparently "just" Quicktime, or the way in which up to now in Quicktime H.264 is decoded. Just the news in the behavior described with Quicktime H.264 files, there is already some years ago.
Marco
Antwort von WoWu:
QU cuts as too right, because the values in areas outside of the xvYCC color space Y'CbCr nothing is lost.
Also differs Y'CbCr of RGB synonymous nor the fact that he has not built up of 16-135, and thus similar to RGB, but of the middle to the sides. Thus, values below 16 instead of black and dark green of everything above 235 "pink pig". In this respect, Apple has been right since.
Who values outside the 16-235 want to use, should make xvYCC.
Here is a link to the Mark II and QT
http://www.film-tv-video.de/newsdetail.html?&uid=37689&no_cache=1
Antwort von Marco:
Oh no, not again ...
Marco
Antwort von WoWu:
Well, facts are just facts, synonymous if they are ignored.
The above article speaks a clear language ... only that there is no xvYCC 2002 still existed. ... Today, however.
Antwort von Marco:
Yes. The fact is that, in principle, actually "just" Quicktime needs to be prevented, the video in the hands to get. Easier said than done, but it is, for example, by Frameserving. Then there's no more problems, or if you have what should remain, they can be easily corrected. There's no synonymous dark green instead of black or pink instead of white.
Marco
Antwort von MacPro:
Also differs Y'CbCr of RGB synonymous nor the fact that he has not built up of 16-135, and thus similar to RGB, but of the middle to the sides This is true but only for Cb and Cr!
This is about is the super white and super black, and Y 'is quite normal of 0 to 1 (or 0-255) structure.
Thus, values below 16 instead of black and dark green of everything above 235 "pink pig". In this respect, Apple has been right since.
Who values outside the 16-235 want to use, should make xvYCC. We are not talking about advanced color, which will be criticized, but to the obvious impossibility of the complete Lumasignal read it (what with all other QuickTime codecs, but allows Y'CbCr (!), Provided that the native application (Y'CbCr) data of QT and QT does not require the conversion to RGB leaves).
Obviously, however, appear h264 in the QuickTime architecture but to the outside as RGB codec in appearance, and that is precisely the problem at stake.
Here is a link to the Mark II and QT
http://www.film-tv-video.de/newsdetail.html?&uid=37689&no_cache=1 They have the reason behind it but not really understood synonymous.
Antwort von WoWu:
They have the reason behind it but not really understood synonymous. ... then hab'ich however synonymous not understood.
It is simply a matter that a camera produces signals, which, although they Y'CbCr color works, this does not respect!
Any camera could be given in the conversion of R'G'B after Y'CbCr theoretically use the whole field.
Take a good camera but not because of the range of values in the color solid is defined.
This then agrees synonymous Color Bars with the following values to match.
Votes Color Bars and camera signal does not agree that it is either bad or defective.
The color in these areas will be well as "illegal color" means NLEs and if they are transferred, they should be marked, or they should be cut, as the latest in monitors, which transmit synonymous xvYCC, these signals are not visible anyway, if not xvYCC is available. Even TV channels broadcast such signals will be cut.
In this respect, it is right and wanted, that this happens in NLEs.
As already mentioned, the space in which these values are transferred to another space reserved for the more then synonymous color aufweist, because there is a difference whether I use a color just spreading (as in this case), or whether I am actually more color is transported.
So where is the problem if the values of either the Camera ... or, if it can not, of NLE, the required color is observed?
What makes it a point to values that are neither with the color bars (and thus with the correct color space) or with a continuous Verarbeitungsweg error-free transfer to and are still in areas that are already of a different color are occupied?
Just because they are on your own monitor, which may not properly limited, slightly more colorful and saturated look like?
So then hab'ich as colleagues in the article synonymous not understood anything.
Antwort von PowerMac:
For digital cinema formats could bring something in TV reports certainly do not.
Antwort von Marco:
I have just a few 5D H.264 clips edited and compared.
I leave for decoding the way over to Quicktime, s.vielen bodies are black (with RGB 0) and white (with RGB 255) Clipped.
Am I but a way by AVISynth and VDubMode and then export the signal to a format in which each system, the full scale values can easily manage (in this case it was Newtek HQ 422), then show the clips no more clipping or s . the places where the prior information by simply clipping was cut off, is now synonymous in the video re-identifiable information.
Although the 5D a few files that I have, not really good for such demonstration purposes. The information "restore" it is easier to Waveformdarstellung than the real image visible. But nevertheless, it shows that with a Quicktime Decoding simply cut off existing information, to include decoding path but remain intact.
What is the norm after in terms of specific applications is right or wrong may be, is one thing. But the fact is that it's not the Camera is the unterschlägt information that this information but reproducible remain Quicktime if the signal does not get to act and that even the values in the border areas for many applications and used by quite synonymous valuable. As mentioned already written: color in the area 0-15 and 236-255, there is not.
It is my opinion, even in relation to a simple broadcast-use, synonymous not good to say, Quicktime is already doing right, because the borderline area in one (I call it now so) Broadcast standard signal "eh have lost nothing.
The latter may indeed be correct. But why do I still long of a decoder is not simply the signal including the information contained therein is off!
The elegant and in my opinion, more professional way to "broadcast signal" is still, to me at first the original signal with all its facets is so, how it was recorded. I decide then for example by means of a targeted color correction, as the limits in the normal range may be because it is then - and only then - radical synonymous without clipping.
Even if I have a complete s.Ende Project simply a broadcast drüberfegen leave, but to me black and white values by means of a curve in the area on the RGB 15 and under 236 counts, I'm serving better quality than with a clippenden Decoding.
As long as I had the choice, I leave myself in any case of a decoder in the first step the dynamics of the signal in such a prune. Dynamics is a valuable good and it is about 13 percent of them.
They should always bear in mind that the world beyond the traditional broadcasting is huge. Therefore, a CameraLink synonymous not as good or bad, only because it's the one way or the handles. The question is rather, for what purpose a particular camera ever since has been developed.
Is it good that myself so much cheap cameras Dynamics and left myself to decide whether the final product of a broadcast-standard or it can be optimized for other applications will be.
Marco
Antwort von MacPro:
So again slowly:
Of colors is nowhere mentioned. it is only and alone at the Lumasignal.
It is true that s.der assign value 16 Y 'value 0 = RGB value 235, and Y' = RGB value 255 is not negotiable. Everything that is ever illegal, per se, because outside of the Displayable.
Now it is a fact that (many) cameras synonymous Lumasignale larger 235 and to record them in the post to have access, is a significant advantage if you have something drawing from a übersstrahltem area herauskitzeln want.
Fact is, the Canon is super white on. One can argue about whether the wise or unwise been Canon of whether it is better not just the image signal in the Camera already mapped to 16-235 would be held there on the field of Super White extended. But would a loss s.Tonwerten to follow. ITU REC 709 prohibits the exploitation of the head room for video data are not synonymous, on the contrary: only Level 0 and 255 have been reserved for timing references. The rest is for "video data" clearly foreseen.
The fact that this headroom per se is not displayed, is clearly and correctly, it's only a matter of this Tonwertreserve in the post to be able to save it.
Edit: Marco was faster ;-)
Antwort von WoWu:
I see the argument perfectly and at a closing date if necessary, the difficulties are not synonymous, but then any standard conversion leads to incorrect results because the signal they are not rated, but by default colorspace expect. Thus it is wrong to spread at the time of entry after R'GB lead.
Yes now I know not whether the Canon Color Bars a provenance, but should (and I think we have agreed), always the reference.
Did they have a FB and was saying in relation to the signal?
Mir is the only issue, if someone wants to use the area, why not the same in xvYCC, because that would be such a signal, and then even defined and correctly converted.
What, then, speaks for such a (pseudo) Y'CbCr?
Antwort von MacPro:
Mir is the only issue, if someone wants to use the area, why not the same in xvYCC, because that would be such a signal, and then even defined and correctly converted.
What, then, speaks for such a (pseudo) Y'CbCr? Ne Quantity:
1. xvYCC is simply not implemented in the Canon!
2. What program on the Mac can deal with xvYCC?
3. xvYCC does not solve the problem, or is the answer to a question that was never raised: the expanded xvYCC color space, ie the Tonwertabstände remain in Comparison to conventional Y'CbCr same. not the xvYCC expanded Luma. More often, as an extreme saturated colors (ie outside of sRGB is), it was just with a übergroßem contrast scene to do that somehow in the few available Tonwertstufen hineingezwängt be. There are plenty of websites that impressively demonstrate how rarely colors of the sRGB not be covered in natural scenes occur.
Antwort von Marco:
It suggests that it is perfectly easy to handle it. The Canon 5D makes it in principle, not unlike almost all DV, HDV and AVCHD cameras (but perhaps there is only extended upwards, ie up to RGB 254/255).
Which editing system can handle because with xvYCC? Each can, in principle, with RGB 0-255 bypass (while not the decoder is stubborn and too early to really use a scalpel).
But I think with xvYCC is anyway not to do.
Special s.diesem The current case is just that the recording of the signal is in Quicktime container happens and thus the flexibility in the first decoding is restricted. Would there not the Quicktime container used, there would have been synonymous nobody s.den signals because it would be easier to circumvent. With all this I mean primarily H.264. How problematic or unproblematic synonymous with the other codecs, which are embedded in Quicktime and decoded through Quicktime, I do not know. So the case of H.264 clips of the Canon 5D, you should not necessarily transferred to other formats.
Sure, not everyone can just ignore the standards. The more flexible a handling remains, the more must be precisely the objectives and the best way to keep an eye on are.
I am not yet a problem to befall the editing system with an RGB signal of 0-255 to handle, even if it s.Ende to sendegerechtem 16-235 compressed to ultimately YUV signal from the Betacart geschaufelt them.
Marco
Oops, this was faster MacPro ...
Antwort von MacPro:
hehe ;-)
Antwort von Axel:
The objection that many output devices and
codecs are not the full luma range which stands on an entirely different matter. The dynamic range of electronic signal processing is limited, and in the recording must be the one to decide which area of particularly good drawing should have (usually yes skin) and the other clipping must be avoided. As my outpost say this is all about, synonymous in the post is room to have, and I can not see why the creators of television should not be relevant.
Masch wit, on the other hand, leads a huge effort to away or limited signals in digital compression and reconstruction throughout the machining process to preserve. The goal here is admittedly the Fazen. Movies with a DV Camera (28 Days Later with the Canon XL-1 for example) should not be a bit more away, but then presentable.
Professional film people, such as mash slightly scornful wit out, go the opposite way: recording with analog film in partially 8k resolution, the flight to a digital intermediate under 2k compressed. The color correction is done with hardware, which costs six totals, but with real-time algorithm works, the color and brightness information with similar cuts and distorted as consumer cameras do. Treffpunkt Movies.
Antwort von WoWu:
Short Intermediate Question:
Has the camera and a generator FB says what the signal relative to the signal generated image?
xvYCC does not solve the problem, or is the answer to a question that was never raised: the expanded xvYCC color space, ie the Tonwertabstände remain in Comparison to conventional Y'CbCr same. not the xvYCC expanded Luma. This is wrong, we have scjliesslich with a color
space to do so.
The digital extension spaces of values of 1-16 and 241-254 in the chroma-axis and of 1-15 and 236-254 in the luma axis exploited.
(Minus the sync-values). The definitions can be in 8 or 10 bit quantization can be defined.
This would xvYCC the problem fairly well and above all would be back data back to RGB and not reproducible such a piñata, which no formula can capture, because it makes this project certainly not for the NLE. At least if it goes to a tape, it will be above and below geclipped, so what has it brought?
Apart from the great impression at work.
Something else will be, if I am with my Raid go to closing date. I see an advantage synonymous, times of the calculation errors in the transition to R'G'B 'apart.
Antwort von Marco:
I do not know if the Canon offering. But I would be a generator of a FB-Konsumerkameras never want to leave. Who guarantees because, then, that
the standard is? I have there already seen enough fantasy bar ...
Of deriving pure interest but the question: What could be shed in this specific case, a Normfarbbalken give? That does not respect the Camera, Aperture / Gain / Exposure / Gamma / Black / White value was incorrect?
The effect of the codecs is so outside.
Or is it simply a question of making a clear statement to be able to meet that standard white, standard black and all colors of a standard color bar in this case in the NLEs to RGB XYZ gemapped be?
"This would make the problem xvYCC very fair" What does not work unless there NLE can handle it.
"At least if it goes to a tape, it will be above and below geclipped, so what has it brought?" Oben will not be long Clipped. "Tape" is not the synonymous factor. Also below, only if in the post - as described above - was not taken into account and also on analogue weiterschreitet ways.
Also already mentioned several times above: it is a question that the range of values not only watch, but synonymous use and even to a fair standard broadcast signal can be expected inside. Just as, for example, a Black Stretch camera works. It does so even for those selbststranguliernden field potential, which will only be used.
Least benefit has in any case a clippendes decoding. This is just an extreme sledgehammer method. Actually, almost a meltdown in dealing with codecs.
Marco
Antwort von WoWu:
At the point it is a question of synonymous Color matrix of the camera, because the needs of the negative values to positive values, because no monitor can show negative values. And it is these processes that ultimately a signal from his so synonymous arbitrariness get, rules standardized procedure, as for the IEC 61966-2-4 xvYCC.
Yes I see the approach and the gain can indeed synonymous understands only I do not know whether such a "luck" is the solution.
The color bars would be at least an indication of whether the downstream video signal on the spacing within the matrix is because of negative values, through the color-space conversion matrix back into positive values to be converted. .... Or whether it really just a "coincidence signal" is what it comes from the camera. That is now not at all pejorative, but sometimes just for the consumer market was built, what professional standards are not really equivalent.
Only then I would not bet, because then the next camera again can look quite different.
And, as I said .... this is so then no Endsignal and s.der next conversion is either flutes or looks fairly "random" out.
Least benefit has in any case a clippendes decoding. This is just an extreme sledgehammer method. Actually, almost a meltdown in dealing with codecs. Since I am fully with you ... but such things can be so synonymous about other curves regulate much more elegant than simply spaces in values to go to the next Verabeitungsschritt no longer knows.
.
Also already mentioned several times above: it is a question that the range of values not only watch, but synonymous use and even to a fair standard broadcast signal can be expected inside. And there is obviously a danger, because you have a signal Stauch, whose elongation did not really know. You lose this fairly random values, which you've painstakingly assembled.
Basically, we are on target so agree, I prefer just reproducible (standardized) methods
Antwort von Marco:
Well, the problem of clipping the 5d clips can be applied to Windows-based systems in any case by Frameserving - and thus bypassing of Quicktime - resolved.
As the Page on Mac looks, I do not know, but I would be interested synonymous. I have repeatedly pushed for the info, that it either directly through Quicktime settings in Final Cut yet feasible. But apparently it goes on any, not previously described in the Color Way.
"And lose you quite a coincidence values that you have painstakingly assembled." Yes, I have no direct (or only a very limited) influence on what information really rübergerettet then and what is not. But at least I can during the process (filtering) and observe in order to judge whether the so-onist.
If the camera has the same limiting recording, synonymous yes, I have no direct influence and usually even less control (when it's not a turn with parallel technical control).
Important and decisive but, for the environment with the best possible solution for the processing of the signal to see how it delivers just the camera. Clipped lands actually black and white in my NLE, I have this hands tied. But if I know that the camera itself does not synonymous Clipped and has not recorded it, I can of the matter to the bottom, a solution to a decoding without clipping and looking for any further step in the required environment.
Marco
Antwort von MarcBallhaus:
So, if you clip, which with the 5D was filmed in Quicktime opens and MPEGStreamClip in parallel, so you can see very clearly that the player Quciktime the contrasts are higher than in MPEGStreamClip really very clear, especially in the highlights are a lot of information away .
And usually does so synonymous QT like Final Cut Pro or Compressor, but I have to check out separately.
MB
Antwort von Marco:
At least in FCE is identical with the representation of the Quicktime player, that is, by decoding with Clipped black and white. I think Final Cut, in whatever version, is in the background to the Decoding of car MOV files always use Quicktime and until that happens, the H.264 files for the Canon no chance for a ungespreiztes Signaldecoding.
Supposedly it in a way yes Color, without clipping to decode. I can not verify.
MPEGStreamClip Runs on Mac platform? Then there would be synonymous with an easy way to escape the problem.
The Windows sometimes mentioned possibilities, by QuicktimePro to Avid DNxHD to convert (the worse the situation is even) or inside of Windows applications to use CoreAVC, actually, unfortunately, bring nothing, because it does not prevent the decoding still runs on Quicktime . The only exception seems to be the use of Cineform Neo, in conjunction with CoreAVC to be. Even I have only reviewed the method by FrameMaker Server. The works reliably.
Marco
Antwort von MarcBallhaus:
Supposedly it in a way yes Color, without clipping to decode. I can not verify.
MPEGStreamClip Runs on Mac platform? Then there would be synonymous with an easy way to escape the problem.
MPEGStreamClip available for PC? I did not know clearly runs on the Mac. And for the color decoding is rather not the right tool for ...
Can MPEGStreamclip stacking process? I've never been really involved ...
MB
Antwort von deti:
ffmpeg is your friend.
Deti
Antwort von Matzel:
Hello,
Apple has kindly responded yesterday and the 7.6 QuickTime update to fix the problems. QT processed now offered the full range of 0-255 and is no longer s.den video standard of 16-235. I can only speak for Mac, but from what I have read some forums, this is synonymous for QT under Windows.
Greeting
Antwort von Axel:
Good news.
Antwort von MarcBallhaus:
FFMpeg I angeguckt ... open source, which is handling her more of the PC division, you must have 4 Programs and looking to install a purpose to fulfill ... garnicht goes.
Thanks anyway for the tip.
I then update QT times.
MB
Antwort von filmpraxis:
I have the contribution with interest. We doktorn long s.diesem problem around. I can confirm that it is Apple with QT 7.6 on the PC works. Just install it and restart rejoice - after all the expensive tests, it is somehow different to be resolved.
I have Edius synonymous with 5:01 tested. The original clip is already in great quality and still win, if we in this de Canopus HQ codec converts.
Tip for a quick test: MOV QT to play in, then in the menu to "copy" and go in an image viewer / on "Insert" go. With all other versions of QT Picture here is the darker.
Thomas Wagner
Antwort von MarcBallhaus:
I have Edius synonymous with 5:01 tested. The original clip is already in great quality and still win, if we in this de Canopus HQ codec converts.
A codec the quality improved? Ah yes. Very interesting.
Tip for a quick test: MOV QT to play in, then in the menu to "copy" and go in an image viewer / on "Insert" go. With all other versions of QT Picture here is the darker.
Thomas Wagner Precisely not. Oh people ... in QT, there is a compatibility mode for Final Cut Pro, which makes the picture darker s.der what is gamma shift. That has hardly ever done.
---------
I now have the new version of QT installed and the problem remains the same. A PNG, rausgerechnet with MPEGStreamclip has more dynamic range than the same frame with QT to PNG. The latter can be seen in the histogram shows that the top and bottom simply something was cut off, and exactly at 16 and 235th
MB
Antwort von Marco:
Just the update in the Windows version. Thus the problem is definitely fixed. I think it's just heavy enough that Apple has for three years needed.
Marc ball home and I can prove it on the Mac is not currently with a Waveformdarstellung check. But the comparison shows picture after the update to the Quicktime prerelease more recognizable details in lights and shadows. So an improvement can I know, but I do not know whether the clipping so that - as in the Windows version of the case - is completely solved.
Marco
Antwort von MarcBallhaus:
Just the update in the Windows version. Thus the problem is definitely fixed. I think it's just heavy enough that Apple has for three years needed.
Marc ball home and I can prove it on the Mac is not currently with a Waveformdarstellung check. But the comparison shows picture after the update to the Quicktime prerelease more recognizable details in lights and shadows. So an improvement can I know, but I do not know whether the clipping so that - as in the Windows version of the case - is completely solved.
Marco The improvement I can see, is but the gamma is not the clipping.
MB
Antwort von Marco:
Changes in the gamma, I have not really taken into account. There are obvious improvements in the darkest black and white areas. But for me being on the Mac, unfortunately, not measurable.
Marco
Antwort von domain:
An exclusive gamma change, I can not really imagine this would be a joke. The picture would be softer look (spread of 226 to 256 levels with finer gradations) but that would be yes in the Clippingproblem None solve.
Antwort von Marco:
I am on the Mac, time to go through a graphics software has gone to make it at least by histogram can be compared. Unfortunately, I have from the old version QT only a single screen grave, where the lights were so very critical. But in the black area was there with QT 7.5 still clearly visible and clipping synonymous measured by histogram. With QT 7.6 shows the same clip synonymous in the histogram in black no longer clipping. What there beforehand by clipping was cut off in the black, is now as image information in the field 0-15 receive.
Marco
Antwort von Axel:
The problem is, at least for Quicktime, resolved, the thread obsolete. Everything now comes to mourn clipping of the exposure in the recording ago.
Antwort von MarcBallhaus:
The problem is, at least for Quicktime, resolved, the thread obsolete. Everything now comes to mourn clipping of the exposure in the recording ago. Aha. And why then do I see a difference of the SAME recording, between MPEGStreamclip and QT? Whether displayed or exported, QT cuts at 16 and 235 s.and stretcht to 0 and 255th
MB
Antwort von domain:
Now is really interesting to look'm curious whether Ballhaus right, this would be a strong piece of
Antwort von Marco:
...
Antwort von Marco:
Since I now MPEG Streamclip on the Mac and have installed a few comparisons between Streamclip and Quicktime Player on Mac platform and Frame-exports from both tools with the Windows results compared, I understand nothing more.
Marco
Antwort von Marco:
Hab nochmal out-and herverglichen, synonymous between Mac and PC. Between the previous version of Quicktime 7.5 and the current version 7.6 is definitely a huge difference. Significant clipping in black and white with version 7.5, in principle, no more clipping in black and white with version 7.6 - neither on Mac nor on the PC.
The Quicktime versions decoded signal between Mac and PC are essentially identical. I checked the signals on the PC with Waveform, Histogram and RGB Parade. From the Mac, I have the Canon H.264 files into FCE imported and of there as a Quicktime file with PNGs exported.
I also have the Mac on MPEG Streamclip PNGs exported. Streamclip These signals are again identical with the versions that I am on the PC via streaming server s.Quicktime vorbeigeschleust hab. So the output of Streamclip for Mac and PC servers to stream, I can actually equate. And of course here is not synonymous clipping in lights and shadows.
Nevertheless, there is a clearly visible and easily measurable difference between the "Stream" and versions of the Quicktime versions. The Quicktime versions are almost never under RGB 16, have a total of a "brighter" side of gamma and (not clipping), the white then eventually something more. From clipping in white but you can not really be any question, or if, this would be in an area of only about 1 or maximum 2 percent. I could, what I see there, especially in comparison to the previous version of Quicktime but not as a clipping call. In black eh not.
Overall, the Quicktime versions Dynamics nevertheless something more to offer than the "Stream" versions. Only we know without a test pattern as the base is not what kind of signals is authentic.
Unlike the output of Quicktime 7.5, I could now live with both versions.
Marco
Antwort von MarcBallhaus:
@ Marco ... machs but not so complicated, is an ever exported from PNG MPEGStreamClip and QT - s.Mac - Lad and both in Photoshop. Then you can see in Histo that QT variant clippt. Does it using Curves in the Dynamics of MPSC version on 16 and 235 to the PNG looks exactly the same way as from the QT. So clippt QT.
MB
Antwort von Marco:
That I had made synonymous (if not synonymous in Photoshop). Since clippt it does not, or so minimal that it really is not relevant. And the differences to the previous version of QT are immense.
Marco
Antwort von MarcBallhaus:
That I had made synonymous (if not synonymous in Photoshop). Since clippt it does not, or so minimal that it really is not relevant. (...)
Marco You're so funny. So clippt it!
Then filme times at night and then you will see that what previously was minimal, and suddenly a problem, because the contrasts are s.höchsten night and then you especially on highlights and drawing in the depths are dependent, while the mids are schnurzegal in Tagaufnahmen it is the other way around.
MB
Antwort von Marco:
Hab times a linear contrast curve (RGB of 0 to 255) rendered as Quicktime H.264 decoding and analyzing different. If the H.264 signal decoded on a Mac, is the contrast curve is changing. With an uncompressed AVI does not happen there. On the PC's happening is not synonymous with H.264. Moreover, the variants, which (from Mac) from MPEG Streamclip export as a frame go out with gamma 2.2, almost identical with the Quicktime expenditure (tested on the PC). But with output from 1.8 Gamma Streamclip is much closer s.Original.
So in everything I have of the Mac-output of the H.264 files have seen is a change in the contrast curve evident in Quicktime more in Streamclip less dramatic, depending on the export setting. In none of the cases, the contrast of the original curve at H.264 decoding on the Mac correctly reproduced. Clipping is only slightly out (3 percent).
I think the clipping problem with Quicktime is largely resolved, but the portrayal of the contrast curve in Mac processing can still be optimized a bit.
"You're so funny. Clippt So it is!" For critical signals have been with Quicktime 7.5 or 13 percent of the signal Clipped. With Quicktime 7.6 there are only about 3 percent. The exact value, I know, only since I have been there with the Grauverlauf able to test (for the real videos, which I last night was under the microscope, it was not as precise analysis). This is already a huge improvement.
The actual signal has changed a lot with the change of the curve, but less with the clipping to be done. That was with QT 7.5 still quite different. Would the gamma nor optimize would probably be in the visual inspection, no difference even more apparent. Indeed, by the gamma correction to Mac-Export curved back to the original curve to straighten. So mostly it's a gamma issue. The loss by clipping remains synonymous after the gamma correction.
The histogram is not this way, as a good instrument. The Waveform display makes clear what happens.
Marco
Antwort von MarcBallhaus:
The speech is not generally s.Mac of H.264, but recordings of the 5D in H.264/MOVs available. What you describe is pure theory, what I write is practice. Sorry, do not misunderstand, but your results may be theoretically correct, but practically, it is simply not the case.
The histogram me is the best tool to identify Tonwertumfang, because nothing else is there.
Antwort von MarcBallhaus:
The difference for Quicktime PNG is minimal but not significant. From Histo apart, are the top right of the picture black holes, just left of the Rhine, while the Picture from MPEGStreamclip still has significant drawing.
Antwort von Axel:
You're right, QT is pretty much in black Clipped. Only the Mpeg Picture SC can be read via a Levels (but only if) the bare branches of winter left in the sky once again be made visible.
What remains, then, if one with Final Cut Pro to cut? Original file from the Camera in Color import and output as uncompressed 10bit ...
Antwort von Marco:
Of course, dealing with test images generated away from practice. But so far no such review of the Canon Clips indeed any objective reference! As long as you do not know how a picture at all in their original state could look like, you can hardly make reliable statements about what the Picture tool ultimately represents the best and where exactly the error happens. Because I must give Wolfgang quite that of the Canon-generated, standardized color bars would be very valuable (and better than a self-generated and to test H.264 encoded picture).
The difference in your screenshots is really clear. But even the signal from Streamclip clippt still a little. The clipping in Black, based on your Quicktime version can be seen, also seems like the above 3 percent requirement. In this design synonymous purely visually recognizable in which I have had, unfortunately not.
If the original file somewhere, perhaps as a universally accessible and legal download?
What bothers me is s.meisten is primarily the difference between the Mac and the PC-Decoding. If I were a Canon 5D file from FCE as an uncompressed AVI and export this output with the original Canon-signal on the PC, see, I have the Gamma of the Final Cut Pro signal to raise the value of 0.4, a principle similar presentation to have. So the comparison of Mac and PC edition kills the difference in gamma erstmal any other errors.
Marco
Antwort von MarcBallhaus:
If the original file somewhere, perhaps as a universally accessible and legal download?
These are all Mood shots, with 1-2 minutes in length. I look but check out what s.Ausschuss here is where I maybe after 5 seconds have ... you have an email address for me?
MB
Antwort von Marco:
I have a few web sources found. I look first to whether there maybe a few critical motives are anything.
Marco
Antwort von MarcBallhaus:
I have a few web sources found. I look first to whether there maybe a few critical motives are anything.
Marco Because I would not so much on it, because what little I've seen where people have found the right settings.
MB
Antwort von Bruno Peter:
Can you this clip at the bottom right there Vimeo need?
http://www.vimeo.com/1764260?pg=embed&sec=1764260
Antwort von Marco:
Yes, thanks for the link.
Marco
Antwort von Marco:
In this recording, the camera already krass fehleingestellt, but I could so rudimentary synonymous clipping in black to understand. Had a summons today again of about 10 completely different 5D clips durchgeschleust. The problem with the wrong Gamma-export the FCE and the correction value of +0.4 for the PC is all the same.
Apparently there is on the PC with Quicktime Decoding the clipping problem in the shadow not synonymous to the low 3 percent. But that's me with the available clips are not clearly spelled out. This last clip is qualitatively easy grottig bad. Nevertheless, there are in the shade here and as a "detail", according Quicktime Decoding on the Mac is no longer reproducible, the same as s.einer Color correction is screwed.
Marc ball home if you have a short sample a motive similar to that shown on the screenshot, would find, it would be interesting. Because in a high-quality signal, I could reliably test whether and how the clipping between PC-and Mac-Quicktime Decoding differs. My mail Contact:
zum Bild Without doubt, however, is with the Quicktime Decoding a bit of what Argencard, despite considerable improvement over the previous version.
Marco
Antwort von MarcBallhaus:
@ Marco
I have sent you Rohschnipsel NEN. The buggy is because I forgot to switch off automatic, but it is synonymous only 20 MB. But the test is perhaps garnicht so bad.
Gib doch mal feedback would be glad.
MB
Antwort von Marco:
Super, thanks for the clip! War is the right motive.
So: first to the PC, which is fast manner. Whether I am on the PC with the clip of the Windows version of MPEG Streamclip, Quicktime Player or the editing software (for the decoding of Quicktime back) decode, makes no difference. The Gamma true and apparently even the deepest shadows are not Clipped.
Because of doubt as objective reference in the form of a standardized Farbalkens from the camera is missing, is the assumption that the gamma of the Windows versions is correct, is still a part speculative. I am on the test series with the internal generated Graukeil, after Quicktime H.264 Encoding and Decoding followed correctly described. That still holds a certain potential for error.
On the Mac:
Since I use the signals on my MacBook can not really check, I have both an export to PNG image sequences made. Once with MPEG Streamclip and once with FCE. The PNG sequences, I then checked on the PC.
Both versions - Export from FCE and export from MPEG Streamclip did the same. To set the value of 0.4 and gamma also changed the slight clipping in the shadows.
If I Streamclip from a person other than the single frame export select, I have no choice at Gamma. I think it will always use 2.2. That appears on the Mac in Streamclip and Quicktime for the largest deviation to lead.
I then again the first frame of the clip Streamclip with gamma 1.8 exported. The result is better, lies somewhere between the 2.2-version and the Windows versions and the clipping seems basically eliminated.
What surprised me is that the Mac Streamclip export on the one hand, the gamma in the 1.8-export option, ultimately does not lead to a deviation of 0.4 compared with values of 2.2-export option and so is still not equal to the Windows versions.
On the other hand there are synonymous (in the case of the gamma 1.8 export option), the darkest shadows still heavily compressed so that it at such a critical motif s.einem just clipping vorbeischießt.
So times regardless of what tool is the platform on which leads to the optimal decoding, it is not me, when decoding the 5D clips on Mac and PC a single result.
Marco
Antwort von PowerMac:
The gamma shift is, therefore, since the Mac Quicktime own gamma value of 1.8 is trying to offset. And I, for example, a monitor-Gamam of 2.2 was wrong ... Again:) Impossible a standard for the "right" set up reception. Too many monitors, viewing situations, parameters ...
Antwort von Marco:
I fear Sowas synonymous. I'm on a Mac are not yet fixed saddle. I just always thought that the gamma of 1.8 for Mac-only internal viewing and player would be relevant, the final video export but basically for a 2.2-playing should be designed. I believe, for other video formats will be in Quicktime (Mac) synonymous account. Only H.264 seems to be out of line to dance.
What synonymous again the question in the room, which gamma-mapping because the Canon D5 during H.264 encoding is used.
My uncertainty whether with Quicktime 7.6 on Windows platform because it really is perfect as it seems at first sight, it is perhaps not entirely synonymous unjustified. There are conjectures (in other forums) that the only "Quick'n'Dirty" solution is a bit unhappy with the 3 different color spaces and hergewandelt out, which will result in a signal without clipping of black and white leads the 8-bit signal but overworked, so that information s.anderer agency lost. S.Lückenbildung is recognizable in the histogram. That I had something synonymous with astonishment noticed.
There is also here and since expressions mean that the gamma when decoding H.264 via Quicktime on Windows platform, something is too high and thus the picture seems brighter than it should be. Then would ultimately almost no decoding version more correct (especially since the result of the Windows version of MPEG Streamclip with the Quicktime result is identical).
Maybe it was the result of MPEG Streamclip for Mac (and the stream server version for the PC) is still the best, in terms of: s.nächsten s.Original.
Marco
Addendum:
The solution to the authentic look and also in each meter shows the fewest artifacts, is with the Streamserving via AviSynth.
On the other hand is suspect still on the way Quicktime. As was with the solution of one problem seems to create new problems.
MPEG Streamclip with gamma 2.2 output has just artifacts AviSynth as the solution, but probably wrong and gamma clippt. MPEG Streamclip with gamma 1.8 clippt although probably not more, but have more artifacts (but still less than Quicktime on Windows) and it remains questionable whether the gamma here is correct (the question arises, however, so far in each of the solutions described here ).
Antwort von MarcBallhaus:
Please gerngeschehen:)
I follow now that you are not the clipping to the extent you, as I had it?
MB
Antwort von Marco:
Hab noch was added above. I would you like some results, including the indications of the measuring devices (Waveform, Histogram and RGB Parade) to you. The fact that each tool produces a different result, however, slows down.
My momentary Conclusion would be that despite the Quicktime update for a result with as little loss of quality Quicktime should be avoided, on the PC is still better than the way Frameserving should have gone to the Mac, MPEG Streamclip with optimal gamma-mapping (if possible).
Who alone is satisfied that the Quicktime update the clipping more or less improved and other factors in the theoretical rather distinct niche, is with the Quicktime update of course, a simple solution.
For you personally is probably more the Mac Page of importance, right?
Marco
Antwort von MarcBallhaus:
For you personally is probably more the Mac Page of importance, right?
Marco Yes, even more. I still have several PCs, but it is synonymous a MacBook and a couple of decent Mac Pro. But if only on the PC easily, then just PC.
MB
Antwort von Marco:
On Windows, I have actually no clipping, not synonymous with Quicktime 7.6. But the results are still questionable, with the exception of FrameMaker Server method.
I come today not to collect examples. I'll tomorrow or the day after nachholen.
Marco
Antwort von Marco:
The examples are summarized ->
