Messages

1

Raw Video Postprocessing / Re: MlRawViewer 1.3.3 (CDNG/MLV/RAW Viewer & Encoder, Linux/Mac/Win)

« on: November 05, 2014, 05:08:09 AM »

Nice job on 1.4.  Great to have a browser!  Generally speaking, everything seems to working, but I haven't had to chance to really test properly yet.  The only thing I noticed is that using the backspace key works fine when I want to leave the viewer and go back the browser.  But I find that if you are in the browser, the backspace key often causes MLRawViewer to exit completely (as if I had hit the escape key to exit).  I'm not sure how the backspace key was intended to work when in the browser, but I found myself dumped out of the app quite often due to hitting the backspace key when in Browrer mode.  I also found a number of instances where it appeared to hang when browsing up the directory tree near the root where all the drive would be visible.  I'm guessing that it is attempting to scan for raw/dng candidates but I'm not sure.  I will need to test more to give more thorough observations.  Running Windows 7, nVidia Geoforce GTX 560M.

2

Modules Development / Re: [experiment] [5D3] mlv_play speedup

« on: September 01, 2014, 06:06:20 AM »

I ran a few tests using the experimental raw_twk module on my 5d3 with both .raw and .mlv clips

Clip Info:   248 frames, 23.976fps, 1920x1080, 10.3 second clip (playback mode: Color & All)

                                       Before       After    
   Playback in-camera        38 sec       22 sec     73% speed increase
   Playback via HDMI       174 sec       97 sec      80% speed increase

Observations
- HDMI playback benefited a bit more than in-camera playback (an additional 7% speed increase)
- Relative speed increases were the same for both .raw and .mlv files
- The popup mlv_play menu was noticeably more sluggish to appear and dissappear (even more so via hdmi)
- I did not notice any other odd behavior with recording, playback, deleting or navigating clips
- No smoke or explosions (at least for me)

Overall a really nice improvement in playback speed

3

Reverse Engineering / Re: CMOS/ADTG/Digic register investigation on ISO

« on: August 12, 2014, 09:35:00 PM »

I'm not sure if I understood correctly.  Are you saying that 5d3 crop mode will display realtime liveview at 1920x1280 but not 1920x1080? Is that right?

4

Reverse Engineering / Re: CMOS/ADTG/Digic register investigation on ISO

« on: August 12, 2014, 06:33:07 PM »

Amazing find!

5

Modules Development / Re: MLV PLAY (mlv_play.mo)

« on: August 10, 2014, 05:10:54 AM »

It's not really an issue leaving it in place... especially if people find it useful.

6

Feature Requests / Re: Audio recording should be enabled by default MLV_SND

« on: July 31, 2014, 05:39:39 AM »

+1 to single module with MLV sound switch

7

Modules Development / Re: MLV PLAY (mlv_play.mo)

« on: July 31, 2014, 05:35:05 AM »

Also, Exact/All toggle of mlv_play doesn't yet work with raw_rec.  Currently, it is displays only All frames.  I toggle that feature all the time to be able to check the speed of my camera movement in realtime vs checking the quality of the shot.

This was fixed in the recent nightly.  Works great.  Also, overall stability of mlv_play is much improved.  Thank you.

Not that it bothers me, but I was just curious about the need for color/fast toggle.  Seems like this was originally put in place to deal with the slower playback of raw files.  But with Exact/All toggle working so well (and in color), I can't see why anyone would ever need the color/fast option now.   Removing it would simplify the menu a bit and free up space in case it's needed down the road.

8

Feature Requests / Re: MLV/REC simpler status indicator

« on: July 31, 2014, 05:17:07 AM »

you'd like to have HDMI overlays fixed and rec status in the top bar.

Yes... hopefully the image dumps being collected will eventually yield some good news on that front.

You'd want status in the picture only if it was required for higher FPS, or if HDMI overlays are not fixed.

GD needs to be turned off in order to maintain recording at higher fps, so the rec icon within the picture is needed.  If HDMI overlay issues get resolved, with GD turned off, it would be best to move the rec status as high up on the display as possible.

9

Feature Requests / Re: MLV/REC simpler status indicator

« on: July 30, 2014, 11:05:07 PM »

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

I turn off GD for frame rates greater than 24.  I find that even with zebras, histo, etc turned off, I get more reliable/consistent performance with it off at higher frame rates which I use a lot.  I agree that the bitrate and idle time are not necessary since the icon color changes are sufficient.

Having the record icon on screen in a minimal way appeals to me simply because of the way I record using an hdmi monitor.  Due to overlays not lining up properly, I scale my hdmi monitor so that the entire video window takes up the whole screen, pushing the overlays off screen.  I need the record icon displayed within this view.  Now, when/if hdmi overlay issues are ever sorted out, I'm sure I would prefer the approach raw_rec uses with the record indicator on the top info bar.

Ideally, both mlv and raw modules would be more consistent with respect to presentation and give the user an option to display the record icon in either the top menu bar or in the main video window.

10

General Development / Re: Silent picture capture with raw video format

« on: July 24, 2014, 11:30:26 PM »

Tested (5d3) the updated mlv_dump on a much larger spanned set of files and all works well and no black borders.   Thank you.

11

Raw Video Postprocessing / Re: MlRawViewer 1.1.7 (RAW/MLV/CDNG viewer/converter, Linux/Mac/Win)

« on: July 24, 2014, 02:11:59 AM »

My feeling is that the final embedded framerate in the DNGs should be a standard framerate since that would let the DNGs work well in Resolve and NLEs etc.  For example, when I extracting the silent pics using mlv2dng, it automatically embedded 23.976 as the frame rate which allowed me to bring the sequence right into resolve into my 23.976 timeline and I was able to play back the timelapse immediately without issues...super easy.

@baldand, A suggestion would be that any changes made to support silent pics should coincide with manual framerate support.  That way people would be able to choose between leaving the actual capture framerate in place as well accomodate those needing 23.976, 24, 29.970, 30 depending on what's needed for their project.

In case you need another test mlv containing just 5 full-res silent pictures....  https://copy.com/7pc7Tla4SAqx (let me know if you would like me to a upload larger mlv file I have containing 110 frames or so).

12

General Development / Re: Silent picture capture with raw video format

« on: July 24, 2014, 01:37:58 AM »

In case anyone needs it for testing purposes, here's a small mlv file shot on the 5D3 containing just 5 full-res silent pictures inside...  https://copy.com/7pc7Tla4SAqx

13

General Development / Re: Silent picture capture with raw video format

« on: July 24, 2014, 12:50:38 AM »

MA Visuals with 5D3, can you make a small MLV file and upload to dropbox so Linux and OSX users can try to convert with their  mlv_dump 

I have a feeling Linux user will be able to extract DNG without black bars just as for my 5D2

Ok.. I'll post a link shortly.

14

General Development / Re: Silent picture capture with raw video format

« on: July 23, 2014, 11:33:46 PM »

Could someone please test the 4GB limit thing? (Just take more than 4GB of photos in a timelapse and make sure you get a .M00 file and that it converts correctly.) I have not had any confirmation that it is working.

Ok I tested (5D3, Win7) for over 4gb and it did create the separate 4gb chunks in camera (mlv... m00... m01).

But mlv_dump gives the following error trying to extract the DNGs.  I was able to extract the complete set of DNGs using mlv2dng.exe however I do get the black bars.

E:\0001-MLVs>mlv_dump 00000001.mlv --dng

 MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: '00000001.mlv'
   - Convert to DNG frames
   - Output into '00000001_frame_'
File 00000001.mlv opened
File 00000001.m00 opened
File 00000001.m01 opened
File 00000001.m02 not existing. (This is where is breaks... it is expecting m02 even though m01 is actually the last file)
Processing...
[ERROR] File ends in the middle of a block
Processed 0 video frames
Done



Edit: I just verfied that mlv_dump works fine extracting DNGs from regular video on my system.

15

Modules Development / Re: MLV PLAY (mlv_play.mo)

« on: July 17, 2014, 01:08:57 AM »

Also, Exact/All toggle of mlv_play doesn't yet work with raw_rec.  Currently, it is displays only All frames.  I toggle that feature all the time to be able to check the speed of my camera movement in realtime vs checking the quality of the shot.

16

Modules Development / Re: MLV PLAY (mlv_play.mo)

« on: July 17, 2014, 12:55:34 AM »

Downloaded the new nightly and can confirm that the delete from mlv_play works when using in raw_rec.  Thank you!

17

General Development / Re: SRM job memory buffers

« on: July 17, 2014, 12:44:46 AM »

I can confirm a big increase in performance after the SRM update.  Was getting 15-20 seconds 30fps... now getting 30-40 seconds.  Double the recording time.  At least for me, this makes 30fps a more stable and reliable frame rate.  Also, 48 fps (squashed mode) went from 8 to 15 seconds. Again, much more dependable where before, it was borderline for me. These new times are with raw_rec.  I get similar relative increases with mlv_rec, just shorter actual recording times due to the extra overhead of the mlv format.   

Changes like this really do make a big difference.  For many HDMI monitor users, this eliminates the Liveview blackout that happens with the old memory hack prior to recording.  I could never deal with that during a production so never realized the benefits of that hack.  Thank you Alex and for any others who contributed to this.

The above was using a 5D3 and a SmallHD DP4 monitor.

18

Modules Development / Re: MLV PLAY (mlv_play.mo)

« on: July 16, 2014, 09:42:04 PM »

It never worked, from what I can tell. Will fix.

I never noticed since I was using mlv_rec for a while but just recently switched back to raw_rec for 30fps shooting due to the better performance of raw_rec.   I know that overlays are being collected/analyzed for a potential solution to the HDMI issue, but mlv_play also has another display issue that seems unrelated to the the overlay alignment issue.  When playing back a clip while using an HDMI monitor, initially it always displays "No Image".  The only way to view the last clip is to first navigate to the previous clip using the top dial, and then back again to the last clip (this clears the message).  You can see it here... http://www.magiclantern.fm/forum/index.php?topic=9062.msg88894#msg88894.   At that time,  I was only reporting the overlay issue but now I realize that the "No Image" issue seems to be independent of the misaligned overlay issue.   One thing that happens a lot is when you have recorded your first clip and want to review it, you can't because there is no other clip to navigate to to clear the message.  So you then need to record a 2nd clip just to have something to switch to.  Not the end of the world but just wanted to mention it to separate it from the other overlay issues.

By the way, as a few other forum members have pointed out, switching on Force HDMI-VGA does indeed help with alignment of the main video display in playback mode.  But ml overlays are made worse so it's a bit of a tradeoff.  In case it helps anyone who is using the 5D3 and SmallHD DP-4 monitor (it may be applicable to the DP6 as well), what I do is create 2 custom scale presets on my DP4... 1 for recording and 1 for playback.  With Force HDMI-VGA selected in ML, none of the built-in DP4 monitor presets work well, so you will need to go into custom scale settings and tweak to get full screen video.   I have opted to tweak the scale settings to view playback completely full screen, but this will push the ML overlays completely off screen.  The main video display takes precedence for me.  Hope that helps some of you.

19

Modules Development / Re: MLV PLAY (mlv_play.mo)

« on: July 16, 2014, 04:00:28 AM »

Just downloaded today's nightly.  I can no longer delete clips via mlv_play when using raw_rec.  I tried initiating deletion from the trash can button as well as from the mlv_play popup.   No errors or indications that the deletions are not actually happening.  I did try various common frame rates with and without hdmi monitor plugged in.  I can delete from the file manager however or from mlv_play while using mlv_rec.   So the problem seems to only be when using raw_rec.

20

General Development / Re: SRM job memory buffers

« on: July 15, 2014, 08:13:42 PM »

Does this mean that the newly found SRM memory will be automatically be made available transparently to raw recording with no liveview resetting?  I was never able take advantage of the memory hack on the 5D3 because the long delay of resetting liveview caused my hdmi monitor to miss the initial 4 seconds of recording as the monitor reset itself.  This alone would have a huge impact for hdmi shooters.  Also, will small hacks still be available/useful?

21

Raw Video Postprocessing / Re: Cinelog - True logspace conversion for DNG and CinemaDNG footage

« on: June 23, 2014, 01:27:17 PM »

@Andy600 Can your upcoming Cinelog-C for Magic Lantern Raw be applied as a LUT in Premiere?  I want to avoid the ACR/AE transcoding workflow so I plan to import ML cDNG files created by MLRawViewer.  The new Lumetri effect in Premiere CC will let you apply a LUT without needing to launch Speedgrade.  Also, will your Cinelog-C match up well with Osiris LUTS or will another transformation be required?

22

Raw Video Postprocessing / Re: MlRawViewer 1.1.6 (RAW/MLV/CDNG viewer/converter, Linux/Mac/Win)

« on: June 23, 2014, 03:58:55 AM »

@baldand I have been revisting importing the cDNG files that MlRawViewer creates using the new version of Premiere CC 2014.  Since the last time I tried this, the experience seems much better than before.  There still remains some magenta highlight issues but there is a workaround for this (using the Video Limiter effect).   Also, it seems that finally, Adobe has acknowledged the pink highlights issue and are actively working a on a fix... see the Adobe forum thread here... https://forums.adobe.com/thread/1500841.

In the new Premiere, the new source settings window does give as least some level of control for exposure, while balance, tint.  It's really great that the white balance set in MLRawViewer carries over pretty accurately in the cDNG files imported into Premiere.  I have read in a few places that Premiere appears to by applying rec.709 upon import of the cDNG files (shame that is doesn't allow selection of a LOG space upon import). 

I'm now trying to figure out the best way to retain the full 14-bit information in Premiere so I ran a few tests.   I purposely significantly overexposed a clip via the new source settings window in Premiere.  I then proceeded to try to bring back the highlight info as much as possible using Colorista II repeated this test using the new Speedgrade CC 2014.  Colorista could not retrieve much of the overexposed information but Speedgrade was able to recover dramatically much more of the highlight info.   I am guessing that Speedgrade is accessing the full 14 bits while Colorista may be limited by a the rec.709 imposed by Premiere upon import.  Here's a video test someone recently performed on Speedgrade which claims that Speedgrade is able to access the full 14 bits of information.... https://www.youtube.com/watch?v=0LFwNs6BDNg.  Since Premiere now has the Lumetri LUT effect which utilizes the Speedgrade engine, it seems like the best option for maximizing the full 14bit of information would be to first apply a LOG-like LUT using Lumetri effect on all cDNG clips imported into Premiere. Then I would use Colorista for the rest of my grading.  I think what we need now is a good LUT for convert ML Raw to LOG.

I was just curious to know your thoughts about all this with regards to using a cDNG workflow.

23

Raw Video Postprocessing / Re: MlRawViewer 1.1.6 (RAW/MLV/CDNG viewer/converter, Linux/Mac/Win)

« on: May 30, 2014, 07:07:10 PM »

Maybe Nvidia geforce problem?
Nice Parrot!!!!

Could be... I'm using an Nvidia GeForce 560M.

24

Raw Video Postprocessing / Re: MlRawViewer 1.1.6 (RAW/MLV/CDNG viewer/converter, Linux/Mac/Win)

« on: May 30, 2014, 07:23:34 AM »

Hello Baland!!!! I have this problem when i apply Srgb and Rec709 curve...there are points yellow and blue in movement in the frame, in this picture is not very apparent but when I play the footage is very visual...I have 7d camera with the last build 24/05/2014, windows 7 and nvidia geforce gtx295 graphic´s

I get the same exact thing as hdclip has reported.  Both the sRGB and Rec709 export to MOV have blue blotches (with some green blotches) in the dark areas with every clip I tested.  Highlights seem ok.   LOG, Linear, HDR export fine.  The clips were shot with the latest nightly build for 5D3 using MLV.   I had already downloaded the latest NVIDIA drivers.    I also tried the use the experimental 0 key prior to export and the issue remains either way. 

I can provide an MLV file that shows the issue if it helps... just let me know how you need me to send it to you.

25

Raw Video Postprocessing / Re: MlRawViewer 1.1.3 (RAW/MLV/CDNG viewer/converter, Linux/Mac/Win)

« on: March 18, 2014, 08:32:55 AM »

I always suspected that it would ultimately require Adobe to fix this on their end.  Thank you for your thoughtful explanation.  It seems the most practical method of post processing for Premiere users then would be then to export to ProRes using your Log curve, and then import into Premiere.  Well at least that will be my preferred workflow unless the pink highlight issue is eventually solved.  Just a few questions....

-Will the ProRes exports eventually support queuing just like DNGs? 
-Is the brightness control equivalent to an exposure control?
-Just wondering why there is no Tungsten white balance option.  Also, it may be too much to ask, but would it be possible to add a white balance eyedropper/picker such as found in ACR, etc. to make it easier to find the correct white balance?

Anyway, terrific progress on your tool.  So professionally developed and very efficient and refined.  Much respect.