Messages

Which quality mic can you recommend?

PM'ed

I wonder if there could be a reason for recording without sound? So why not implementing it as always on...?

If I'm recording second system, I'll turn sound off to save space and processing. If no quality mic is plugged in the camera I know I won't use that audio.

If I can summarize your preference, you'd like to have HDMI overlays fixed and rec status in the top bar. You'd want status in the picture only if it was required for higher FPS, or if HDMI overlays are not fixed.

When you say framing do you mean bitmap cropmarks? Do you use/need the top/bottom info bars?

I personally have shot raw on a lesser camera, the 650D, and that's actually where I got used to relying upon the bit-rate and idle time, because you're really threading a needle when trying to record continuous raw 720p@24fps on that camera

Do you turn off Global Draw when you do that?

GD OFF turning LVINFO off seems like a blunt instrument. I can understand how zebras, wfm, etc would necessarily be taxing. But the MLV rec indicator is more chatty than LVINFO, so it's counterintuitive to me that LVINFO should break the camel's back. Maybe there's an architectural solution.

I like the comfort level bit-rate and idle time give me while I'm shooting, but as long as status is green, everything is Ok, so like you say, less important than remaining time/space (turn on for debuging would be good though).

I would suggest something like Canon does, namely display an indicator only if buffering is problematic. You may have never seen it because you should not (unless you have a slow card). Splattering text would be good enough I think, because it is abnormal operation and should be noticeable and explicit.

"Slow card: maximum speed reached"      (say, 0.5% idle time)
"Slow card: <n> frames dropped"

Do people really need/want to do that? I can't imagine shooting RAW video without exposure etc info on screen.

TLDR:

- remove "None" MLV record status mode
- remove "Icon" MLV status mode and display clip time and time remaining in LVINFO (design TBD)
- put all internal info to "Debug" mode, and make it an independent toggle that splatters LV as today

~~~~~~~~~~

Currently MLVREC "Icon" mode displays an icon and three lines of text to indicate status. I think two of the lines are not useful in practice - bitrate and idle time. Also, the icon and text are drawn over the video image, encroaching on composition space. LVINFO is designed for status information.

ref: http://www.magiclantern.fm/forum/index.php?topic=8539.msg80890

The "None" status mode is worthless. Correct my if I'm wrong, but I can't imagine anyone wanting their camera recording with no indication of the fact.

This suggestion is to simplify display by removing unnecessary information in the normal case, and moving it out of the way. It also add the important "time remaining" feature, which is hopefully possible.

Finally it simplifies the menu by removing any options besides "Debug" which is for developers/troubleshooting.

Running out of storage during an important take is a real bummer. It would be great if, in addition to current clip length, the estimated time remaining on the current card was displayed. This could be based on a short moving average record bit rate in RAW/MLV, and storage space left on the card since the clip started, worst case.

Currently the space shown remaining on my CF card does not update unless I power cycle my 5D3. It would be great if this was updated more frequently. Recording RAW eats space fast, and power cycling is not convenient in that situation.

I agree with one module and a sound switch/submenu. For my purposes it would be simplest. I assume the sound module portion is not likely to be replaced, nor is it so big that unloading it is compelling.

+1 to enabling mlv sound by default. You'll never kick yourself for accidentally recording sound, only for forgetting it.

I tried forcing 480p and had some issues:

- I noticed that playing picture/video looked very different on my SmallHD in photo versus movie modes. So I captured both (photo first).
- I captured movie standby and record for all three movie formats, but only folders were created, no dump files.

http://popspring.com/mldrop/VRAM_stevefal_5D3_113_480p.zip

Here's a set from 5D3_113. I used three different HDMI monitors, including two with 1280x720 native displays. But all three are coming up as 1080p, so I don't know how to generate the 480p HDMI case. It goes pretty fast once you get the hang of it:

http://popspring.com/mldrop/VRAM_stevefal_5D3_113.zip

[edit] Ah, I missed the instruction about 480p. Will try.

What's required for the SD cases? I never use composite video out. I assume a cable needs to be plugged in, but does it need to actually go somewhere? Or just a 75 ohm load?

[edit] Apparently plugging in the silly SD cable disables the internal LCD, so I guess a composite monitor is required unless the cable is plugged in after triggering the dump. I'll do that for the PAL case at least, since I don't have a PAL monitor.

video_mode_crop (H.264) does not apply to 5D3, correct?  If so I count 12x5 or 60 modes for 5D3.

I still use ACR for the first technical correction, because it has so many high quality features. I just keep away from too much of the fancy exposure controls. I use it for:

- white balance
- exposure
- some highlight/shadow
- lens correction
- noise reduction
- sharpening
- chromatic aberration correction (for specular highlights)
- gradient corrections

The last one is possibly overlooked by people. With ACR you can draw gradients over the image that contain exposure and other corrective variations from the main controls. For instance, if you have a hot light on the side of an image, you can bring its exposure down while leaving the other side of the image untouched. For me, this is a good alternative to aggressive highlight control. Check it out.

I then render in AE to ProRes4444 at 16 bits. These files are much smaller than the CDNG, but still very gradeable.

There is no flicker or artifacts in After Effects ACR because it is treating it as video...

This is not right. AE/ACR CC still flickers: http://www.magiclantern.fm/forum/index.php?topic=5710.100

I guess I'm seeing something else. I don't think it looks like dual-ISO aliased edges. I  see a kind of rolling moire along the upper face of the frame. Is there perhaps a line or grid pattern on that metal material?

As I look again, I don't really see how this could be related to the exposure issue. The artifact moves just like moire, but I don't see the pattern causing it. It's like to shooting though a screen.

I've done pretty exhaustive testing with custom test images to try and get to the bottom of ACR's non-linear behaviors relative to highlight recovery and other exposure controls. These are the behaviors that causes flickering in video when the balance of bright and dark objects changes from frame to frame. I measured Process 2012, 2010, and 2003. Process 2012 offers the most aggressive controls but all of them will cause flickering due to some kind of image-dependent tweaking of curves or maybe microcontrast processing.

I've never seen the kind of aliasing you got on and below that horizontal window frame, but it might be an artifact of the exposure processing at extremes, and the geometry and lighting of that particular object. I don't see similar aliasing anywhere else in the clip.

Focusing only on Process 2012, the following exposure controls will cause non-linear changes and hence flickering:

Exposure +/- OK
Contrast +/- NOT OK
Highlights +/- NOT OK
Shadows +/- NOT OK
Whites + NOT OK (minor)
Whites - OK
Blacks +/-  OK
Clarity +  NOT OK
Clarity - OK

Processes 2010 and 2003 behave similarly, but with less dramatic flickering (due to less aggressive effects), and some differences from the latest. I can post those results if anyone is interested.

If a semaphone namespace is flat and 1:1 per module, that's not rich enough to capture the potential conflicts. A module could create conflicts not envisioned by the original developer and therefore not be accounted for by the semaphore. Or, if the original developer realizes the multiple potential conflicts and overloads his semaphore, it will be unique and might as well just be the module name – so developers will just have to know which modules conflict with their own.

Probably a list of semaphores would be needed, if at all. And then the module name should by default be the first one:

"MyModule", "UsesAudio", "RawRecording", "UsesShutterButton",  "HasAStateThatPreventsAnyNumberOfOtherOperations", "OnlyGodKnows"

Describing dependencies within an open platform is hard. At very least, the most common dependency classes would need to be designed centrally and documented carefully in order to be useful and not generate false positives. Slippery slope problem.

I just tested this and AE/ACR CC flickers exactly the same way as CS6. I see no evidence that settings are locked.

I'm beginning to think that the ACR highlight control performs microcontrast adjustments, which, if true, may make flickering inevitable, and the idea of "locking" a fallacy.

[http://forums.adobe.com/message/6334477#6334477]

I posted a feature request/bug at Adobe and started a discussion on their forum. Chime in for visibility:  http://forums.adobe.com/message/6334477#6334477

~~~~~~

Discussed at http://www.magiclantern.fm/forum/index.php?topic=5710.0

People using ACR to import video image sequences into After Effects have discovered that ACR's highlight recovery and other exposure controls produce varied exposures depending on the content of each frame.

The result is "flickering" in the rendered video when the scene changes such as when light or dark objects come into view.

Users have experimented with Process 2010 and Process 2003, but they all exhibit the same problem to some degree.

The problem makes ACR unusable for some video shots where it would otherwise be a great solution due to its superior highlight recovery.

I discovered this issue when reviewing my footage rendered from After Effects. Any with significantly bright or dark objects coming into frame changed the exposure of the rest of the frame, irreparably.

SUGGESTION
The suggestion is to offer an "Exposure Lock" feature in Adobe Camera RAW, which would lock the absolute exposure values determined via the prototype frame (typically the first frame), and use those for every frame of video rendered. This means that exposure computations performed based on the content of each frame would be disabled during rendering. The computations would be performed only when the user interacts with the exposure controls via the ACR UI.

The benefit of this feature is that ACR could be legitimately used to initially process high quality RAW video. A side benefit is any situation, including still photography, where the user needs to match absolute exposure settings between shots.

I hope Adobe will consider adding this feature or something equivalent that provides, for video, ACR's unsurpassed ability to tame highlights.

edit: I think I've just created a regression, bug #1 in stevefal's sample.
edit2: fixed and reuploaded.

I haven't been able to get cr2hdr-20bit.exe working yet. I use cr2hdr for OSX.

In either case, I want to point out that the aliasing I saw in #1 of my sample became prominent after I lifted the shadows. So I'm not sure how the fix looks under the same circumstances.