MlRawViewer 1.3.3 (CDNG/MLV/RAW Viewer & Encoder, Linux/Mac/Win)

Started by baldand, December 09, 2013, 06:10:19 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.


swinxx

hello,

@baland:

i have a iris gpu, yes.
my osx is 10.9.3, so its the latest stuff. i have another mac with a nvidia 680 gpu with 4gb ram but i can not test your app til end of july cause i am on holiday now :)

greets and thank you for you effort.
sw

ToS_Maverick

Quote from: baldand on July 11, 2014, 11:40:18 AM
- Fix for default brightness of log output (it was 16 times too dark)

I've also changed my build environments for both Windows and Mac. It's possible this will cause some problems for some people, but I hope it won't.

Please let me know here if you have tried this version out, and if it worked ok, or if you saw some problems.

Thanks!

Hi baldand,
thank you for the fixes!

The brightness of the log output is correct now indeed! I'm mainly using OSX but was trying MlRawViewer on Linux as well and noticed the brightness difference in 1.1.6. Seems it was working correctly in Linux!
Does that only apply for the Win/Mac build?

Didn't test much else but it felt quite solid!
Was the WB/Exposure saving feature (G and H keys) persistent between sessions in the last build as well? Just noticed yesterday while playing around ;)

BR
Michael

baldand

Quote from: ToS_Maverick on July 16, 2014, 09:03:28 AM
The brightness of the log output is correct now indeed! I'm mainly using OSX but was trying MlRawViewer on Linux as well and noticed the brightness difference in 1.1.6. Seems it was working correctly in Linux!
Does that only apply for the Win/Mac build?

Didn't test much else but it felt quite solid!
Was the WB/Exposure saving feature (G and H keys) persistent between sessions in the last build as well? Just noticed yesterday while playing around ;)
Michael

If you pulled from git during the last couple of weeks, you probably had the brightness fix even the version number was 1.1.6. I only bump the version number when making Win/Mac binary releases.

WB/Exposure saving was also in 1.1.6 (binary releases).

mario1000

Hi Baldand,

thanks for the update, everthing concerning the conversion of the MLV-Files works fine. But I would like to ask you whether it is possible to implement the following feature:
Every time I work with MLV and DROPPED FRAMES ALLOWED I get a black frame for this dropped frame. I think it would be very useful to replace this black frame with this picture:

http://www.uploadimages4free.com/browse_images/smpte_color_bars_ntsc_recreated_with_fml_test_card_maker-15600.html

I found a script for After Effects which makes use of this picture to find and replace missing frames in After Effects (Framerestorer: http://aescripts.com/pt_framerestorer/).

Best regards
Mario

baldand

Quote from: mario1000 on July 17, 2014, 08:33:20 PM
...
Every time I work with MLV and DROPPED FRAMES ALLOWED I get a black frame for this dropped frame. I think it would be very useful to replace this black frame with this picture:
...

That's an interesting idea. Perhaps you could add it as an enhancement for people to vote on in the issues list: https://bitbucket.org/baldand/mlrawviewer/issues

What does the replacing script use to replace missing frames? Does it just copy the previous frame?
Perhaps that would be a more useful option to add, e.g. to replace missing frames with the last good frame while exporting?

Danne

It seems it uses the time warp effect which could use different methods.
http://helpx.adobe.com/after-effects/using/time-effects.html#timewarp_effect

Whole Frames, duplicates the last frame
Frame Mix, creates a new frame by blending existing frames.

Danne

Hi Baldand. Quick question. I,ve been working with dual iso movie files and converting them with mlvmystic. Since they are developed I,d like to be able to export the dng,s once more to mov files with mlrawviewer going from mlvmystic DNG:s. However, mlvmystic dng:s seems to miss exif data and the mlvrawviewer defaults to exporting 25fps. My files has to be 24fps. Is there any way to set the fps manually?
Thanks

baldand

Quote from: Danne on July 22, 2014, 10:35:29 AM
...Is there any way to set the fps manually?

Not at the moment. It hasn't been needed so far since most played files have a frame rate embedded.
Please add this is an enhancement request to bitbucket.


Sidneywish

Sorry if this been answered before... any way to export to mov without the overexposed signs (colors) embedded in the video?

baldand

Quote from: Sidneywish on July 22, 2014, 06:02:35 PM
Sorry if this been answered before... any way to export to mov without the overexposed signs (colors) embedded in the video?

Do you mean you want an option to disable the highlight reconstruction, or something else? Can you give some example?

sgofferj

Can't export on kubuntu 14.04:

MOV export to /video/test/M23-0349_000001.MOV started
Opening MLV file /video/test/M23-0349.MLV
Black level: 2044 White level: 13000
FPS: 23.97 (23970/1000)
Audio frame count 0
Traceback (most recent call last):
  File "/home/sgofferj/mlrawviewer/ExportQueue.py", line 423, in doExportMov
    self.processExportMov(jobindex,filename,movfile,wavfile,startFrame,endFrame,audioOffset,rgbl,tm,matrix,preprocess)
  File "/home/sgofferj/mlrawviewer/ExportQueue.py", line 482, in processExportMov
    self.encoderProcess = subprocess.Popen(args,**kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
Export job failed:
Traceback (most recent call last):
  File "/home/sgofferj/mlrawviewer/ExportQueue.py", line 182, in run
    self.nextJob(self.jobs[self.currentjob])
  File "/home/sgofferj/mlrawviewer/ExportQueue.py", line 205, in nextJob
    self.doExportMov(job[0],jobArgs)
  File "/home/sgofferj/mlrawviewer/ExportQueue.py", line 430, in doExportMov
    if self.encoderProcess:
AttributeError: 'ExportQueue' object has no attribute 'encoderProcess'


Edit:
Can't export to MOV. Export to DNG works...
18+ years Linux user, wolf-fan, hobby photographer and -filmmaker
EOS 6D, EOS 7D

baldand

Quote from: sgofferj on July 23, 2014, 03:18:13 AM
...Can't export to MOV. Export to DNG works...

You need a static binary build of ffmpeg in the same directory as the source. Get it from here: http://johnvansickle.com/ffmpeg/

dmilligan

@baldand:

I've been working on saving silent-pics and full resolution silent pics in MLV containers. The data from the full resolution silent pics has OB areas included. When using MLRawViewer to open these MLVs, it doesn't seem to be respecting the 'active_area' fields of struct raw_info (in the RAWI chunk) and outputs DNGs with the OB black bars in them. mlv_dump processes these correctly. For more information and some sample files see: http://www.magiclantern.fm/forum/index.php?topic=12733.0

here's an example of what I'm talking about:
File Header (MLVI)
    Size        : 0x00000034
    Ver         : v2.0
    GUID        : 5214970244131067897
    FPS         : 0.066667
    File        : 0 / 0
    Frames Video: 6
    Frames Audio: 0
Block: RAWI
  Offset: 0x00000034
    Size: 180
    Time: 23.117000 ms
    Res:  4832x3201
    raw_info:
      api_version      0x00000001
      height           3201
      width            4832
      pitch            8456
      frame_size       0x019D0508
      bits_per_pixel   14
      black_level      1023
      white_level      12932
      active_area.y1   24
      active_area.x1   62
      active_area.y2   3201
      active_area.x2   4832

      exposure_bias    0, 0
      cfa_pattern      0x02010100
      calibration_ill  1

baldand

Quote from: dmilligan on July 23, 2014, 10:25:42 PM
I've been working on saving silent-pics and full resolution silent pics in MLV containers. The data from the full resolution silent pics has OB areas included. When using MLRawViewer to open these MLVs, it doesn't seem to be respecting the 'active_area' fields of struct raw_info...

@dmilligan thanks for the heads-up. I have been following the thread and already got one sample file earlier from @barepixels. I already guessed the active_area would become a problem. I've added this as an enhancement request for a future release: https://bitbucket.org/baldand/mlrawviewer/issue/83/should-support-active_area-params-of-mlv

One other issue I noted is the frame rate. If the capture frame rate is stored in the file, then it is played back at the speed it was captured, e.g. 0.1 FPS is 1 frame every 10 seconds. I don't think this is useful since normally you would want to watch the video at a normal framerate, not the capture rate. Perhaps the MLV should have a normal playback rate instead?

dmilligan

Quote from: baldand on July 23, 2014, 11:43:48 PM
One other issue I noted is the frame rate.
Yeah I was thinking about that. It's kind of a sticky situation. I figured it was more important to capture the information about what the real frame rate was, since you know it as the intervalometer is running, in case you ever needed it or wanted to know later. If you just put 24fps there or whatever, this information is lost (well, not totally lost, you could figure it out from the timestamps).

MA Visuals

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).

baldand

Quote from: MA Visuals on July 24, 2014, 02:11:59 AM
@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.

Yes, I think you are right. Frame rate override would probably be the way to go here after all. There is already enhancement request for that. https://bitbucket.org/baldand/mlrawviewer/issue/82/manual-framerate-support

Petter Sand

Hi! I use A 5d mark III with ML for 1.1.3 firmware and a build from the 20th of may.
I recently switched to MlRawviewer 1.1.7 and exported som MLV files. When I exported I noticed these red artifacts in the yellow parts of the workers clothes.
Does anyone have clue why? Could it be a wrong setting? The red artifacts are not there if I look at DNG´s.

See frame here: https://www.dropbox.com/s/4htmy976ni4c8j2/redareasx.jpg

Best Regards
Pettermannen

aace

Quote from: Petter Sand on July 26, 2014, 11:35:23 PM
Hi! I use A 5d mark III with ML for 1.1.3 firmware and a build from the 20th of may.
I recently switched to MlRawviewer 1.1.7 and exported som MLV files. When I exported I noticed these red artifacts in the yellow parts of the workers clothes.
Does anyone have clue why? Could it be a wrong setting? The red artifacts are not there if I look at DNG´s.

See frame here: https://www.dropbox.com/s/4htmy976ni4c8j2/redareasx.jpg

Best Regards
Pettermannen

This is similar to an issue I had. You can check out how I got around it here: https://vimeo.com/94709318 The trouble ticket is here: https://bitbucket.org/baldand/mlrawviewer/issue/66/overexposed-highlights-issue

sgofferj

Quote from: baldand on July 23, 2014, 04:16:36 PM
You need a static binary build of ffmpeg in the same directory as the source. Get it from here: http://johnvansickle.com/ffmpeg/
Still doesn't work :(. Now it writes a 185bytes big MOV file and then idles.
18+ years Linux user, wolf-fan, hobby photographer and -filmmaker
EOS 6D, EOS 7D

baldand

Quote from: sgofferj on July 27, 2014, 07:23:06 PM
Still doesn't work :(. Now it writes a 185bytes big MOV file and then idles.

My guess is that you are using GLUT rather than GLFW as the graphics toolkit. Unfortunately a few things don't work with GLUT - I think the MOV export is one of them.

Doubly unfortunately, MlRawViewer is using the latest version of glfw3 - 3.1 - which you will need to build for yourself from source from the git tree here: https://github.com/glfw/glfw.git

You will need cmake to build it. Make a "build" directory under the source tree, go in there and do "cmake ..". Then edit the generated CMakeCache.txt and change the line "BUILD_SHARED_LIBS:BOOL=ON" from OFF to ON.
Then build with "make", and copy the file "libglfw.so.3.1" into the mlrawviewer source directory with the name "libglfw.so.3"

After that your mov export should work.

Sorry for all the trouble. Hopefully in future, when GLFW3.1 is released and packaged by distros, this step will become as easy as "sudo apt-get install libglfw3".

baldand

Quote from: Petter Sand on July 26, 2014, 11:35:23 PM
...I recently switched to MlRawviewer 1.1.7 and exported som MLV files. When I exported I noticed these red artifacts in the yellow parts of the workers clothes.
Does anyone have clue why? Could it be a wrong setting? The red artifacts are not there if I look at DNG´s.

There is one thing to try, but I doubt it will help much. Turn on the stripe reduction (clip the icon with stripes) as this actually uses a slightly different highlight reconstruction algorithm.

However, the basic problem is that you have a green object with an overexposed (clipped) green channel, and the overall scene white balance is unrelated to that colour. It's not possible (AFAIK) to recover the colour correctly in that kind of case with any simple highlight reconstruction algorithm.

I suggest avoiding overexposing green objects (especially leaves in sunlight!) in future.

(I always keep an eye on the Raw histogram while recording and step up my ND filter to make sure none of those bright objects that are not in the sky are overexposed.)

sgofferj

Quote from: baldand on July 27, 2014, 08:40:47 PM
My guess is that you are using GLUT rather than GLFW as the graphics toolkit. Unfortunately a few things don't work with GLUT - I think the MOV export is one of them.

Doubly unfortunately, MlRawViewer is using the latest version of glfw3 - 3.1 - which you will need to build for yourself from source from the git tree here: https://github.com/glfw/glfw.git

You will need cmake to build it. Make a "build" directory under the source tree, go in there and do "cmake ..". Then edit the generated CMakeCache.txt and change the line "BUILD_SHARED_LIBS:BOOL=ON" from OFF to ON.
Then build with "make", and copy the file "libglfw.so.3.1" into the mlrawviewer source directory with the name "libglfw.so.3"

After that your mov export should work.

Sorry for all the trouble. Hopefully in future, when GLFW3.1 is released and packaged by distros, this step will become as easy as "sudo apt-get install libglfw3".

Ok, I'll test but I have to check first if that messes up my system. A number of things are running on openGL. No worries about the "trouble" - it's none. I like to test stuff and with the price going half this summer, I'll likely get myself a BMPCC for that $500... So my 6D would be for photos only then :).
18+ years Linux user, wolf-fan, hobby photographer and -filmmaker
EOS 6D, EOS 7D