Messages

Unless Canon tell us exactly what spec a lens must achieve to be given the 4K badge then on it's own it's pretty meaningless. But to say that 4k capture will show up problems with lenses that were fine in HD, or on FF 35mm film, is not untrue.

As you suggest, a decent L series prime will project well over 4k resolution onto a S35 or APS-C sized sensor. Even the sub $100 50mm/f1.8 will do so if stopped down a bit, as will many lenses dating back to 1950s and beyond. Problems are more likely to show up with zooms, even high end ones. However, some of Canons newer zooms are remarkable, and not just those with the 4K badge on them.

Glass is definitely not just glass, not by a long shot. Lenses vary massively in image quality. 4K on S35/APS-C is without doubt challenging and will certainly separate the good from the bad. But the lack of a 4K badge does not mean a lens aint good enough, just that it aint part of this particular marketing drive.

Thanks folks, much appreciated. It's available in 4k UHD from Vimeo on Demand. First 50 people to use the promo code MAGICLANTERN will get a free copy.

Thanks again.

We shot this last summer, making heavy use of Magic Lantern ETTR timelapse features. Thanks again to all the developers and everyone else who's helped answer my stupid questions.

I'd try making the white balance very warm, shift greens towards yellow and desaturate a little, blues towards green (maybe?) and desaturate. Not too much contrast.

The Wedge, I like it. Taking tokina a while that filter int it. I keep checking too. Not much new on our vimeo. Working on a natural history short, which has been turning me into a recluse for months now. Recording foley today, great laugh. Should be online in january with a bit of luck.

I haven't tried to use the ML intervalometer like this but I've never known it to drop a frame, even with ettr and deflicker running. I have had some crashes but I think they were down to the deflicker module.

I find it hard to imagine an external device doing as good a job as ettr. I trust it more than any other auto exposure system I've used. But it does come with a time premium. Great for day to nights, tides and shadows. Not so good for people, animals, or weather! I guess you're stuck out in the rain, getting numb fingers.

AETTR is probably too slow for most of what Jim does. I've posted a test aettr/weather shot before, and it manages the exposure extremely well. But the results are a bit quick and do stutter due to shifting intervals. With manual exposure adjustment though you could avoid this, and with no aettr or deflicker processing time wouldn't be an issue.

Be interested to know if it works for you Jim? And how's that lazy susan working out?

PS. Jim, this is Andy from Light and Time.

If Bridge gives me bad data for some or another reason then that function isn't there and you get the 'resize is undefined' message.

Yeah, this seems to be what's happening. I think it may be caused by something outside Bridge. Or at least it seems to happen less if Bridge is the only application running. I'm also seeing problems like below (sometimes), where certain frames are processed very differently from those around them in one iteration, the following iteration will then try to correct them. This was after 3 iterations of the script. They weren't there after two iterations and the fourth started correcting them. This may have started happening after a 'resize undefined' problem, not sure.

Getting below about 10s and you can start running into the occasional 'dropped' xmp file, if for some reason the CPU was a little busier.

I was shooting every 12 secs with 6 sec max exposure, but some of the frames with dropped xmps are short exposures, so did have over 10 secs processing time. I still have an old build (21st July 2013) that has served me well for ETTR. With this I can reliably shoot with the intervalometer set to 8 secs and the max exposure set to 4 secs.

@dmilligan
I've been trying your script and having a few problems. My first test worked pretty well but I thought not quite as well as the original in-camera deflicker. But I'd processed the shot with default ACR setting, where as the in-camera deflickered version I was comparing it to had been tweaked. So I tried to synchronise the ACR settings and re-run the script, at which point things started to go wrong and I've not had any joy since. I've been trying to do too much at once so I really don't know if the script or my system is the problem. I've never used Bridge before, which doesn't help. I've been trying to get my head around it but I'm really not in a position to make a coherent fault report at the moment, except that it often seems to freeze and when I try to quit Bridge I get an error message saying 'resize is undefined'. Sorry for the non report report. I'll persevere if I get the chance and post more coherently if I can.

I've been trying the latest builds for ETTR timelapse on a 5D2. I've not been getting the crashes I was before and ETTR seems to be functioning really well, but I'm still having problems with deflicker. In the shot below about 20 frames, distributed seemingly randomly through the sequence, did not have xmp files associated with them. And there was three sections where the brightness jumped 0.38 stops for about 150 frames, before jumping down again. Looking at the back of the camera during the shot, global draw did not seem to be working properly. It had been at the beginning but by half way through the image and intervalometer info was displaying correctly but no histogram or zebras, instead some text that looked like code. I've forgotten what it said I'm afraid, should of written it down. Despite this ETTR clearly functioned fine.

In crop mode I'm still seeing much better performance from raw_rec than mlv_rec. Is this to be expected?

2144x917@25fps gets me around 20secs in mlv, as opposed to over a minute in raw. 5D2, Sandisk 1067x, 29-03-14 build, no mlv_snd.

Edit: Was looking at the 25P chart, didn't notice the crop mode figures above. Sorry.

Thanks OObner.

Very nice.

Begun as a kit test, to see how our rag tag bunch of cameras, lenses and filters would grade up together, it turned into a little film about the extreme high tides we've been getting of late in the uk. There's timelapse shots from a Nikon D800, a D2X and a Canon 5D mkII, as well as video from a Red Epic MX and Magic Lantern Raw (crop mode 2K) shot on the 5D2 (a.d.s builds).

The Dee estuary is quite a challenging environment for imaging kit. It's high contrast, subtle colour, and lots of fine detail. We think the footage has all matched up pretty well..? Incredible how good the ML raw looks next to the Red footage. Yes, some of it is noticeably less detailed and smooth than the Red, downscaled to HD. But most of it isn't. Most of it matches up so well I'd challenge even the most dedicated pixel peeper to pick the difference. And the 5D3 can get 2.5K. I can see this sitting happily next to any Red/Arri footage, and probably F5/55 too, when printing to HD/2K anyway.

If dmilligan Bridge script does it all, can we do away with xmp deflicker and just use ETTR?

My understanding was that the in-camera deflicker uses the linear raw data to do calculations, where as the the script uses linearised data from the jpeg previews. Thus the in-camera deflicker is more accurate. I may have misunderstood this though..?

Some stuff shot in crop mode. I really like the gritty look the footage has, be great for a music video or something. Bit of a beast to use though.

Nice one.

Like I say, I'll get working on a version thats less picky.

Try the tweak below and let me know. It's a guess but might work. Think there may also be problems if your xmp files have .xmp as extension rather that .XMP. Not sure how to stop it being case sensitive.

I'll try and make a more robust version that handles errors a bit better, and possibly add an optional third argument to ramp other parameters other than Exposure2012. But I'm learning as I go along so it wont happen quickly.

Code Select Expand

#!/bin/sh
# Script to ramp XMP exposure values
# exramp [total ramp] [path/to/sequence]

ramp=$1
path=$2
cd "$path"
seq_total=$(ls -1 "$path"/*.XMP| wc -l)
steps=$(expr $seq_total - 1)
inc=$(echo "scale=6; $ramp / $steps" | bc)

echo "The path to the sequence is $path"
echo "The total number of .xmp files to process is $seq_total"
echo "The total ramp will be $ramp"
echo "The increment per file will be $inc"

n=0
gain=$(echo "scale=6; 0 - $inc" | bc)

while [ $n -lt $seq_total ]
do
n=$(expr $n + 1)
gain=$(echo "scale=6; $gain + $inc" | bc)
xmp_file=$(ls -1 "$path"/*.XMP | sed -n "$n"p)
echo ""
echo "Processing frame $n: $xmp_file"
echo "The gain to be added is $gain"
exiftool -Exposure2012+="$gain" "$xmp_file"
done


I'm on Mac OS 10.8.5. Works for me but I'm no programer. I didn't have the script in the same folder as the files but don't know why that would break it.

You need to tell it the path to the folder full of cr2+xmp. For example, if the script is on your desktop, as is a folder called ETTRSequence, and you want to ramp it up by 1.2 stops:

~/Desktop/exramp 1.2 ~/Desktop/ETTRSequence

If this doesn't throw it, I don't know what will? The exposure changes and contrast in this shot are pretty extreme. And it copes beautifully. This really is an amazing tool for timelapse.

I'm still having problems with stability. And it's not predictable, at least not to my un-scientific brain. It seems to crash more often with quicker intervals, longer max exposures, but it can happen with any settings. The last exposure seems always to be lacking an XMP file, and is often (perhaps always) a different exposure than the previous frame.

Sorry I can't give better info but I really hope you can find the fault. I'm gonna switch back to an older build for the moment, 21st July seems stable on the 5D2.

The exposure in the above shot was ramped up by one stop in post, using a slightly modified version of the shell script above. Seems to work quite well. If you just need to do simple ramping then this is a cost effective (free) way. Download the script here:- http://www.lightandtime.co.uk/downloads/exramp.zip

Nice one glubber. Great idea. Not being a fan of Excel I've pinched your idea and tried to put it into a shell script. Seems to work in brief tests but I aint used it in anger yet.

Code Select Expand

#!/bin/sh
# Script to ramp XMP exposure values
# expramp [total ramp] [path/to/sequence]

ramp=$1
path=$2
cd $path
seq_total=$(ls -1 *.XMP| wc -l)
steps=$(expr $seq_total - 1)
inc=$(echo "scale=8; $ramp / $steps" | bc)

n=0
gain=$(echo "scale=8; 0 - $inc" | bc)

while [ $n -lt $seq_total ]
do
n=$(expr $n + 1)
gain=$(echo "scale=8; $gain + $inc" | bc)
xmp_file=$(ls -1 *.XMP | sed -n "$n"p)
echo ""
echo "Processing frame $n: $xmp_file"
echo "The gain to be added is $gain"
exiftool -Exposure2012+="$gain" "$xmp_file"
done

So expramp -1.2 ~/Desktop/ETTR_Sequence should ramp ETTR_Sequence down by a total of 1.2 stops. The numbers it produces look right but I haven't actually watched a sequence processed with it yet.

I've been trying to pin down the crashes mentioned above but I aint got that far yet. Now on the 21st August build. It seems all is well at 10 sec intervals, 2 sec or 4 sec max shutter. At 5 sec intervals with a 2 sec max shutter it will reliably crash, but not predictably. I've had it shoot for a while at 2 sec exposure and then crash after the exposure has dropped to 1.3. But it will crash sooner or later. With these settings I've never managed more than about 50 shots. I am forcing fairly rapid exposure changes on it, but then I'm doing the same at 10/4.

The crash seems to be directly after the frame is taken, before any lcd action or beeb. On one occasion I thought I saw it change exposure settings essentially as it crashed, but this has never happened again and I might have imagined it. If I find out anything else out I'll post.

Deflicker on the computer sounds good, if time consuming. Would it speed the shooting cycle up much?

Oops. big plate of humble pie for me. This is not working how I thought it was, how i was told it would, and I'd not checked it properly divy that I am. Thanks for the warning, very timely as it happens.

I usually use essentially this workflow but exporting to DNxHD, which did seem to work. I could pull real data back into highlits or shadows in Resolve. The DPXs definitly don't work like this though. Is there a way to get a proper broadcast levels signal into a DPX from AE, or am I flogging a dead horse?

Canon raw files can contain upto 11 stops, and with some cross channel highlight reconstruction you may get a little more. In my experience a default conversion via ARC to a standard RGB space will clip some of this. And likewise if you grade for output in ARC you are likely to clip some data. But then I much prefer to do this rather than do a low contrast conversion at this point. This makes sense for us as our stuff often goes straight off for stock from AE.

With default settings ACR puts quite a bit of data in the super black/super white portion of the signal, or if a non extended space is used for output, it clips this data.

And when I say we grade by eye in AE, I really mean in ACR.

If I use the full range space then whites/blacks are clipped in the DPX. If I use 16-235 then super whites are retained, if they were present in the raw file.

And I don't see where we're going back and forward? We go from the sensor space straight to rec709 16-235, and stay there. Setting Cineon to full range means it passes the working space unchanged. So our DPX has rec709 colours and gamma with black at 64 and white at 960.

We use Rec709 (16-235) as our AE working space, then export to DPX with output space set to working space and Cineon options set to full range. This way we can grade by eye in AE, open the files in Resolve (video levels 64-960) with the AE look maintained, but still have enough latitude to make considerable adjustments in Resolve if needs be (super whites and super blacks present in the raw are maintained in the DPX even though they may be clipped by the AE grade).

I don't know if this is the proper way to work with DPXs or with broadcast levels, but it works for us. And we've also submitted these files to broadcast clients and our stock library with no reported problems (though these were timelapse sequences shot cr2 rather than ML raw).

I'm not sure where in the cycle the crash happened. When I came to the camera the rear screen was blank. Trash, play and menu buttons did nothing. The top lcd was as if the camera was metering, number of shots left (999) was flashing, cf light was off, not sure about blue led. Turning off the power cleared most of the display but left the meter and the 999 displays flashing, so I pulled out the battery.

The second crash was at 1.6 secs, with the 10 sec interval (2 sec max shutter), after several missed .xmps. As I say, I've shot with these settings for hours before, with no skipped frames and no flicker.

I was using a fairly slow card, a 64GB ProSpec 420x. The same card I've used before and freshly formatted. Part-twisted EF lens (@f/11 with nd0.9 and nd0.6 grad), full battery. ETTR set to always on with the 2 sec max shutter but all other settings default. Globaldraw on with raw histogram and zebras. 2 sec preview. Deflicker set to .xmp but otherwise default.

Anything else?