Administrators Andrew Reid Posted January 13, 2015 Administrators Share Posted January 13, 2015 Could this problem - http://philipbloom.net/2013/02/03/canon-1dc-mjpeg-compression/Actually be this? https://forums.adobe.com/thread/1119755It seems to me like the infamous 8bit banding we see with some cameras actually... shock horror... not the fault of 8bit OR the camera, but a bug in Adobe Premiere.Scaling for retina displays and other forms of display driver funkiness can also cause banding.So I got my Samsung 4K display out and tried playing back the file 1D C 4K MJPEG file in Quicktime at the native res (no scaling). To my astonishment the banding vanished. Just a bit of blocky noise and that's it. Looks even better in VLC Player with a fine noise grain over it applied in the player settings.Here's an exported frame in TIFF format and a screen shot of the same file in Quicktime Player at native 4K res on my Samsung display. Pretty big difference!!http://www.eoshd.com/uploads/1dc-premiere.zipNothing special just a very shoddy test shot But 2 thirds of the frame are gentle gradients so great to test with.As you can see the output of the file in Quicktime is much smoother than in Premiere which has the discoloured banding every other 1D C user reports.So... what's the cause? And why the hell can't Adobe test their products properly? Going to switch to Resolve for editing if they don't fix it. It may have effected my other cameras too, like the NX1, so quite serious. The problem is on both the exported video and the Premiere timeline at 100%.Really need to find a fix. The video preview settings for the sequence don't change it, neither does swapping between CUDA, OpenCL and software for the mercury playback engine. Tried a lot of other settings too but no good! Quote Link to comment Share on other sites More sharing options...
jcs Posted January 14, 2015 Share Posted January 14, 2015 It's likely Premiere's QuickTime importer (.mov container). Are you using Windows or OSX? Have you tried rewrapping the MJPEG from .mov to .mpg/.mp4/.avi? To get around a PPro bug a while back I renamed the .mov files to .mpg (or perhaps it was .mp4) to get PPro to use the native importer vs. QuickTime (QT and MP containers are very similar which allowed the trick to work). You could use ffmpeg to quickly rewrap MJPEG in .mov into a .mpg/.mp4/.avi container. Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 14, 2015 Author Administrators Share Posted January 14, 2015 Found a fix and it's even more astonishing.1D C uses the ITU 601 decoding matrix (not more common HD rec.709) and luma is 0-255 full range, not broadcast safe range of 16-235.Transcoding in 5DtoRGB to a luminance range of 16-235 fixes the problem.Premiere is definitely not supposed to screw your 0-255 footage like this. In the fast colour corrector you can simulate 16-235 from 0-255 by changing the input range to those figures. The banding remains.So import a 16-235 file and it's fine, but the problem now is that the dynamic range is reduced because 0-255 isn't remapped to 16-235, it's clipped instead.Here's my theory as to what Premiere is up to - I think it's trying to do some dodgy remapping of 0-255 footage to the broadcast standard of 16-235 and giving us banding on a ton of 8bit cameras. Not good!! Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 14, 2015 Author Administrators Share Posted January 14, 2015 Resolve seems to be the answer.It handles the 4K MJPEGs properly, converts in realtime to ProRes and the files then display correctly in Premiere and are fluidly editable.Difference is marked.Blog soon. I think this same trick can be applied to other cameras like the NX1. Will test.Seems we have not been doing them justice by using Adobe software. It's bad. Very bad for them to not have fixed this yet. Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 14, 2015 Author Administrators Share Posted January 14, 2015 First shot, 1D C in Premiere, exported to 4K TIFF frame, converted to 1080p JPEG in Photoshop for the webSecond shot (below), 1D C in Resolve, exported to ProRes. Then into Premiere, 4K TIFF to 1080p JPEG same as above. Even without looking at the 4K version you can tell the difference, so will apply to final Vimeo upload and how the mass audience sees your material... Quote Link to comment Share on other sites More sharing options...
FilmMan Posted January 14, 2015 Share Posted January 14, 2015 Glad you're enjoying your new toy. Lot's of fun lies ahead. I went through a lot of growing pains too. I'm still haven't hit puberty with the 1DC yet. Interesting discovery that you made with Premiere and the footage. Cheers. Quote Link to comment Share on other sites More sharing options...
jcs Posted January 14, 2015 Share Posted January 14, 2015 This may be the same problem: https://vitrolite.wordpress.com/2010/12/31/quicktime_gamma_bug/ . A faster solution (faster than real-time, can put into a script and fully automated) might be to rewrap out of the .mov container to .mp4/.avi to avoid the QuickTime decoder in PPro. Something like this:ffmpeg -i <1DC file>.mov -vcodec copy -acodec copy <1DC file>.mp4 This will run very fast and can easily be scripted to process a whole directory. Much faster and easier than Resolve or any other method (if it works).Can you upload a couple seconds of raw 1DC footage with banding? Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 14, 2015 Author Administrators Share Posted January 14, 2015 Resolve uses the GPU to render to ProRes, does ffmpeg? If not then it isn't faster, and if you want to transcode only a selection of clips in the directory, you'd have to list them out one by one on the command line or move the clips to their own directory... pain in the arse! Quote Link to comment Share on other sites More sharing options...
sunyata Posted January 14, 2015 Share Posted January 14, 2015 Good suggestion jcs. That should be nearly instant btw because it's not re-compressing anything. Another thing to note is that a screengrab of the QuickTime player window might not accurately represent that file (I've heard lots of designers complain specifically about qt player). Save out a static to do a "fcheck" in something else, Photoshop etc."ffmpeg -ss 00:00:04 -i myfile.mov -t 1 -pix_fmt rgb24 myfile.tif" <= that will save out one frame 4 seconds into a clip as 8bit uncompressed rgb tiff. An open source fcheck utility: http://opensource.mikrosimage.eu/duke.html Xavier Plagaro Mussard 1 Quote Link to comment Share on other sites More sharing options...
jcs Posted January 14, 2015 Share Posted January 14, 2015 Thanks sunyata.Andrew- using ffmpeg with 'copy' for both codecs will run as fast as copying the files- zero transcoding. Renaming <1DC file>.mov to <1DC file>.mp4 might also work (I used this trick before- might work here too). Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 14, 2015 Author Administrators Share Posted January 14, 2015 I heard about the file renaming technique and the stream copy. Whilst I think both of you for your suggestions and effort, unfortunately the approach doesn't work.The 1D C needs to be ProRes (via Resolve) for you to edit it smoothly and for Premiere to not break the footage with a ton of banding. Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 14, 2015 Author Administrators Share Posted January 14, 2015 Click to enlarge... The left is Quicktime Player and the right is Premiere, same clip. That shadow has gone to hell! Quote Link to comment Share on other sites More sharing options...
jcs Posted January 14, 2015 Share Posted January 14, 2015 Yeah, the performance on the right is pretty shady! Xavier Plagaro Mussard 1 Quote Link to comment Share on other sites More sharing options...
aldolega Posted January 14, 2015 Share Posted January 14, 2015 Does this happen on Windows? Hasn't OSX/Quicktime had gamma clipping problems like this for years? Quote Link to comment Share on other sites More sharing options...
sunyata Posted January 14, 2015 Share Posted January 14, 2015 Another good frame check:http://sourceforge.net/projects/djv/files/djv-stable/1.0.5/can import cineon/dpx, create custom profiles, import LUTs (.lut files), do conversions (no, I'm not getting paid). Quote Link to comment Share on other sites More sharing options...
Nikkor Posted January 14, 2015 Share Posted January 14, 2015 Enjoy your mac. Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 14, 2015 Author Administrators Share Posted January 14, 2015 Does this happen on Windows? Hasn't OSX/Quicktime had gamma clipping problems like this for years?So far nothing to suggest it is the gamma issue. Black levels and brightness all normal, no clipping. The banding is a different thing. Will try on Windows version of Premiere CC and see how it goes. Quote Link to comment Share on other sites More sharing options...
Nikkor Posted January 14, 2015 Share Posted January 14, 2015 Does it also happen in After Effects? Quote Link to comment Share on other sites More sharing options...
sunyata Posted January 14, 2015 Share Posted January 14, 2015 So far nothing to suggest it is the gamma issue. Black levels and brightness all normal, no clipping. The banding is a different thing. Will try on Windows version of Premiere CC and see how it goes.Normally you'd only see banding introduced on import if you applied a 3D LUT or downconverted 10bit to 8bit accidentally. My guess is that the banding is in the source and it's just being revealed in Premiere. To test you can render out a short unaltered clip uncompressed from Premiere (full range), then open back up in QT player and see if it looks the same as before. Quote Link to comment Share on other sites More sharing options...
Administrators Andrew Reid Posted January 15, 2015 Author Administrators Share Posted January 15, 2015 Normally you'd only see banding introduced on import if you applied a 3D LUT or downconverted 10bit to 8bit accidentally. My guess is that the banding is in the source and it's just being revealed in Premiere. To test you can render out a short unaltered clip uncompressed from Premiere (full range), then open back up in QT player and see if it looks the same as before. Did that and it has the banding. Premiere is introducing it on export even at the highest quality setting. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.