Messages

I have checked the exported .mov but it is 422 (HQ) Is this expected behaviour?

I haven't checked that. On Linux, the same parameters produce 10bit 444. I'll take a look and see what's going on.

Thanks for the clarification – I'll persevere!

@baldand – PS Should the 'Frameworks' folder inside the package be empty? Mine is!

Yes, frameworks folder should be empty.

Fantastic!!!
How to install the ffmpeg?Unzip and click on it?

The Mac install package includes ffmpeg.

For Windows or Linux you should download a version from http://ffmpeg.org/download.html

@baldand

Thank you for helping out Mac! My install crashes as soon as I drag a .raw file onto the app icon. Do I still need to install Python etc. before I install this app? I'm a little confused – sorry!

I'm on OSX 10.7.5

Thanks!

It should include everything needed - no need to install a python unless you are building it from source. I've only been able to test on 10.9/Mavericks. I really have no idea will this package work at all on an earlier OS X version. (Mavericks is a free upgrade, and you should be able to upgrade direct from 10.7.x)

@Danne, thanks - can you post a bit more info the issue report if possible. See the responses there.

I had a go at making an installable version of the app for Mac.

https://bitbucket.org/baldand/mlrawviewer/downloads/MlRawViewer_1.0.1_alpha.dmg

This was made using pyinstaller, and it has been tested on a couple of machines running 10.9 (Mavericks).

Once it is installed to you Application directory, you should be able to click on a MLV or RAW file to open them with it. Alternatively, drag the raw file onto the App icon to open it.

It's mostly keyboard driven at the moment - keys are described here: https://bitbucket.org/baldand/mlrawviewer/overview

Addtionally: ESC exits the app.

There is no way to supply a file name for the ProRes encoding, so by default when you press E, it will encode to the same filename as the source with .MOV appended.

Please report crashes/problems/issues to https://bitbucket.org/baldand/mlrawviewer/overview using the Issues button.

Questions/feature requests etc can be here.

Mac update: I just tested the latest version on Mac and it can be made to work with small changes.

I know these steps are not suitable for all Mac users, but maybe an installable package will come later as a result of this.

I used OSX Mavericks with the system python. Assuming you have git and the command line compiler....clone the source code.

Install pyOpenGL like this:

sudo easy_install pip && sudo pip install pyOpenGL

You should already have numpy installed (I did, and I hadn't installed it myself).

Then you need to edit setup.py to remove the 2 openmp references. Clang does not yet support openmp (maybe there is a way to use gcc instead and hence get openmp and faster CPU demosaicing - I'm not sure).

Then:

Code Select Expand


python setup.py build
ln -s build/lib.macosx-10.9-intel-2.7/bitunpack.so .


Download ffmpeg static binary from http://www.evermeet.cx/ffmpeg/ and:

Code Select Expand


7z x ffmpeg-2.1.1.7z

(if you need 7z, use homebrew and "brew install p7zip")

Finally from the source dir:

python mlrawviewer.py /Volumes/RAWVIDEOS/M01-2345.MLV MyEncodedFilm.MOV

I was able to encode a ProRes MOV and play it back fine with Quicktime.

I pushed a small change now so it will use an ffmpeg in the same directory as the script in preference to one on the path.

I strongly recommend downloading a suitable static binary from one of the links on http://www.ffmpeg.org/download.html and putting it to the same directory as mlrawviewer.py

That's what I did in order to get a version which could encode 10bit 444 ProRes.

I added encoding to ProRes using ffmpeg. It needs a newish versions of ffmpeg for that to work. Only tested on Linux so far.

To use it, optionally add an output name as a 2nd command line argument.
Then adjust the white balance and brightness, find the starting frame, and press "E".
To end encoding, press "E" again.
It will also stop automatically at the end of the file.

I can test an exe on win 8 if you can provide one?

Thanks. I will take closer look at pyinstaller soon for Win/Mac packaging. Of course it might be good if you or another Win8 user could try it first with https://code.google.com/p/winpython/ to see does it even work.

I just pushed a fix for the crash on Windows+mingw32 with CPU demosaicing. For me the current tip is now working fine on Win7.

I will try also with Mac tomorrow to see if there are any new problems there (it was working earlier).

Ok, I applied the patch. Glad to hear it is working now.

(Proper Dual ISO playback support would be great, even if I would never be able to make use of it with my 7D... sob)

No, it does work on Windows. But getting it working needs a few steps.

First, I can't say anything about Windows 8 as I haven't used it at all. But I know that there have been problems with OpenGL based apps there. So Windows 8 might be out unless you know you have working OpenGL.

However, I just tested the latest code on an ACER Aspire One 522 with AMD C-50 & integrated Radeon 6250 with Win7 whatever version it came with - 32bit, limited to 2Gbytes of RAM(!??!)

I used WinPython 2.7.5.3 https://code.google.com/p/winpython/downloads/detail?name=WinPython-32bit-2.7.5.3.exe

I had to add the included mingw to the path, e.g.:

set PATH=C:\WinPython-32bit-2.7.5.3\tools\mingw32\bin;%PATH%

Then (from the mlrawviewer direcory) I built the bitunpack module:

\WinPython-32bit-2.7.5.3\python-2.7.5\python.exe setup.py build_ext -c mingw32 --inplace

Finally I ran it:

\WinPython-32bit-2.7.5.3\python-2.7.5\python.exe mlrawviewer.py \Users\andrew\Downloads\mlr\M15-1647.RAW

The video comes up and plays. I can navigate with cursor keys, change brightness, fullscreen with TAB.

But I also had some problems which would need investigating by someone -> it crashed whenever it tried to use AMaZE. Which means pausing, or Q button.

I just pushed a change to remove the need for uploading float textures in the CPU demosaicing case.

It means doing a little more work in the CPU-side, but should work now in more environments.

Ok, let me try and rework it to support this setup.

I would take a wild guess that this is texture-upload related again.

The output from the CPU demosaicing is floating point, so we need to be able to upload in RGB float format to an RGB texture (instead of 16 bit uint as with bayer data).

Looking again at the patches you made, was the conclusion that your Intel GPU doesn't support floating point textures at all?

Ok, AMaZE is in.

It's now used to display frames when paused, or during playback if explicitly turned on with the Q key.

I will try to add encoding output next (which will also use AMaZE).

Thanks for all the great contributions so far. It's already working way better than just a few days ago.

Next up , I'm planning to integrate CPU-based AMaZE demosaicing (which is much slower than GPU demosaicing, but better looking) for using to export sections of a video through ffmpeg, e.g. to ProRes files.

See also the thread about MlRawViewer, which is cross-platform (python), but quite focused on Linux:

http://www.magiclantern.fm/forum/index.php?topic=9560.msg91165#msg91165

I just pushed a change for that line to use R16 internally, which should be ok for the raw bayer data.
Would be good to know if your env now fails on the next texture create which is RGB float.

What kind of platform are you running on, e.g.

Native Linux or under a VM? (VirtualBox/VMWare often have more limited OpenGL implementations)

What kind of graphics card/drivers - Intel, AMD, NVIDIA?

For reference, I've used it on (low end integrated) AMD & (mid range) NVIDIA, but not Intel (though I think it should generally work also there).

My suspicion here is the GL_R32F as the internal format. Your environment might not support floating point textures. One thing to try might be to change that to R16F or just R16 and see if that helps.

(moved to top post)

@baldand:

do you pre-index the MLV blocks before processing?

No. I tried that at first, but it was a bit painful to wait a few seconds each time while it indexed e.g. a 20Gb set of files.

Now it builds an internal temporary index as it goes, and also tries to preload the next frame while the current one is rendered. I have a slighty better version not yet pushed which can do more look-ahead.

Of course it would be good if it would generate and persist an IDX file at the same time.

Bug:
When using nearest to de-mosaic instead of bi-linear, everything comes out blue


Found the solution:
You didnt "-black" on the other colours.

Thanks! I pushed the fix for this now.

I'm using a simple Reinhard global tone map function (x/(x+1)) for the display, so the brightness value needed depends very much on the content. At the moment I tend to just go in and modify the value manually for each clip I view.

A step up from that would be to make it a command line parameter, and a step up from that would be to let you change it while viewing the clip, and a step up from that would be to measure a histogram of the data and calculate a suitable value along with auto colour balance and the rest. All possible, but needs a bit more development.

Contributions/pull requests most welcome :-)

for me I got;

Code Select Expand


cosmo@cosmo:~/Downloads/mlrawviewer-1-0-0$ ./mlrawviewer.py ~/Videos/M12-1345.MLV
Falling back to Numpy for bit unpacking operations.
Consider compiling bitunpack module for faster conversion.
Opening MLV file /home/cosmo/Videos/M12-1345.MLV
Could not open file /home/cosmo/Videos/M12-1345.MLV. Error:1280922707


and with the bitunpack.so

Code Select Expand


cosmo@cosmo:~/Downloads/mlrawviewer-1-0-0$ ./mlrawviewer.py ~/Videos/M12-1345.MLV
Opening MLV file /home/cosmo/Videos/M12-1345.MLV
Could not open file /home/cosmo/Videos/M12-1345.MLV. Error:1280922707


That was due to an unrecognised block type in the MLV file.

Now I got round to putting the source code to bitbucket, and fixing that bug. If you have a chance to pull a new version from there, it might work for you now.

https://bitbucket.org/baldand/mlrawviewer

I'm guessing you tried to run it with a Python 3.x runtime (which doens't support that Exception syntax)?

If so, try a Python 2.x runtime, like 2.7.6 from http://www.python.org/getit/

You may still have compiler or module troubles. When I tested it on Windows, I actually used the WinPython distribution, which includes all needed external modules, and also mingw for compiling the bitunpack module. See the end of my blog post for pointers: http://thndl.com/?20

Did you make that program baldand (haven't it tested yet).

Yes, I did.