Switch for macOS Catalina/Linux (former cr2hdr.app)

Started by Danne, May 05, 2015, 04:32:38 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DeafEyeJedi

Dude... this is such a relief to be able to process over 40 CR2's of Dual-ISO from within the Menu in no time!  8)

No longer stuck with the drag 'n drop mode for raw2mlv only. It's SO nice to be able to choose one or the other.

Thanks, @Danne for the quick fix after @name_are_hard conquered the erratic line. BIG thanks for that!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

Alefrient

Hi!
I wonder if it is possible to process dual_iso cr2 at half resolution to eliminate stripes using Switch?
Thanks!

adrjork

Hi everyone, sorry if the question is a bit stupid, but I can't convert MLV to Prores only with Switch.
In this case I'm not interested into converting MLV to DNG, but only to Prores proxy.

I tried:
-Output is exactly where I want to save the converted Prores files;
-On main menu I add (p) for Prores output, then I add (12) for rec709, then (r) for run.
The result on target folder: NO Prores proxy file, but DNG files!

Then I tried:
-Same things as previous test;
-On main menu I add (m) for mlv_dump, then I add (19) MLV+proxy, then (r) run.
The result is nothing...

Then I tried:
-Same things;
-On main menu (o) then (08) then (r) run.
The result is a little window with "Claening proxys", but nothing seems happening (CPU not working...)

May you kindly help me? Thanks

Danne

Been a while since I used Switch. Noticed proxy exports has an issue. What works is the regular prores exporter. You could test Select (p) from main menu then select (04) for rec709 output.

If there´s an MLV it will first convert into dng files then start encoding to prores. Switch cannot pipe MLV to prores directly but created dng intermiediates to work from.

adrjork

Thanks Danne (my hero!)
Quote from: Danne on May 12, 2020, 10:22:54 AMIf there´s an MLV it will first convert into dng files then start encoding to prores. Switch cannot pipe MLV to prores directly but created dng intermiediates to work from.
This is yet the answer I was looking for: actually I was searching for an app that converts MLV-to-Proxy without producing DNGs (for lack of space) and faster than MLV App.
Up to now, I've noticed that the only app that can convert MLV-to-Proxy a little faster than MLV App is MLVFS+Davinci-optimized-media. BUT... Davinci optimized media are sort of weird/folderish/internal files, and if I disconnect the MLVFS-virtual-drive then I lose the preview image on the timeline footage...
So... it seems MLV App is the only way to go at the moment... (but it takes 8 days for a basic-bilinear MLV-to-Proxy conversion...)

Do you know if there is a Mac app that can do the job via GPU? It should be a faster solution, right? Expecially for something like producing proxies.

Danne

Actually, there's built in mlvfs support in Switch. In main menu select (ml) Then select (A) to activate virtual dng files and go from there.

adrjork

Thanks again Danne.
Quote from: Danne on May 12, 2020, 11:55:08 AM
Actually, there's built in mlvfs support in Switch. In main menu select (ml) Then select (A) to activate virtual dng files and go from there.
I had seen it. Unfortunately in my current case mlvfs seems not to be a solution because all the (too many) original MLV files are in a relatively old (and noisy) external RAID. I would be oriented keeping my external-draisine (dRAIDsine could be an appropriate neologism) "safely" off during the looong time of the preliminary video-editing in Davinci I'll have to face. So I'd prefer having indipendent proxies on a faster (and smaller) internal drive. The only problem is the huge amount of time for the conversion... I'm on Mac, but I've read something about a Win software that should be very fast in MLV-MOV conversion since it's GPU-based (for proxy-things should be great). I'm hoping into something similar for Mac too... :)

Danne

For proxy workflow you will still need dng files in the end either virtually or physically exported.
For fast conversion in Switch you select these options in Prores output menu:




Now select (04) or something else from prores4444 output. Since (07) is set to prores 422 and dcraw quality reduced it will export faster and produce smaller files.


Don´t see why you don´t want the dng folders if you are using a proxy workflow in resolve. If you want direct exports MLV to proroes simply use mlv app. You can start two or three Mlv app apps in prallell to speed up conversion. You could also erase dng files after prores files has been created. Or create proxies from mlvfs.

EDIT: Also fixed the proxy not working situation from before

Danne

Updated Switch. Included mlvfs workflow now has the latest pixel maps from dfort and also working with 1x3(anamorphic) mlv files.

adrjork

Dear Danne, THANKS (really) for your guide and your patience!
Quote from: Danne on May 13, 2020, 05:18:03 AMYou can start two or three Mlv app apps in prallell to speed up conversion.
That's VERY interesting: sorry I can image it's a dummy question, but how can I run 2 or 3 MLV App apps in parallel? Some script from the Terminal? Or via Switch? (Up to now I can simply run a single window of that app...)
...Now I know: Script Editor :) :) :) Great advice, Danne, thanks a lot!

Quote from: Danne on May 13, 2020, 05:18:03 AMFor proxy workflow you will still need dng files in the end either virtually or physically exported. [...] Don´t see why you don´t want the dng folders if you are using a proxy workflow in resolve.
[I want to give you an asnwer about this, but I honestly warn all the people in the forum that the following section is boring, not-technical and unuseful, so you can happily ignore it :)] Actually I don't plan to follow a regular proxy workflow in Davinci, but simply use a prores proxy version of my MLVs, because my current project in based on about 3500 MLVs that means around 34 TB stored in a single 8-drives external RAID6 thunderb.2 full as an egg, and in my 2nd external RAID I haven't enough free space to store all the converted-DNGs. Surely I could use MLVFS but it means keeping the 1st RAID always on, that's I'd avoid for various "safety" reason (first of all the content's safety). It's a huge project to handle for a newbie total-indie like me, mainly because I have NO screenplay: in fact the footage is a sort-of-documentary thing simply based on a concept, not on a story. My "freely-artistic" approach (clearly this is a non-business thing) is "discovering" the form of the film (the screenplay) directly from the "timeline-lab", where I hope to understand which (FEW!) shots to keep, and which others (many, I hope) to cut out. For the few "survivors", I finally will do the actual MLV-to-DNG convertions, and this selected DNG-footage will be placed onto a pretty fast internal 4-NVMe 8TB RAID (should be sufficiently roomy). Then I'll redo the editing following the former proxies-based editing. It's not actually a workflow... i.e. it would not have been strictly efficient for an eventual paid job ;)

Danne

Switch is already running multiprocessing 4 parallell exports so if you want dng exports you could use it. Should be fairly fast.
With mlv app you need to make 4 copies of the program and you can run those at the same time.

adrjork

Dear Danne, I've made a test (perhaps could be useful sharing this):
My hackintosh has an old i7-6950X Extreme 3GHz 10-cores.
Two tests:
1. A single MLV App converting a list of 4 different 27GB MLVs to MOVs in about 37': CPU usage is 1750-1800% (Activity Monitor) and all the cores seem working equally (iStat Menus);
2. Four MLV App instances running in parallel, each one converting 1 single 27GB MLV to MOV in 19-20': each instance's CPU usage is around only 400% and all the cores seem working equally.

So, it seems there is a strange discrepancy: the CPU usage of a single App running in "solo" is more than the sum of the CPU usage of 4 apps running in parallel (so a single App seems to be more efficient because it use more CPU), BUT 4 Apps do the job in about half the time (even if using less CPU...)
It's a bit strange, isn't it?

Danne

Yes, pretty strange. Maybe you should run eight copies  8).
Also test proxyexports with Switch. Might work fast too. Proxy issue is now fixed by the way.

Danne

Uploaded a new version. Proxy exports now are way faster than before. Typically a 5minute clip will take around 1minute.
Also note that scaling down output will fasten exports even more. Watch out for speeding tickets...

adrjork

Sorry guys, surely a stupid question: I've downloaded the last Switch and now, converting MOVs into DNGs, it deletes the MLV originals (the A_ORIGINALS folder is empty). I reset Switch to defaults, but it continues to delete the MLV originals...
How can I avoid that?
Thanks in advance.

Danne

MOV to DNG?
Maybe you didn't wait for the dng files to complete. In that case mlv file is still inside the folder with the dng files. Hard to say what's going on with so little information.

adrjork

Hi Danne, sorry I meant MLV to DNG! I made various tests: MLV (dual-iso) to DNG. Running the task, MLV disappears almost immediately from its native folder. After the conversion is terminated, MLV is not in the A_ORIGINALS folder neither...
Never happened with old versions of Switch... It's strange.

Danne

Find that hard to believe. Please choose a short file and run a screen recording from start to finish. My own eyes have to see this.
If true this needs to be fixed asap.

adrjork

Mea culpa, Danne: yes, the original MLV file is still in the folder of all the dngs. Anyway, what actually happens is that Switch creates the A_ORIGINALS folder, then immediately after starting the conversion it moves the original dual-iso MLV file into the dngs' folder. When Switch is near to have finished, it removes the A_ORIGINALS folder. Then arrives the "finish" window.
I believed that at the end of the conversion I'll have found the MLV into the A_ORIGINALS folder (like when I used old versions of Switch, if I remember correctly). Anyway, is it all normal?

Danne



Danne

Try keeping the original name of the file. Renaming adding punctuations, white space or other strange symbols will often mess things up.

adrjork

Test done, you are right: re-changing back the name to the original form Mdd-hhmm.MLV solves the issue: now the original MLV goes finally in the A_ORIGINALS folder. I tried importing into Davinci both DNG-folders: the one converted from the Mdd-hhmm.MLV file, and the other one converted from the renamed mess-mess.mess.MLV file. The result seems pretty the same (I can't notice any difference in preview, nor in scopes). But you wrote:
Quote from: Danne on May 31, 2020, 09:28:18 PM
Renaming adding punctuations, white space or other strange symbols will often mess things up.
And that worried me a bit: do you mean simply that original MLV will be placed into the DNGs folder? (That's honestly a minor problem.) Or do you mean that something in the DNGs themselves (code, list order) could be messed up? (That would be a pretty dramatic thing because I should rename my MLVs to their original name, that's a rapid thing in itself but implies loosing my detailed system of identification for all that amount of MLVs...)

Second question: I converted MLV to DNGs once in Switch (leaving all default), and once in MLV-App specifing Cineon tonemapping and Alexa gamut. I imported both results in Davinci: in RAW Panel I set both with BMD Film in Color Space and Gamma. Since I was using DNG files, I naively expected to see the same visual result, instead I noticed a huge difference. So, the question is simply: which is the "right" way of converting the MLVs? Should I specify a profile (BMD Film, since the target is Davinci?) or leaving all default (MLV-App's default gamut is Rec.709, but which is Switch's default gamut?)

Thanks a lot for your help.

Danne

You have to test and draw your own conclusions. For instance. What symbol messed up your workflow before? Thrn proceed to see if you can rename as you wish after this. If it looks ok, it probably works.

adrjork

Quote from: Danne on June 01, 2020, 06:43:29 AMIf it looks ok, it probably works.
This last thing referred to the second question?