Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - TequilaKez

Pages: 1 [2] 3
Chiming in to add/confirm reports on 550D every 2nd frame is a copy of the last frame, except the top 3rd which looks like current frame, only shifted on X axis.

If I can contribute to testing in anyway, gimme a job! 550D is 'B' cam, but love to get more than a couple of seconds of Raw at full res.

Raw Video Postprocessing / Re: New Mac app for MLV (Alpha 1)
« on: March 10, 2017, 02:37:04 AM »
Great app, I'll be looking forward to trying it out when OpenGL is implemented.

Some suggestions for making this app killer for fast workflows.... if I may, ahem.

-Left pane browser (instead of '+') with folder favourites. See DaVinci Resolve for good example.
-Some way to tag MLV files. Using the standard Apple Finder tag meta would be great so it would reflect in Finder. Just the color tags would do.
-Comment files using the standard Finder comment meta.
-Delete MLV files from the app.
-Quickview plugin. I've experimented with this before, and looks like best we could hope for (since 10.6) would be a single frame preview. But when logging and organising 100s of MLVs, even a single poster frame preview would be a godsend. Seeing as you are using AVFoundation already, this should be perry easy.

Nonsense, your post is what is a joke. MLVFS is extremely fast, and myself (and countless others) get real-time speed. If you are having issues, where is your bug report?

Well in my experience with Resolve, I could get very close to realtime playback from DNGs exported to a real (non SSD) drive. When I tried this with the same DNGs directly from the MLVFS virtual drive, I could get only barely a few fps which wasn't usable for me
I did not put this down to a bug, but rather assumed there must be too much extra overhead from the virtual file system converting between MLV and cDNG 'on the fly'.

I havne't got MacFuse installed right now so I can't retest, but if you are saying that no body else notices any different in speed between real and virtual files, I'm open to it being a specific issue with my system.

The only thing I can think of is that, running on a 1G Radeon HD6870 didn't give enough hardware acceleration for Resolve so was maxing out CPU.
In that case maybe the added CPU overhead of the 'on the fly' conversion was just too much.

In my experience...

-Fast / Stable / Crossplatform . Great for quickly going through a card full of MLVs as you can preview and export only what you need very easily.
-It's mostly keyboard controlled though which can be annoying if you forget the keys.

-More thorough options for things like Dual ISO and be-banding
-Great idea in theory using a virtual file system, but using it in this way is painfully slow. Forget working in Resolve like this. You'll have to drag the DNGs to a real folder to get reasonable speed. If you're doing the AE/ACR method, you'l be used to a painfully slow conversion process anyway so you may not notice.

If you want a fast workflow while still keeping 14bit raw, you need to get the cDNGs to a real folder on a hard drive, preferable SSD.
You can either do this by just going through each shot in MLRawviwer and pressing 'E' to add to the export queue.
Or, using MLVFS and dragging the cDNGs from the virtual drive created by MacFuse to a real drive.
If you have Resolve configured for performance, they should lay in realtime without conversion.
DON'T attempt this using just MLVFS's virtual DNGs though, it's a joke.

I'd say, unless you have banding issues or are using Dual ISO, just export through MLRawViewer. It's a lot less steps to get cDNGs and no 3rd party software to install (MacFuse).

Modules Development / Re: Full-resolution silent pictures
« on: December 24, 2014, 08:41:32 PM »
@bookemdano. I've made a slider with an arduino and stepper that moves a specified amount, then fires the half shutter (operated via iPhone app). I'd been thinking recently that the same design would suit telecine very well. You just have to swap the AC motor for a stepper then fps and sync are non issues.

Hardware and Accessories / Re: Remote joystick
« on: December 12, 2014, 02:45:14 AM »
Theoretically, any function supported by EOS utility could be controlled over the USB port if you got busy with an Arduino or similar ( otherwise the only external inputs you have access to are half shutter and full shutter press via the remote cable, (+ face sensor and audio trigger) so the magic lantern features can only be controlled by those.

General Chat / Re: NEW H.265 CODEC
« on: December 11, 2014, 11:01:02 AM »
^what he said :)

General Chat / Re: NEW H.265 CODEC
« on: December 10, 2014, 03:09:16 AM »
I've just learned that h.265 AND h.264 can support 10bit color. Pretty annoying camera dev's aren't utilising it.

Raw Video / Re: qDslrDashboard on iPad
« on: December 02, 2014, 12:19:20 AM »
Doesn't work over USB, only wifi for cameras that have it (no video). Best at the moment is dslrcontroller for iOS as it's almost as fast as hdmi but it's for jailbroken devices only and it's purely a viewer, no controls yet. And it doesn't work with raw. Afaik raw disables this h.264 output stream as it doesn't work with the canon eos utility either. So someone would have to make a modded version of the mlv module (likely sacrificing data rate)

Raw Video / Re: ML .RAW plugin integration OS X
« on: November 28, 2014, 09:06:56 AM »
Considering the wide support for ARRIRAW, batch converting from MLV to ARRIRAW would certainly handy workflow solution though it's
hard to tell if it's open on the input side (encoding). Probably not as it would be counter productive.

Does MLV use any form of encoding? I wonder how different the data is besides headers and data structure. (ML module possible?)
Then u have native QT including thumbnails and quick look, native FCPX support, native Resolve support and plugins for pretty much everything else.

From the website:

Is ARRIRAW an open format?
We recently submitted the ARRIRAW format and header specifications to the SMPTE, requesting the initiation of a new Registered Disclosure Document (RDD). Once the document has been accepted, the SMPTE will publish the RDD on its periodic distribution media and on the SMPTE website. This will ensure that the format is open to anyone who wants to develop applications around it.

ARRI offers a software development kit (SDK) for ARRIRAW processing that software vendors can incorporate into their application. ARRI also supports vendors who wish to implement the ARRIRAW processing procedure on their own. Depending on the implementation, the following processing settings can be adjusted:

Exposure Index (ASA rating).
white balance.
tint (green-magenta shift).
current or legacy debayering mode.
output color space for HDTV, digital cinema (P3), ACES and Log C wide gamut.
different standard aspect ratios.
output resolution.
sharpening of the image output.

With the ARRIRAW SDK, you can also apply a custom ARRI Look File, which offers primary adjustments through printer lights, saturation and additionally lift/gamma/gain (or slope/offset/power).

No info on where to get such in SDK though. I imagine they expect direct contact from developers.

Raw Video / Re: ML .RAW plugin integration OS X
« on: November 27, 2014, 01:38:46 PM »
I would like to see a ArriRaw type file support which by the way FCPX has native support with Raw adjustments.

Looks like they made it pretty easy for Apple with an SDK and all. MLV would likely need the same though Apple's not likely to want be seen supporting it when you consider their stance on modding firmwares.

Raw Video / Re: ML .RAW plugin integration OS X
« on: November 21, 2014, 12:43:31 AM »
Eventually I hope we can get some sort of native support in fcpx  and davinci. MLVfS is a great idea but I can't preview in real time in davinci with it so I don't find it practical. Batching to cdng or proves with MLRV  is still works best for me.

I do really miss quick look though. I have my thumb permanently resting on he space bar when I'm working as I find instant preview integral to fast workflows when rummaging through files.

Here's a quick look plugin that already supports most of ffmpeg via vlckit so it just needs the mlv implementation in ffmpeg to mature and then our mlv icons will show snapshots. See here for the devs comments

No video unfortunately due to aforementioned avfoundation migration but there's chance it could work in a hacky way if we can work out how to find the memory address of the quick look window.

@TequilaKez If you press C, it will process all the MLV files in the same folder as the one you loaded.

Damn it, it was there! I looked it over a few times but i guess i was scanning for the word batch or something.
That's great.
Still, the droplet like functionality would be even better:)

Raw Video Postprocessing / Re: Editing and CC in ProRes
« on: October 29, 2014, 11:02:35 PM »
Well I'm hoping someone can chime in here swell as I'm not exactly sure what they all are!
Eventually Im hoping we'll be able to use visionLog etc which are specifically designed to get the most out of Canon sensors.
Until then, if you're going for the flat log look anyway, just choose one that looks good.
Or if you intend on going back to a more contrasty look and just want the grading latitude, choose one that has a corresponding 'undo' LUT in resolve.

Would it be easy to add a batch feature so we could drag multiple items and have them added to the queue with the current settings?

EDIT: and draggable to the dock icon swell as the window? XLD is a great utility for transcoding audio. i just drag a bunch of AIFFs on the dock icon and Apple Lossless versions magically pop up on my desktop. Same with Compressor droplets. Great for speedy workflows!

Raw Video Postprocessing / Re: Editing and CC in ProRes
« on: October 29, 2014, 04:14:13 AM »
Yes, I've gravitated to this workflow as well.
Filming normally in in H.264, on top of only 8 bits, you suffer very low resolution color (4:2:0 chroma subsampling), nasty H.264 artifacts and usually clipping at either or both ends.
RAW->Prores gives you full color res, virtually lossless, and if you use one of the log curves via MLRV, you can retain nearly all of your highlight and shadow info.

Cinestyle / Marvel profiles were a good idea but if you've ever tried CC with them you'd know that log and h.264 don't work very well together. We're trying to compress info into the middle of the color range so we can play with it later, but H.264 was designed to discard all that extra info as it's barely visible to the eye when viewed as is.

Even at 10bit it's a huge advantage over standard mode.

Share Your Videos / Re: My commercial shots on 5DMKIII FULL HD RAW
« on: October 27, 2014, 02:56:09 PM »
That last image looks really nice.
How much do you think the Tiffen filter contributed to the look?
I'm assuming its a physical filter and not the plugin?
How many light sources?

Raw Video Postprocessing / Transcoding raw to Prores 4444 vs 422(HQ)
« on: October 25, 2014, 07:25:38 AM »
Decided to start another thread as the forum suggested it, but it's really an extension of this thread.

Appologies If someone's gone here already but I couldn't find it.

Anyhow I couldn't come to a conclusion about what Prores format suits best, and it seems opinions vary.
Do we use 422 and not care about chroma resolution loss as the difference with be negligible?
Or keep all the data and use 4444, possibly wasting space as we don't need alpha?

Well I did a test by bringing in a DNG sequence into AE and using 'Set Matte' to create some alpha.

RGBA -> Prores 4444 = 140.2MB
RGB -> Prores 4444 = 78.4MB     
RGB -> Prores 422(HQ) = 66.1MB 
RGB -> Prores 422 = 49.4MB

RGB-4444 %55 the size of the RGBA, but RGB-4444 is only %18 larger than it's RGB-422HQ counterpart.

So my conclusion is. the lossless compression of the alpha channel is not wasting space.
May as well be safe and use 4444 as the size difference is only marginal over HQ.

@Andy600 thanks. I have a basic understanding of what log does, except the clog/logc ei stuff but thanks for laying it out for me. With regard to the exposure slider in Mlrv, it's a handy tool if exposure wasn't set properly when shooting but I try to make a point of not to using it. I also see the most efficient workflow being dragging a bunch of MLVs onto MLRV to batch them all with the current gamma curve which means no chance to mess with it per clip!
@baldand: any chance of drag and drop batch functionality coming soon?
Being able to fix WB is also nice, if we ever get quick look thumbnails we could identify any to leave out of the batch and add to the queue separately with tweaked WB.

My layman's view of the workflow concept is this. rec709 h264 out of the camera suffers 3 main issues.
1. Discarded detail and compression artifacts due to h.264
3. Major loss of chroma information due to 4:2:0
2. Highlight and shadow information beyond the white and black points are clipped and non recoverable

The prores 4444 codec fixes the first 2, and if the 14bits are scaled(compressed) down to 10bit (or 12 with XQ), that fixes #3. We loose some bits, but the gamma curve prioritises the most useful parts of the information so we retain more bits where we need them.
Of course if we view the entire sensor data compressed like this, it's going to look extremely flat, but we can use a 3d LUT to expand the range back to rec709 etc. to view it as it would have looked straight from the camera.
The important part being that this LUT be applied at the end of the processing pipeline so we still have all that highlight and shadow info to play with before it gets clipped again by the LUT.

The attractive thing about the visionLog curve is that the 3D output LUT could be one of their Osiris film LUTs and we don't need to go through another lossy input LUT step.

Am I on the right track here? The BMD color space fits in there somewhere but I'm not sure I understand where and why:)

Thanks for the info Andy. I've been trying to read up a little on color space etc on Wikipedia but once I hit the lengthy transform equations it starts getting beyond the scope of 'need to know' for me. So tbh a lot of it goes over my head! I've just been working with mlv and Resolve and while dng has some nice advantages, for indie rec709 stuff, it seems to me that a prores workflow could be faster, more efficent for disk and cpu/gpu and more compatible with other apps and OSX (quick look). Ideally I would drag a folder of MLVs on mlrawviwer and it would spit out log encoded prores suitable for resolve with a single 3d output LUT. That could be a film stock LUT or plain old rec709.
I've just not had any lucky with the included log luts for mlvrawviewer, I think mainly because an additional input LUT seems to be required for the Output luts to make sense. So it ends up going thru 3 lossy luts and info appears to get lost or clipped along the way.
Apologies for any naiveity there, I'm still learning:) is this what prores from BMD cameras is?
Anyhow, your luts look equally promising for this application. I'd happily let go of a few bucks to realise this kind of workflow.!

Nice. 3 x price and a bit more fiddly with extra connections, though I guess you could just solder a 3.5mm plug onto the av cable. Charging via USB is def a nice vibe though!

I've been digging around more for getting the most out of our prores exports. Some info on DCP if you should ever find the time and interest!
Here's some correspondance from VisionColor

Is there a way to get or convert these LUTs to .cube format so they could be used with MLRawViewer to export MLV video as Prores4444 with visionLog profile?

thank you for reaching out to us! Unfortunately conventional 3D LUT formats can not hold the data neccessary to convert linear light RAW sensor data to VisionLOG. AFAIK, a more complex camera profile which has Hue/Sat deltas and an independent tone curve is required for such operations.
I guess that the MLRawViewer uses the embedded camera profile to convert the raw data to images at which point it is too late in the process to use a  LUT to extract more information from the image.
Essentially MLRawViewer would need an option to load external dcp profiles for proper conversion...

But then I though I remembered..

However, I don't know how to support DCP files, since those are a binary file format intended for Adobe products. So to use VisionLOG, or CineLOG, you would need to get "simple" LUT versions of those, or else help me find a spec for the DCP file format.

So incase you never could find it....

The developer has mentioned possibly supporting dcp profiles if he could get the spec.
Could you point us in the right direction?

Sure, you can download the DNG specification and SDK on Adobe's website which lays out the dcp profile structure which should be all your developer needs. Here's the link:

Hardware and Accessories / $10 semi-diy 9v battery headphone amp (LM4881)
« on: October 24, 2014, 04:23:58 AM »
Just wanted to share the little headphone amp I wired up.
Cheap, portable, easy to solder, and decent quality components so it sounds great.

What you need:

2. 9V battery clip (a few cents)
3. Canon AV cable.
4. Suitable enclosure of your choice. Sweets tins are good.

I had a spare AV cable so I chose to butcher it and keep it simple but you could easily wire up RCA sockets. I also chose not to use terminal blocks but they're probably a good idea.

There's only a dip switch for low and high gain but I've found the default setting to be the perfect level as is.
You could easily attenuate the input with a pot but I find the ML headphone volume control is enough (devs: a couple a negative gain options might be handy)

Now just need a on/off switch and suitable pocket sized case that could be optionally velcro'd to the tripod.

Specs are not bad either.

Size:76.2 mm (L) x 50.8 mm (W) x 12.1 mm(H) ± 0.2mm
Thermal shutdown protection circuitry
Adjustable gain
Wide power supply range: 8V-24V
Audiophile Quality Sound:
0.025% THD+N @120mWrms 16Ω
0.02% THD+N @75mWrms 32Ω

Wouldn't cineon be the best option to choose?  It's industry log standard and Davinci was been designed to work with it since its inception.

haha well that' sorta of what I'm asking. Thanks for the tip!
Although the the film stock LUTs I was referring to list either DCI, rec709 or in the case of the link just 'log' which according to his screenshots would be log as it comes from the RED.

So If I go to Cineon, i need to get to one of those eventually before the film stock LUT.

And in terms of MLRawViewer, would c.log refer to this Cineon Log? or Canon Log, or Something else entirely?

Pages: 1 [2] 3