Messages

on 50D i'm seeing the Canon full color screen when in ML Grayscale until i hit record then it switches to grayscale.
(recent unified build)
Movie -> Raw Video -> Preview ->ML Grayscale
is this a bug? is this happening on the tragic builds from 1%?
also, the 50D ML grayscale is beautifully detailed in comparison to ML grayscale on 5D3.

note: for those PM'ing me about pink frames - you should not get pink frames in any recent build.
when the white point  (set in the exif) of the DNG is above the actual white level you will see a pink frame.
these bugs were fixed weeks ago.
do not be fooled by pink preview images.
if you have a DNG from a recent build which is pink when viewed in gimp or a commercial tool then that is a bug.
post the DNG image and build info to the forum.

@ultramaze thanks for the video - like the hand held vérité shots in the car - parthenon is not a bad place for a picnic.

PS. If it helps, the resolution that clip was recorded at was 2240x954, but it also happened at 2560x1090.
Does the 5d3 not have that wide of an area on the sensor? Could that be it?

hi @aaphotog
in this example,
it happened at:
2880x1320
2560x1320
2240x1260

5D3 has crop mode maximum horizontal resolution of 3584 (based on LiveView) - so something may be off in the frame position or frame grab in crop mode at higher resolutions - moving around the focus box could affect this -so when i can test and report issue more precisely i'll do so.

Didn't change anything lately.

Maybe it depends on focus box position?

OK - will try different focus box positions- still haven't used digital dolly - so i thought i'd take a large image and pan in post.

had been demoing raw video for some LA cinematographers who were very impressed with both 50D and 5D3.
they were running 2 5D3's in time lapse for this shot and wanted to know more about 2K - so that's why i'm trying it out.
raw->cinemadng(via rawmagic)->gimp (ufraw) -> jpg (no processing)

5D3 (unified.80e3ca539891) shooting greater that 2k produces frames with black right borders
2880x1320 ends up more like 2770x1320
if this is not a known issue and anyone would like DNGs of any flavor, left me know.

thanks for the info.
5D3 when in ML Grayscale
half shutter press is showing the Canon info display (at bottom exposure iso setting) - not disabling the the Grayscale

btw - tried the auto-ettr and flicker free sidecars for a timelapse and it worked very well.
you have a real achievement in camera software design with these features.
https://vimeo.com/69576183
waiting for clear skies at night this is a test dawn sequence where i adjusted the focus, framing and aperture.
(wanted to try workflow and evaluate location)

using same 3ecd254bdba1 (a1ex last commit) hudson/unified code
https://bitbucket.org/hudson/magic-lantern/commits/3ecd254bdba1907110eb72a98b2b9aeb2785a3a5
on 50D and 5D3 -
how come ML Grayscale looks so much better on the 50D ?
on 5D3 ML Grayscale is blocky and pixelated (so bad i am forced to go to 10x to focus).
on 50D, the display is Canon color until record then a smooth grayscale image.

also, couldn't get digital dolly to work on either camera with it enabled. strangely joystick could pan albeit jerky when digital dolly was disabled. perhaps i am missing a setting.

by the way, much of this guide is relevant to OSX.
so your detailed description of working within the virtualbox are completely applicable.
the virtualbox is the easiest way to have all the required build tools available.

https://bitbucket.org/GregoryOfManhattan/magic-lantern/downloads/magiclantern-2013Jun28.50D.109.go.unified.3ecd254bdba1.zip
new "Warm up" the card option for raw record to potentially help the speed of the first recording.

Note: last build from me for a while - i will have limited internet for a couple of weeks.

@akumiszcza thank you for your continued detailed bug reports - how did it work with a card format?

@araucaria are you saying that spanning at 4GB is not working for you.

@1% failing read test in LV is not a good sign is it?

starting the Card Benchmark while in LV gets substantially slower results for me.

turning on camera and running benchmark got these results



turning on camera, turning on LV and then running benchmarks got the following

[Update 26 June 2013]

1%'s hacks for variable buffering are now in part included in the hudson/unified branch and builds.

is the "estimation of how many frames you are going to get" using the latest raw_rec.mo module with the Small Hacks enabled accurate?

Update 26 June 2013 - there is a new "Small Hacks" feature in the raw_rec module.  in the Raw Rec Detail Menu enable Small Hacks. This is the first 50D hudson/unified build to hit 81MB/s.
a1ex is looking for feedback on the accuracy of the reported speed and frames - please report details if you have them.

@flambe - yes that's the maximum in regular video mode
@araucaria - these "Small Hacks" should bring up the speed on the 5D2 as well
@albert-e - be happy that the canon engineers built a sensor and datapipline capable of these speeds (greater than the red one)
@goldenchild9to5 and @2FAST - feel free to discuss on vimeo - bmcc, pump up the gamma, offset negative red, - a little too yellow and i need to learn to keep the full dynamic range with the detail in the tree bark.  been watching excalibur (1981) and loving green.
@goldenchild9to5 yes shoot it

https://bitbucket.org/GregoryOfManhattan/magic-lantern/downloads/magiclantern-2013Jun27.50D.109.go.unified.b77a85f7ac68.zip
integrates some of 1% hacks.
runs at 70MB/s without.
enabling "Small Hacks" results in 80MB/s
had 2 shots at 1920x1080p24 go over 1000 frames.

btw - m00000.raw is no filenaming-convention anymore - with the newer versions of rec_raw its written
mXX-YYYY.raw - f.e. M35-6148.raw

the naming convention for raw files currently is:
M for magic lantern
dd for 2 digit day of the month
hhmm for 2 digit hour and 2 digit minute when recording began.
(the last two digits get incremented if you've already recorded videos in the same minute up to 99 (if anyone could click that fast))
so every file name is unique.

so your example would never be generated by magic lantern.
M01-M31 first part range
0000 - 2399 second part range (though seldom will there be values greater than 2359)

it may be helpful to preserve these dates and times in yours and other post-processing tools.
(i was looking at this in case there was a need to insert a timecode into the cinemaDNG exif data)

tried that latest hudson/unied build with today's removal of pink frame code.
if you have had pink frames in crop/zoom mode you may want to try it as a.d. has confirmed this is an improvement on the 5D2

at 23.976 frames per second
getting continuous recording at:
1584x1058
1920x872
1920x1080 got 221 frames in a single test.
at 25 fps 1584x1058 got 1835 frames in a single test (for the 50hz anamorphic users).

reformatting these FAT32 cards periodically is a very good idea, for anyone who is experiencing speed challenges.
tried this setting a 64k block size with perhaps better results
1920x1080 got 227 frames in a single test
at 25fps 1584x1058 got 2400 frames and then 3400 frames.

did get into some state where the canon info menus re-appeared - power cycle seemed to cure it.

unified build seem to be fine with real speeds near 70MB/s.

new build with a1ex fix for pink frames in crop modes
https://bitbucket.org/GregoryOfManhattan/magic-lantern/downloads/magiclantern-2013Jun26.50D.109.go.unified.ac1db39643b3.zip

numbers may change but the frames remain the same.
today's builds include code changes to bitrate calculations - so the numbers may display differently than before.
you can compare performance with past builds by maximum frames under some settings (1920x1080 @23.976) or maximum continuous recording at your favorite aspect ratio.

in the last couple of days a1ex modified the code in hudson/unified branch which reports the speed (bitrate) so numerical comparisons with past and other builds may not be accurate.
there has been a single change (commit) since i posted the unified build yesterday - a "fix typo" where speed in one place is shown 10x greater than actual. no functional differences.

hi @chmee and @peoplemerge
here is some additional information - hope it helps.

round trip with the blackmagic demo clips does work without the Reel No. (so there must be some additional information in the metadata for the cinemadngs)
i tried this with  fcpx 10.0.8 and premiere cs6 (sorry that 5.5 didn't work for you chmee).

so using shot1 - shot 5 cinemaDNGs from video.blackmagicdesign.com, i started a project in davinci resolve 9.1.4

first screen shot shows the media pool with NO Reel No.



the second screen shot shows the round trip imported clips from fcpx.  you can also see that the media pool begins with the black  frame clip so the Master Timeline would be in that order. the order in the confrom window matches my edit in fcpx.


the third screen shot shows the round trip  imported clips from premiere cs6


link to fcpx round trip file
http://50.56.67.113/ml-25june13/bmcc-shots.fcpxml

link to premier roundtrip file
http://50.56.67.113//ml-25june13/bmcc-shot-roundtrippup.xml

i did try to use the Assist Using Reel names after i'd renamed the files to what i thought was the black magic camera convention - and it didn't work for me. though when i did this i thought the reel names from bmcc were all C000xx - wonder if they need to be an actual number without the C for resolve.

In the new build I see speeds required 10x as they should be - 270 MB/s instead of 27 for instance.

good eyes to catch this.
a1ex fixed it - the code for calculating the speed has been changed and may be more accurate now.

numbers may change but the frames remain the same.
today's builds include code changes to bitrate calculations - so the numbers may display differently than before.
you can compare performance with past builds by maximum frames under some settings (1920x1080 @23.976) or maximum continuous recording at your favorite aspect ratio.
(for the super speed builds, it's looked to me as if the numbers on screen were less than the required bitrate - e.g. 1920x1080p23.976 should be closer to 83MB/s and the 80point1 build reported around 80.1)

@Rawolution - enjoy 1600 maximum width in regular raw video mode - that is it.

@pinger007, @rommex (and the whole moire gang) - i wouldn't go so far as to say unusable - you have to decide where to use it.  it will present issues in environments with regular patterns and hard thin lines.  for myself, i did some camera tests to see a range of conditions.

included a not great panning city scape to show the moire.
at 25second far left top corner the windows have a crazy multicolor pattern,
the rooftops to the left of the Allianz building show some strange flickering digital artifacts which i think is caused by antennas.
the side of the dark brick building center frame at 35second has very visible moire.
in resolve lite, i tried to separate luma and chroma and to blur the chroma to reduce at least the rainbow portions of the moire pattern.  all these things look worse at full resolution viewing the cinemaDNGs - the silver lining in all the compression to post videos online is that the apparent problems are reduced.

the earlier shots of the trees could have been processed (perhaps by masking the backs of the trees or could i have keyed on the tree bark color?) to keep the dark detail in a very wide dynamic range shot.
(note: uploaded a 444 prores with vimeo compression and somewhere - this vimeo gamma is much darker from what i saw on screen - at my limit for the week of uploads - so cannot be replaced)

looks to me like the 50D image can be sharpened and look very nice on organic natural shots - trees, forest , ocean, etc...
a deep focus city shot is going to require post work to reduce the moire.
basically you need to limit depth of field in a city or room with patterns.

the final shot show crop/ zoom mode at 105mm looking at one world trade center (4.2miles / 6.7km ) and 1 penn plaza (1.3 miles / 2.3 km) distance.

@rommex - you may like a documentary film "crumb" (1994) - it shows an artistic interpretation of telephone and power cables. 

new hudson unified build posted
https://bitbucket.org/GregoryOfManhattan/magic-lantern/downloads/magiclantern-2013Jun25.50D.109.go.unified.282abfa87fef.zip
quick test shows modules load and recording raw work.

@KENNEDYR21 - sorry about that - module building changed 5 days ago and i mis-adjusted my build script.
it should be fine now and going forward.

these builds should track both the main magic lantern in hudson/unified and in the modules as well.

hi 1%,
not my own repo - i thought it useful to have a 50D build which tracks exactly what is on hudson unified
so any builds i have called "unified" are from https://bitbucket.org/hudson/magic-lantern/src

towards that end, could you please let a1ex know what you currently are using for skip_left in src/raw.c
https://bitbucket.org/hudson/magic-lantern/pull-request/130/undoing-the-damage/diff

is it useful to continue to have builds that track the main unified?

https://bitbucket.org/GregoryOfManhattan/magic-lantern/downloads/magiclantern-2013Jun23.50D.109.go.unified.6685347055ba.zip
this is the latest unifeid build - but it will have black margins -
waiting for an
hg backout 5ddc160
to be merged back into the unified branch.

black point disease is not always cured by blood letting the skip values - applying leeches can make things worse and actually spread bad blacks to other areas.

Andy600 - i am metaphorically trying to say that the black point issue in your zoom mode images has nothing to do with the skip values. changing those values can make things worse in other modes.
looks like the important thing you have highlighted is that the zoom mode video images are different from zoom mode silent pictures images.
a1ex and 1% should be able to sort that out as it may explain what is going on for other cameras - the 5D2 bounced its skip values around this week as well and there are ongoing problems with pink frames and so forth.

the correct value for skip left based on silent picture DNGs (which is the procedure a1ex said to use) is:

Code Select Expand

skip_left = zoom ? 64 : 74;
for zoom mode video - the skip value of 0 would seem to apply, if having a too large skip_left value in zoom video mode causes the black point issue then that needs to be addressed.

hey Andy600, how are you fixing black point errors in Resolve?
for stills, there are many ways - like the free gimp (see screenshot below with your DNG)
lift doesn't do the same thing as shifting the black point does - so if you have any Resolve tips for adjusting this, let me know.

black point disease is not always cured by blood letting the skip values - applying leeches can make things worse and actually spread bad blacks to other areas.

@a1ex - do not know if h.264 enable or not makes a difference.

@1% - values i provided are correct.

@akumiszcza - thank you for details - i am getting glitchy frames (silent pics) from both of yesterday's builds though i haven't had a crash myself yet. recommend you use an earlier vintage build for practical shooting.

@Andy600 -  you can be sure about the build and code sync by looking in the magic.cfg - it tells you what build is on which card - should always have the commit id.  same information is at the bottom of the info screen.
that build id should match one of the commit id's on https://bitbucket.org/hudson/magic-lantern/commits/branch/unified
so 9f26e15d9146 in the bug report from @akumiszcza matches commit 9f26e15
https://bitbucket.org/hudson/magic-lantern/commits/9f26e15d91464033c14d1633bf31cd13c0b100a3?at=unified

posted a build with the latest code in unified branch
https://bitbucket.org/GregoryOfManhattan/magic-lantern/downloads/mlmod-2013Jun21.50D.109.go.unified.7b79e51d4d06.zip

this code will result in black borders for
regular silent pictures 74 pixels,
zoom mode silent pictures 64 pixels, and
regular mode video 74 pixels
zoom mode video will be OK.

you can see this in the image below or try it for yourself with the build.


looks like the procedure that we used on june 5th was incorrect insofar as it used the same value for zoom mode silent pictures and video - 64 pixels left offset. is there a conditional which could be used to distinguish zoom photo mode from zoom video mode? is so then it could be added to the code, though at the time, i didn't see any degradation to the zoom mode video image from the extra skip left.

Code Select Expand


skip_left   =  zoom ? 64: 74;

if mv1080crop or something like it, is defined for 50D,

Code Select Expand


skip_left   = mv1080crop ? 0 :  zoom ? 64: 74;


please note there are multiple builds being used along with creative users who combine an autexec.bin from here with a 50D_109.sym from there and perhaps a raw_rec.mo from over yonder - so its easy to confuse reported results.