Subtle contrast changes when wrapping m2t -> mov

[Shane Kelly]

I'm pretty new to ClipWrap - and it seems to work well for my needs, however, I've noticed a slight variation in contrast when comparing frames from the source M2T file (captured from my 1080i PAL camcorder using HDV Split) and the final Clipwrapped version - wrapped without any transcoding.

Consider the side-by-side frames when I load them up into Adobe Premiere Pro CS4. The image on the right is the original M2T HD video stream, whilst the image on the left is loaded from the resulting clipwrapped .mov file.



Ignore the slightly different timecodes between the side-by-side images - you are looking at the same frame in both videos - except that Clipwrap seems to have removed 12 junk/corrupted frames from the start of the original video during the wrapping process.

To confirm that this wasn't an anomaly with my monitor, I used an eyedropper tool to compare the RGB values of a corresponding pixel in each frame and there is a difference in value.

I had assumed that ClipWrap did not modify the video in any way if you chose to simply 'wrap' it, rather than transcoding it to another codec. Could this be something to do with my setup - Quicktime? Adobe Premiere? Not a tremendous show-stopper to be fair, but just curious to know if others are seeing similar behaviour?

ShaneK

[Perrone Ford]

Gamma shift. Common problem with quicktime. Hopefully, clipwrap has a solution for you.

[Mike Woodworth]

Shane,

While it's possible we are tagging this video improperly, it seems unlikely. We embed color transform information in each video as recommended by quicktime. With this format, ClipWrap would tag the video with rec709 primaries... this *should* be the correct format, unless your camera is shooting a different mode than what we've experienced in our testing.

A few questions:
-does this shift happen in other apps? for instance if, you export the mts as a quicktime form premiere and compare in QuickTime Player?

-in the past, some editors have had a gamma shift between preview and canvas viewers. Can you do a side by side with the two clips in the same timeline/ perhaps wiping one to the other?

If both of those still point to a color tagging problem in ClipWrap, send me an email off list so we can arrange a way to arrange a way to recreate this on our end.

Thanks,
mike
--
Mike Woodworth
mike@divergentmedia.com

[Shane Kelly]

Perrone,

Thanks for your prompt reply - it could well be gamma shift - after seeing your response I did a quick search and it seems that lots of other people are seeing this sort of issue - so I'm not alone.

Mike,

I will try the things that you have suggested and get back to you. In the meantime, some more info about my environment.

ClipWrap 2.0.4
Mac OS X 10.6.2 [Snow Leopard]
Adobe Premiere Pro CS4 [4.2.1]
Quicktime X [90.3.1]

Camcorder: Canon HV20
Video: 25fps 1080i PAL HDV

[David Knaggs]

Hi Shane.

Try opening them (both the .m2t file and the Clipwrapped .mov file) side by side with the VLC player and then compare.

The only time I've noticed gamma shift with QuickTime is when exporting or converting to H.264. (There are a couple of threads in this forum about this.)

[Marty Welk]

Originally Posted by Shane Kelly

if you chose to simply 'wrap' it, rather than transcoding it to another codec. Could this be something to do with my setup - Quicktime?
ShaneK

If it was not transcoded, then its the decode, right? different decoders on the computer work different ways/opinions on what makes the pic look the best when decoding. also weather it routes through directx , or even Video cards 3D GPU, and all that stuff. some codecs you can actually select all that stuff with the codecs decode player software, where you can change the entire look of the decode.
i donno, but when playing back stuff here i have my video cards "OVERLAY" set to different settings than the software render, and the first video played snags the "overlay" of the video card for direct show quick playback, the Second video i show, will have to do software render. because i Contrived my video cards overlay settings off of default, the videos using overlay are completly different than the software only, showing of the same thing.
Same thing, if i set the video cards 3D processing different for games, and the decoder or player software will be using the 3D parts of the video card for the decoding process.

Overlay doesnt work with screen grabs, so it is unlikly to be overlay itself, just discussing the myriad of processing possibilities that a video can go through (in a computer) on the most simple decode of a video.
Quicktime for example has , way back in its stuff has many settings that would completly change the look of the decode, along with many other codecs. The decode player change options dont just pop up easily out of the players editors USING the codec, so the adjustability of a codecs decoding is virtually ignored, till this happens.
For Quickslime check out the "Control Pannel" of a PC type computer , as i think the controls for QT are accessable via a Icon tossed in there.

[Shane Kelly]

Folks,

Thanks for your suggestions. I've been doing a little bit of additional investigation here and what I've found would tend to lean towards it being some sort of issue with Quicktime and/or Adobe Premiere on my iMac rather than something specific to ClipWrap (there is one exception though, which I'll get to later).

First, a further demonstration of what I'm seeing in Adobe Premiere:

Sequence01.flv video by ballinascreen - Photobucket

What I've done here is superimposed one video track over the other, and cropped the upper track by 50% from the left to allow the underlying track to show through. The video on the left is the original M2T file captured from my camcorder, whilst the video on the right is the ClipWrapped video. Viewing it this way shows that there is a more significant difference than I had originally thought.

Okay, so first off, I tried a few of the suggestions above:

1. I imported the original M2T file into Adobe Premiere, exported to a non-Quicktime container, re-imported the exported file back into Premiere - and then compared the two. In this scenario there was no perceptible difference.

2. I imported the original M2T file into Adobe Premiere, and exported to a Quicktime container, and then re-imported the file back into Premiere - this time there was a difference (as illustrated earlier)

3. Instead of using ClipWrap to simply wrap my M2T file, I decided to try transcoding to see if that made any difference. I transcoded the original file to Apple Intermediate Codec and Apple ProRes 422 HQ - and then imported these into Premiere as before. The AIC file exhibited the same issue, whilst the ProRes 422 HQ file did not (this is the exception I was referring to earlier).

4. When I compare the M2T and ClipWrap (wrap only) files outside of Adobe Premiere (both on my Mac and PC) using VLC I can see no perceptible difference between the two. However, if I load the same ClipWrapped file into VLC and QuickTime Player I do see differences - bizarrely, the video in the QuickTime player is lighter and less saturated which is the opposite of the behaviour that I see in Adobe Premiere!

5. I could only use VLC to compare ClipWrap files with no transcoding - if I transcoded to AIC (icod) or ProRes (apch) and tried to play them it wouldn't recognise those codecs.

6. Finally, I wanted to try and import the original M2T file and its ClipWrapped (wrap only) equivalent into Adobe Premiere CS4 on a PC to see if it exhibited the same problems there - however I got a 'Codec missing or unavailable' error when I tried to import - wonder what I'm missing here?

I think the body of evidence thus far would suggest that its a localised problem with my setup rather than a specific issue with ClipWrap - I may need to test out a few more scenarios in the meantime though…. suggestions welcome :)

Shane