Author Topic: Switch for macOS Catalina/Linux (former cr2hdr.app)  (Read 183248 times)

Teamsleepkid

  • Member
  • ***
  • Posts: 247
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #300 on: September 18, 2017, 07:38:09 AM »
tried the one linked on the first page. went really fast i got pretty excited. looked into my dng folders and nothing in there. switched back to previous version of switch (pulled it out of the trash) and that one worked fine dngs back in the folders all good. so i don't know might be broken.
EOS M

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #301 on: September 18, 2017, 08:21:09 AM »
Do you have the LOG file anywhere?
What camera are you using, how are the files recorded? What are your settings when processing?
Just tested over here and couldn´t reproduce with files from a 5D mark III. Eosm files seems ok as well.

Speed increase will mostly affect spanned MLV files and only when checking metadata information in the very start of the program.

Teamsleepkid

  • Member
  • ***
  • Posts: 247
EOS M

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #303 on: September 18, 2017, 09:32:21 PM »
Strange. Can you send me a samle of the MLV file? You can create samples from the mlv_dump menu (17) create a sample files package

zachnfine

  • Freshman
  • **
  • Posts: 51
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #304 on: September 19, 2017, 04:37:18 AM »
For those of us on an openzfs filesystem on OS X (am I the only one?), Switch (as did cr2hdr before it) produces prores files with all the frames running in random order. This is pretty cool to look at, but is definitely not as useful for normal purposes as standard sequential output. This can be fixed by simply adding a '-s' flag to the 'find' commands in the FFmpeg_produce_0*.command files. All this flag does is make explicit that find returns files in 'lexicographical order', which appears to also mean numerical order.

Here's an example of one of the invocations of 'find' from those files, with the '-s' flag inserted:

Quote
#export ProRes4444
    find -s "$out""$out3""$name""$sl". -maxdepth 1 -iname '*.dng' -print0 | xargs -0 dcraw +M $h2 $o $S \
-c -6 -W -q 3 $gam $wb $pix $br | ffmpeg -loglevel warning $wav1 -f image2pipe -vcodec ppm -r $fps -i pi\
pe:0 $sd -vcodec prores_ks -pix_fmt yuv444p10 -n -r $(echo $fps / 2 | bc -l) $tbl$cin$cin_01$cin_02$cin_\
03$cin_01b$cin_02b$cin_03b$scale$denoise$sharpen "$out""$out2""$date"_ProRes4444/"$name".mov

I've done the search and replace on all instances of 'find "' to change them to 'find -s "' in my local copies of FFmpeg_produce_0*.command, and now my prores output is watchable. I'd suggest this as a fix for the main branch of Switch but I don't know if the '-s' argument works in non-OSX versions of 'find'.


DeafEyeJedi

  • Hero Member
  • *****
  • Posts: 3411
  • 5D3 | M1 | 7D | 70D | SL1 | M2 | 50D
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #305 on: September 19, 2017, 04:59:16 AM »
Great find @zachnfine!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

dfort

  • Guest
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #306 on: September 19, 2017, 06:37:39 AM »
I'd suggest this as a fix for the main branch of Switch but I don't know if the '-s' argument works in non-OSX versions of 'find'.

You know you could submit a pull request in Bitbucket so anyone who wants to test out your suggestions can easily do so and give feedback. Though knowing Danne he is probably already trying out the '-s' flag.

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #307 on: September 19, 2017, 07:30:25 AM »
Gonna check. It's actually the second time someone a user encounter this. Last time was in MLP, former project I worked upon. Oh, it´s the same user :). Welcome to Switch then.

Teamsleepkid

  • Member
  • ***
  • Posts: 247
EOS M

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #309 on: September 19, 2017, 08:15:12 AM »
Processing of that sample works just fine over here with the latest version. I suggest you try to process it one more time. If it doesn´t work try restarting your computer and run it again, and then report back.
Thanks for testing.

zachnfine

  • Freshman
  • **
  • Posts: 51
Re: Switch for macOS Sierra/Linux (formerly cr2hdr.app)
« Reply #310 on: September 19, 2017, 06:21:30 PM »
You know you could submit a pull request in Bitbucket so anyone who wants to test out your suggestions can easily do so and give feedback. Though knowing Danne he is probably already trying out the '-s' flag.

Ah, interesting. I figured there was some sort of standard procedure. Have never used bitbucket.

On a different note -- I think the "-s" flag for sort order is a feature of BSD find but not of GNU find. So "-s" will work for OS X and BSD varietals, but likely not for Cygwin or Linux.

According to the man page '-s' tells 'find' to traverse the directories in lexicographical order. It appears that this just happens by default without the flag present with HFS+ filesystems, but OpenZFS filesystems are an exception. I suppose there might be others.

Teamsleepkid

  • Member
  • ***
  • Posts: 247
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #311 on: September 21, 2017, 06:44:55 AM »
maybe its because I'm on el cap...
EOS M

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #312 on: September 25, 2017, 09:38:06 PM »
New upload

HDR CR2 automation
ML has a really good HDR bracketing feature. Even canons own bracket function works really well. There is also a really nice open source project called HDRmerge, which can output merged dng files straight from CR2 without any need for intermediate tiffs for instance:
http://jcelaya.github.io/hdrmerge/

For this to work you need to install HDRmerge into the applications folder.

Usage:
Fill a folder with bracketed CR2 files and Switch will group and then use HDRmerge to output merged dng files. Switch uses exiftool to find the time gap between the brackets, sends them to a list then process to dng files multithreaded.

In main menu select (h)  HDR processing(CR2)

Then


Progress bar while grouping CR2 brackets


HDRmerge processing the brackets


DeafEyeJedi

  • Hero Member
  • *****
  • Posts: 3411
  • 5D3 | M1 | 7D | 70D | SL1 | M2 | 50D
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #313 on: September 28, 2017, 10:44:00 AM »
Thanks @Danne for reviving HDR back once again and this time it is definitely a game changer when it comes to this HDRmerge automation. Can't wait to try it out! :D
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

dfort

  • Guest
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #314 on: October 07, 2017, 05:42:00 PM »
I've been using Switch to process MLV files for a documentary project and came up with an issue that really isn't a problem with the app but it is something that people shooting mlv_lite with H.264 proxies should be aware of.

Out of four days of shooting that amounted to a few hundred clips and several hours (estimated about 300 shots, 4 hours) there were only two clips where the length of the raw footage didn't match up with the trimmed H.264 proxy. Being the perfectionist that he is Danne tried his best but the issue isn't with Switch--it turned out that sometimes the H.264 recording stops before the MLV. One short clip was off by 1 frame and the other, an 8 minute shot that spanned two H.264 files was off by 2 frames.

The way that H.264 proxies are recorded they are black at the head and tail. Switch can create new proxies to the same length as the raw video. I learned that Switch uses the black at the head of the proxy and checks the length of the raw file to make sure the lengths match perfectly. Of course if the H.264 cuts out early there's not much Switch can do about it.

Ok--so there's a slight chance of having a H.264 proxy short by 1 or 2 frames but shooting MLV with H.264 proxies is probably the most practical way to shoot. At least if you're shooting regular 1920x1080 with a 5D3. I doubt this will work with other frame sizes or other cameras. Here are the advantages:

1 - You only need to activate the mlv_lite module. No need for mlv_snd to record audio or mlv_play (raw_tweak?) -- you can't playback in real time in camera with that anyway. However, you can play back the H.264 proxies in the camera just fine which is very helpful in the field.

2 - You can start editing before the MLV files are processed. There's an option in Switch that allows you to trim the H.264 proxies without having to process the MLV files. While not as fast as simply copying the files off the card, it does cut down the wait time between shooting and editing. As an example, on a day that I shot 51 clips totaling 31.5 minutes it took only 17.5 minutes to trim the H.264 proxies compared to processing the MLV files to DNGs which took 4 hours. Yes, you can also use MLVFS or whatever other post workflow you want, just remember that the audio must be extracted from the H.264 proxies and Switch does that for you.

3 - Recording on two cards simultaneously. On the 5D3, which is the only camera this workflow is practical, can be setup to record H.264 on the SD card and MLV on the CF card. I used 128GB cards so the SD card had ML loaded and I didn't lose any setting because I could shoot all day without having to swap out that card. The CF cards could hold about 45 minutes of 14-bit lossless but I would switch out CF cards frequently just in case something get corrupted. Glad to say it has never happened.

Here's the best part about shooting this way--my partner in this project is comfortable working with H.264 and isn't quite convinced that Magic Lantern is worth all the extra work. This way we can have it both ways. At the end of the post we have the option of color grading the raw video files.

Ok, there are drawback too. My biggest gripe is that LiveView goes dark until it starts recording. That makes it hard to see if your shot is lined up on a run and gun shot and I missed several shots because it does seem to take longer before recording starts, about 4 seconds or so.

One other point worth considering when shooting lossless compression. If the scene has a lot of contrasty detail and you open up the aperture (like to check focus) it could overwhelm the compression. The console opens, shows a bunch of error messages and ML saves crash logs. Restarting clears things up but if you are having problems simply switch off the compression. Yeah, the files will take up more room but the CF card has no problems keeping up shooting uncompressed 14-bit 1920x1080 23.976 FPS.

12georgiadis

  • Member
  • ***
  • Posts: 213
  • 5DmkIII - 7D - EOS-M
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #315 on: October 07, 2017, 09:23:43 PM »
Good summary Dfort. I think this workflow is necessary for all the cameras if it's possible with lower bitrates. This is the best way to preview and to edit straight off the camera.

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #316 on: October 07, 2017, 10:05:01 PM »
Very nice follow up Dan.
12georgiadis, you should download the latest version. Tweaked thresholds a bit...

12georgiadis

  • Member
  • ***
  • Posts: 213
  • 5DmkIII - 7D - EOS-M
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #317 on: October 08, 2017, 01:31:58 AM »
Ok, thank you Danne, I'm gonna test it soon

IDA_ML

  • Hero Member
  • *****
  • Posts: 1014
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #318 on: October 08, 2017, 01:05:25 PM »
This is very useful practical information, Dfort!  Thank you.

I have a question to Danne:  Is it possible to compile Switch for Windows x64 too?

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #319 on: October 08, 2017, 03:22:20 PM »
Hi IDA_ML. I started porting most of this stuff to linux subsystem for windows. Do you have the possibility for this on you Windows system? Another solution for proxy matching is to continue working with batch_mlv and put it in there.

Lars Steenhoff

  • Senior
  • ****
  • Posts: 473
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #320 on: October 11, 2017, 02:06:54 AM »
It would be really nice if we could make a nice GUI for this workflow.



Teamsleepkid

  • Member
  • ***
  • Posts: 247
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #321 on: October 11, 2017, 07:55:39 PM »
even better totally automatic use the new pixel stuff bouncy ball is working on and just have it batch mlv to dng. no options just works. thats my dream. But seriously thank you this is the only software that works well for me and i'm always using it.
EOS M

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #322 on: October 11, 2017, 08:10:43 PM »
@Lars Steenhoff
GUI, always wanted to do this. Then again, I can´t find a way building one to fit bash scripts. The path right now is to instead focus on keeping everything updated and multi processing. A lot of functions implemented. Will take a while porting it to a gui.

@Teamsleepkid
It´s on my todo list putting in Bouncyball´s latest mlv_dump version both in Switch and batch_mlv. Even so, right now Switch is using Bouncyball´s fpmutil, a side tool doing exactly what latest mlv_dump_on steroids is doing. Just select (ms) in main menu and you´ll be using mlv_dump_on_steroids...

Lars Steenhoff

  • Senior
  • ****
  • Posts: 473
Re: Switch for macOS Sierra/Linux (former cr2hdr.app)
« Reply #323 on: October 11, 2017, 09:07:06 PM »
I'm not an expert but it seem Q is used for apps that are cross platform
https://en.wikipedia.org/wiki/Qt_(software)

Maybe this can be an option?

I guess its a lot of work