Subtle contrast changes when wrapping m2t -> mov at
DV Info Net

Go Back   DV Info Net > Apple / Mac Post Production Solutions > divergent media ScopeBox and ClipWrap

divergent media ScopeBox and ClipWrap
The official support forums for divergent media's ScopeBox (video monitoring and recorder) and ClipWrap (m2t to .mov re-wrap).

Thread Tools Search this Thread
Old December 27th, 2009, 09:15 AM   #1
Join Date: Dec 2009
Location: Belfast, N.Ireland
Posts: 3
Subtle contrast changes when wrapping m2t -> mov

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?

Shane Kelly is offline   Reply With Quote
Old December 27th, 2009, 12:24 PM   #2
Inner Circle
Join Date: Nov 2006
Location: Tallahassee, FL
Posts: 4,100
Gamma shift. Common problem with quicktime. Hopefully, clipwrap has a solution for you.
DVX100, PMW-EX1, Canon 550D, FigRig, Dell Octocore, Avid MC4/5, MB Looks, RedCineX, Matrox MX02 mini, GTech RAID, Edirol R-4, Senn. G2 Evo, Countryman, Moles and Lowels.
Perrone Ford is offline   Reply With Quote
Old December 28th, 2009, 03:36 PM   #3
divergent media
Join Date: Sep 2006
Location: United States
Posts: 52

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.

Mike Woodworth
Mike Woodworth is offline   Reply With Quote
Old December 28th, 2009, 05:06 PM   #4
Join Date: Dec 2009
Location: Belfast, N.Ireland
Posts: 3

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.


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
Shane Kelly is offline   Reply With Quote
Old December 28th, 2009, 05:31 PM   #5
Major Player
Join Date: Apr 2006
Location: Melbourne, Australia
Posts: 825
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.)
David Knaggs is offline   Reply With Quote
Old December 28th, 2009, 10:22 PM   #6
Major Player
Join Date: Sep 2008
Location: East Bay Cali
Posts: 563
Originally Posted by Shane Kelly View Post
if you chose to simply 'wrap' it, rather than transcoding it to another codec. Could this be something to do with my setup - Quicktime?
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.
Re-learning everything all over again, one more time.
Marty Welk is offline   Reply With Quote
Old January 2nd, 2010, 01:43 PM   #7
Join Date: Dec 2009
Location: Belfast, N.Ireland
Posts: 3

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 Kelly is offline   Reply

DV Info Net refers all where-to-buy and where-to-rent questions exclusively to these trusted full line dealers and rental houses...

B&H Photo Video
(866) 521-7381
New York, NY USA

Scan Computers Int. Ltd.
+44 0871-472-4747
Bolton, Lancashire UK

DV Info Net also encourages you to support local businesses and buy from an authorized dealer in your neighborhood.
  You are here: DV Info Net > Apple / Mac Post Production Solutions > divergent media ScopeBox and ClipWrap

Thread Tools Search this Thread
Search this Thread:

Advanced Search


All times are GMT -6. The time now is 11:10 PM.

DV Info Net -- Real Names, Real People, Real Info!
1998-2020 The Digital Video Information Network