Messages

Great to see MlrawViewer is still being worked on. Is there a Windows Release with the added functionality on the horizon?

I am in no position to maintain the windows build due to lack of expertise, but you're welcome to give it a try :-)
The latest sources are found in
https://bitbucket.org/hwdbk/mlrawviewer/branch/fix_focus_pixels

Can someone please help me figure out how to remove this band (or lines or whatever) on my footage? My files render into DNG sequences and videos just fine but these lines are not removed throught out the process. I have seen other people use mlrawviewer and produce videos without these lines or horizontal bands. PLEASE I NEED YOUR HELP

This looks like a Dual-ISO shot. I don't think MlRawViewer handles Dual-ISO in a special way, so you'd need to postprocess the DNGs yourself, or use alternative tools like mlv_dump directly.

Are there any other programs that can read or transcode MLV files? I've just installed and get the following exception:

Code Select Expand

Traceback (most recent call last):
  File "/home/mike/Downloads/magic lantern/baldand-mlrawviewer-e7abaaf4cf9b/GLComputeGLFW.py", line 315, in __draw
    self.onDraw(w,h)
  File "/home/mike/Downloads/magic lantern/baldand-mlrawviewer-e7abaaf4cf9b/Viewer.py", line 374, in onDraw
    self.renderScenes()
  File "/home/mike/Downloads/magic lantern/baldand-mlrawviewer-e7abaaf4cf9b/GLComputeGLFW.py", line 265, in renderScenes
    s.prepareToRender()
  File "/home/mike/Downloads/magic lantern/baldand-mlrawviewer-e7abaaf4cf9b/Display.py", line 447, in prepareToRender
    self.iconBackground.rectangle(80,height,rgba=(0.0,0.0,0.0,0.25))
  File "/home/mike/Downloads/magic lantern/baldand-mlrawviewer-e7abaaf4cf9b/GLComputeUI.py", line 295, in rectangle
    self.setVab(vertices)
  File "/home/mike/Downloads/magic lantern/baldand-mlrawviewer-e7abaaf4cf9b/GLComputeUI.py", line 289, in setVab
    self.svbo.update(vertices,self.svbobase)
  File "/home/mike/Downloads/magic lantern/baldand-mlrawviewer-e7abaaf4cf9b/GLComputeUI.py", line 90, in update
    self.vbo[ow:(ow+len(data))] = data
  File "/usr/lib/python2.7/dist-packages/OpenGL/arrays/vbo.py", line 262, in __setitem__
    size = ArrayDatatype.arrayByteCount( self.data[0] )
  File "/usr/lib/python2.7/dist-packages/OpenGL/arrays/arraydatatype.py", line 184, in arrayByteCount
    return cls.getHandler(value).arrayByteCount( value )
  File "/usr/lib/python2.7/dist-packages/OpenGL/arrays/arraydatatype.py", line 53, in __call__
    typ.__module__, type.__name__, repr(value)[:50]
TypeError: No array-type handler for type numpy.type (value: 0.0) registered

It looks to me that the numerical math library numpy is not installed properly on your system.
Try sudo pip install numpy or take a look at https://scipy.org/install.html

I would also recommend to no longer use the baldand release, but the latest from
https://bitbucket.org/hwdbk/mlrawviewer/branches/
which is
https://bitbucket.org/hwdbk/mlrawviewer/branch/fix_focus_pixels

Cheers, Henk

On the .MOV export not working (MacOS X) from a built version of  MlRawViewer, I found the following glitch: if ffmpeg is updated on your machine (I use MacPorts), the old binary copied into the MlRawViewer.app/Contents/MacOS/ffmpeg path for some reason no longer works. In mlrawviewer.log I get

Code Select Expand

Traceback (most recent call last):
  File "ExportQueue.py", line 796, in stdoutWriter
IOError: [Errno 32] Broken pipe
repeated 11 times. The export process stops after showing 0.00% for a couple of seconds. I think this means that the dynamic libraries and ffmpeg executable somehow go together, and also that a distributed version of the MlRawViewer.app with ffmpeg inside not necessarily works.
This problem is not related (I think) to the 'ffmpeg doesn't get data' problem where the export process stops at a couple of percent and then stalls.
The saga continues...

@Rob: what you're experiencing is what I can reproduce ON LINUX. So far, I've been able to pinpoint it to stdin for the ffmpeg process not coming through. I (sort of) ruled out ffmpeg itself because the problem (stalling output) occurs with ffmpeg 2.7 as well with ffmpeg 3.3. So it must have to do with the Popen stdin piping or the thread that feeds (writes to) stdin of ffmpeg. In fact, if I fake ffmpeg with a script, I can see that no data comes in at all on stdin. Any suggestions are welcome because I am not familiar with Pyton Popen.

@daycon: MOV rendering should work on Mac OS (it does for several users, not just me), read the posts, but not for Linux, it seems. DNG rendering should work if you use the latest commit; in the first commit it didn't, sorry. I fixed it by writing 16-bit DNGs, that seems to work (in fact, if I want these DNGs to work in Adobe Premiere, only the 16-bit ones seem to work anyway). If I have time I will look at this issue.

Thanks.

@DeafEyeJedi: I'm seeng the striped output on dusl-iso 14bit raw, nothing stranger than expected. Which OS are you on? Could it be that what you see depends on the zoom/scale/size of the window? AFAIK, Danne is working on essentially the same version. The branches haven't divergered much yet

@Rob: yes, I know MOV export doesn't work on Linux, no pointer as to why ffmpeg doesn't receive the raw frames from stdin. Any help there is welcome.

so i tried it. 1.5 and...its really great. maybe some of the best looking images I've ever gotten out of a magic lantern post production tool. but...i see focus pixels! god damn focus pixels always ruin everything. I mean they are much worse with the stripe correction turned off. if you turn it on they go away a little bit. but they are still there. I know this is another guys software but any way to tweek it? also the mov export doesn't seem to work. the dng works fine. feel like i could use my eos m for a film if i could just find the right post production tools...excited for dannes new switch app with gui as well. currently using switch. thanks guys.

On my Ubuntu, I can't get MOV export going either (DNG works). It does launch an ffmpeg subprocess with the right parameters (you can see with ps -efww), but that process stalls - I guess it's not getting raw frames through stdin. Was looking at it yesterday evening (subprocess class, Popen) but no apparent solution yet.
On the focus pixels, I think I know what you mean, that regardless of the AMaZEing demosaicing algorithm, still some pixellation occurs, for instance between tree leaves. If you mean a more general pixellation, please try the Q button and see if AMaZE improves things (PS> AMaZE is always on when exporting to MOV, always off (RAW mode) when exporting to DNG). Please could you post an image of your artefact?

For those of you who would wish to try:

https://bitbucket.org/hwdbk/mlrawviewer/downloads/MlRawViewer%201.5.0%20(Commit%203d7c98f,%20Mac%20OS%20X%20build).zip

No ffmpeg inside due to licensing issues, see Danne's instructions above; ffmpeg goes into Contents/MacOS or Contents/MacOS/extlibs - can't figure out why one sometimes works and the other not, or reverse... Just try out with the E key (export to MOV) and you'll quickly find out.

Yes, it seems that code was written, then split up (for instance demosaic = predemosaic+lowlevel_demosaic+postdemosaic, but the original demosaic was not taken down - lots of duplication and code specifically for 12 or 14 bit, or worse, for an implied bit depth, not taking bitsPerSample from the file into account. So, a lot of that has been cleaned up and I have a much better understanding of what the program does.

On Windows: it should work but I'm in no position to try this build. I'm on Mac OS and Ubuntu. Looking for a volunteer to build the Windows version and report back here.

/Henk

Hi all,

I've created a new version over the weekend,

- bitunpack: treat code with generic bit depth - now works with any depth 7-16 (tested with 7,8,9,11,13,15,16 bits created with mlv_dump, as these bit depths are not created from the camera); 10,12 and 14 from regular camera MLVs.
- fixed LJ92 decoding from within the Demosaic function (was not called and caused garbled output, basically showing the raw compressed data rather than the decompressed image)
- major cleanup of MlRaw.py - lots of code was never called
- code now also tested on Ubuntu, see README

https://bitbucket.org/hwdbk/mlrawviewer/commits/3d7c98f3a875d66451217aa212ea8a4c9d409d3c

Tried with a clean Ubuntu VM (Ubuntu Linux 16.04):

All I had to do to get it going was:

Code Select Expand

- sudo apt-get install python-opengl
- sudo apt-get install python-numpy
- sudo apt-get install python-dev        (to be able to compile bitunpack etc.)
- sudo apt install python-pip
- pip install scandir
- sudo apt install ffmpeg
in the mlrawviewer directory:
- python setup.py build
- cp ./build/lib.linux-x86_64-2.7/bitunpack.so .
and then run the program from the command line:
- python mlrawviewer.py <MLV-file.MLV>


Quirks: Yes, I can reproduce the garbled output when High Quality demosaicing (AMaZE) is used in combination with LJPEG-compressed MLVs and in that mode. In that mode, the app also shows something of memory leak in 'top'. I'll look into that, maybe it's related.
The other quirks (TAB for fullscreen, L for looping the clip), I can't reproduce and work properly on my VM.

[Q] turns the AMaZE demosaicing on and off. There is a code branch that does the decoding/decompression and demosaicing in one go - and still uses the quite-not-working bitunpack code. On my machine (Mac OS), this code never gets called because it first explicitly decodes the frame in 16 bit samples, and _then_ calls the demosaicing function.

Fixing the other 'broken' bitunpack readers (there were some 7 copies of approx the same code in there) is the next thing to do. Or is it getting my Ubunty VM up and running again? :-)

Fingers crossed:

https://bitbucket.org/hwdbk/mlrawviewer/branch/raw_video_10bit_12bit_lj92compressed

and some background information:
https://bitbucket.org/hwdbk/mlrawviewer/commits/6ab1892e50b82ba9307256b6ef4b14f06e2c518a?at=raw_video_10bit_12bit_lj92compressed

Very concise 'howto build' in the README

Henk

Yeah, the headache of converting everything back to 14-bit MLV or DNG was just too much for me. And, it was an excellent excuse for me to peek under the hood of this piece of software (and mlv_dump, where it al starts, of course). So, the two main reasons for giving this a shot was a) to play whatever I recorded without further conversion and b) streamline the workflow in creating an edit-ready ProRes copy straight off the MLV (then, mlrawviewer would be some sort of speedgrade).

Compiling: yes, that was perhaps the steepest part of the learning curve - I had never programmed in Python before (I'm a C,C++,C#,bash guy still getting irritated about the dumb indents) but I kept a record of what I did to get it going (perhaps the cmake-glfw3-xcode exercise was the worst of it all). I'll include a howto.txt, but can't verify if it is any good: once you've installed all the modules and tools, there's no going back without a full restore and retry. And there's that other thing with distributing ffmpeg as part of the package that I am not comfortable with....

I'll see about the bitbucket. What you describe about forking in one's own repository makes sense and should work.

I've been working on updating mlrawviewer 1.4.3 to also support 10 and 12-bit raw MLV files, and MLV files that use in-camera LJPEG92 compression (so-called 'compressed RAW' MLV files).

So far, I've been able to fix MlRaw.py and bitunpack.c in such a way that, on my computer, mlrawviewer now plays all types of files I can get out of the current crop_rec_4k branch, i.e.
- 10, 12, and 14 bit raw MLV
- the 8-11, 12 and 14 bit compressed (LJPEG92) MLVs
but also
- compressed and uncompressed DNGs created by mlv_dump (the DNGs are 14-bits - don't know how to create 10 or 12-bits DNGs).

I currently work on MacOS Sierra but I see no reason why this wouldn't work on Windows - it's just that I don't have the dev env installed on Win.

Now the problem: I don't seem to be able to create a pull request on Andrew Baldwin's bitbucket repository. Is there anyone who can help me with this?

/Henk