Messages

**Interesting Facts**

Both started export (.MOV) at same time.

Top Left = MlRawViewer 1.3.3 (Mac_Perf Test)
Bottom Right = MlRawViewer 1.3.3


*Edit*
Approximate 10 minutes later...

@Baldand -- Thanks again for your PM regarding test for Mac. I ran it twice to make sure and deleted a bunch of empty .MLD files as well as empty DNG folders that were created by your app right before the crash. Perhaps there's something wrong with my macbook pro or could this be due to MLVFS latest update?

**Edit**
Test #2 (Frozen Exports)

I'll keep troubleshooting this down to figure out what is causing this app to NOT export either DNG's nor .MOV's...

All was fine until I updated the test app and then again on the original 1.3.3 (non-test) and still the export error persist.

Here's the CR from the Mac_Perf...
https://www.dropbox.com/s/bksw9fqbrim83fb/CR_MlRawViewer_1.3.3_Mac_Perf.rtf?dl=0

SJ

[Also: Has anyone else seen a similar extreme performance regression with MOV encoding in 1.3.3 compared to earlier versions?]

I am not able to reproduce this. Can you do some more quantitative tests and give more information:

- Exact details of your computer and operating system, source and target disk types


- Version numbers you are comparing, e.g. 1.3.2 and 1.3.3 (don't change any other aspect of your setup when comparing results) currently comparing between 1.3.2 & 1.3.3
- Encoding settings, e.g. how many LUTs, mapping function (e.g. Log-8, C-Log), stripe correction on or off

- Time taken to encode with old version currently testing

- Time taken to encode same files with same settings with new version currently testing

It might be worth checking time taken both with and without stripe correction since that is a more complex processing pipeline. Also good to test with more than one source file.  Agreed. I am currently testing this since I felt that the stripe correction really takes a toll (which is normal) but as for me with 5D3/EOS-M I'm not really noticing any stripes issues except for the 7D that I use at work sometimes

THANKS @baldand!

Also: Has anyone else seen a similar extreme performance regression with MOV encoding in 1.3.3 compared to earlier versions?

Just downloaded the latest update few mins ago.. Thanks @dmilligan! Will let you know how it goes..

Question -- is it always reccommended to take the files out from the mount folder and into the file system (desktop, external drives, etc) as oppose to try running apps within the mount folder itself?

Perhaps it would run faster running off the system rather than or does that not matter?

Just downloaded the latest update few mins ago.. Thanks @dmilligan! Will let you know how it goes..

Question -- is it always reccommended to take the files out from the mount folder and into the file system (desktop, external drives, etc) as oppose to try running apps within the mount folder itself?

Perhaps it would run faster running off the system rather than or does that not matter?

@Danne -- all good. apparently it opens up just fine via ACR/LR5 as soon as I got home tonight. Both takes. Perhaps the first take was due to not being fully completed (as you stated regarding the black/white levels not being applied) as strange as that could be... not sure how this happened but I wouldn't worry about it.

Could be due to my old poor 2006 macbook pro running Mavricks, ha?

will upload the test footage as soon as Vimeo is back into service from their so called maintance.

Thanks again for everything!

@baldand -- sorry for the delay but I also wanted to report some CR regarding a situation when I tap on 'W' to double check my destination folder for output DURING the process of rendering .MOV files and the app suddenly crashes (twice I tried same method)... is this normal for 1.3.3?

https://www.dropbox.com/s/r4cdl4aoydlusjs/CR_MlRawViewer_10%3A18%3A14.rtf?dl=0

I probably shouldn't have done this and wait until the rendering ends otherwise I wouldn't be asking this. Again, I absolutely am in awe of this remarkable app and will continue to support you as much as I can -- NO BIGGIE because I was only using my test files. 

Other than the rendering is literally like 3X slower than what it used to be on previous versions... is there a reason for this?

talk soon.

Indeed the wireless remote FF would be killer and dream come true for all of us.

Until then...

Here's take 2 of the converted DNG's...

https://www.dropbox.com/s/nqnlhhj2dtaq0cs/M20-1628_000001.DNG?dl=0

I actually did let it run through overnight so I'm assuming it did apply the white/black levels toward the end?

I am currently converting again with the newest app that you mentioned to me in PM from last night and will upload a sample DNG as soon as its completed..

It's still in the process so I'll wait for the white/black levels to be applied...

@Danne -- my fault I fell asleep last night and here is the DNG you requested...

https://www.dropbox.com/s/t3bswzveeg0z6ti/M20-1628_000000.DNG?dl=0

*update*

Although I did it twice just to make sure. For some reason after your app is completed and I get an error when trying to open the newly converted DNG's. Tried again with LR5 -- same.



Will try restarting the macbook pro and try one last time before I hit the sack...

Thanks for the hint @dmilligan and I am enjoying your latest MLVFS so far... looking forward to future updates as we all grow within the magic...

BIG Thanks @Baldand for your most hyped update this week. I've been jonesing for this all day today because I could literally feel it!

What a coincidence to have this & @Danne's incredible cr2hdr-r application (automator) both get their nice updates today which I am currently in the process of it as I type 



Stand by...

*EDIT*

Anyone else notice a lag within the app during .MOV exports on the latest MlRawViewer (1.3.3)?? To me, it seems much longer to render & I wonder why...

This is quite interesting... definitely makes sense with the fact that the dual-ISO giving correct exposure feedbacks because its actually reading it 'deeper' within both ISO's as oppose to just one.

Indeed, very well done! Excellent editing I thought the pace was spot on. I like how you saved the best shot for the closing...

copy that @dmilligan & @a1ex -- I'm off to bed and will get back on the boat w you guys over the weekend!

Thanks guys!

SJ

looking forward to it @Danne! 

Just tested out the latest update of MLVFS -- it is in fact quite impressive especially with the new GUI layout as well as the DUAL-ISO 20-bit option...

I tried to leave everything alone as much as possible beside 'Bad Pixel Fix' and 'Dual-ISO 20-bit' and the DNG's are coming out quite weird...




Definitely better than the previous version but it's not quite the same quality as if you were just to export as unconverted DNG's and then use a stand alone app (cr2hdr-r) through with Automator OR the 20-bit plug-in for LR5... either one of these gets the job well.

**ALSO when trying export files directly from the MLVFS mount folder -- it freezes up the Photoshop app and have to force to close BUT it seems to work just fine with LR5... just have to wait for it to finish load which takes forever! is there a reason for this?



The only question I have regarding this is whether or not should I apply the same levels through command because I'm not sure if MLVFS does this? (this is why I love the new cr2hdr-r workflow the @Danne created as well @dmilligan's merged into this 'Service' similar to MLVFS.

Unless I am missing something regarding the newly updated MLVFS...

THANKS ALL!

@kichetof -- my apologies I didn't realized you responded to one of my post from weeks ago. Somehow it got buried along... anyway I still have the original MLV file as well as the DNG's (pre and post MLVFS) and I've been also noticing that your plug-in beta 3 works for most part except for when sometimes LR processing bar on top left corner freezes or does not show percentage BUT when I go into my folder and can see the cr2hdr 20-bit doing its job as usual.

Perhaps its because I'm running mavricks on a 2006 Macbook Pro. 

I'm still on the fence between MLVFS (works with cr2hdr-r through Automator) and your plug-in on LR5 although it can be buggy at times when using it together with MLVFS.

Thanks again for your dedication and correspondents on keeping your plug-in's useful in the long run.

Let me know if you still want the samples of my original MLV and DNG's for your own experiments!

Hello-

I use a 70D at work (that I can take home for testing)  for sports shooting (mostly on gimbal TYTO's) and it would be a dream come true to have ML installed on it.

Let me know if there's any way I can contribute to speed up the process on this magic...

*cheers*

Can I use the raw2dng.exe for mac? Please help! I cannot remove the Pink dots on my RAW.

There isn't a version for Mac, however if you want to try and use @Baldand's remarkable app which includes similar PDR effects.

Here's the link: https://bitbucket.org/baldand/mlrawviewer/downloads/MlRawViewer_1_3_2_mac.dmg

Enjoy...

all of a sudden the MLV dumper stopped working running Mavricks on 2006 Macbook Pro...



anyone else out there out experiencing the same issue?

(I accidentally posted this in the wrong section of the forum -- not sure how to delete this and move it over to the MLV Dump section -- my fault @a1ex)

hmm. think most interesting would be 5DIII DualISO, EOS-M should be interesting cause of the af-pattern on sensor.

5D3 - https://www.dropbox.com/sh/0pjyczg9i5wzbxh/AAAvkEs5o6idJ-nGkns0rudna?dl=0

EOS-M - https://www.dropbox.com/sh/518hfz7rmal6q3p/AAB7QI7ddayuse6DqOODG7Vja?dl=0

@DeafEyeJedi:
could you provide a short DualISO-Clip for the samplefiles?

from which body? 5D3, EOS-M or 7D?