Messages

For anyone testing 1.4.0:

After trying it, even if you don't have any problems, please write a short report here describing your environment and what features you tested.

This will greatly speed up the process to stabilise the 1.4.x series and the new browser feature.

Thanks.

however, have you also  had time to integrate an optimized vertical stripes correction code for canon 5d mk3? that would be an important step forward. (im my direction

No.

[VERY UNSTABLE NEW VERSION 1.4.0 NEEDS EARLY TESTING]

VERY UNSTABLE NEW VERSION 1.4.0 NEEDS EARLY TESTING

I have made builds of the bleeding edge MlRawViewer code as version 1.4.0, available from the usual place: https://bitbucket.org/baldand/mlrawviewer/downloads

I do not recommend that you try these unless you are ready to experience many new bugs and give me detailed reports about them.

It has a major change from the previous releases. The old external file dialogs have been replaced by an integrated browser view. This affects choosing files, LUTs, and the export directory.

The browser can be operated with keys or mouse. Mouse operation should be quite obvious. Keyboard shortcuts are Shift to go up a folder, Enter to enter a folder or choose a file and Backspace to close the browser. Otherwise cursor keys move the focus.

To enter the browser from the normal viewer, click the metadata window, or press Backspace.

If you run MlRawViewer with no file, it will start in the browser.

I'm particularly interested to hear reports about how it behaves for you when you go up to the root folder e.g. to change disks. It tries to scan the file tree for candidate files so it does not show folders which do not contain anything relevant. But that approach may be too slow to use in practice - let me know what you think.

Where should I post a crash report?

Thanks!

ST

https://bitbucket.org/baldand/mlrawviewer/issues

Please provide as much detail as possible, including the mlrawviewer.log file and any system crash log.

Btw, this is a bit out of the way, but would it have any performance advantage on 64 bit systems to run a 64 bit version of this? If it is, would be nice to have a 64 bit version of this too. :3

I don't know for sure, but I somehow doubt it would make much difference performance-wise since most work is done on the GPU, and the only CPU heavy bit (HQ demosaicing) is mostly SSE code anyway.

Anyway, the source code is available from https://bitbucket.org/baldand/mlrawviewer/overview so someone is welcome to try it out making a build with a 64bit python windows runtime and measure if there is any speed advantage.

650d user here. Does this have Chromasoothing or any way to deal with the pink dot issue?
If not would it be possible to integrate it?

There is a pre-processing step which can suppress some of the pink dots as part of the stripe correction.
However, it's not really fully suited to the needs of "pink dot cameras". It would really need a calibration step to train it with e.g. a defocused images, and then reuse that training data. At the moment it just tries to find that data from each scene. So, YMMV.

MlRawViewer 1.3.4 now available

Get it from the downloads page: https://bitbucket.org/baldand/mlrawviewer/downloads

This should behave almost the same as 1.3.3 with a couple of small changes:

- Fixes a bug with handling spanning RAW files. Previously frames spread across two files were treated as missing frames. They should now be reconstructured correctly.
- Adds a feature to hide the overlay. Press Shift-TAB to hide the overlay even while paused, and Shift-TAB again to show it.

@Baldand

I´m using 5D III 1920x1080 25P and OSX

a)  - Is normal than version 1.2.3 export a Raw file in DNG files at 3Gb and version 1.3.3  just 1,3 GB?
I´ve note that each DNG before was 4,2 MB and now around 1.2 !



b) - If this is normal, Have I lost too much quality?

c) If this is normal, and the quality is the same, can I reduce all my DNGs - without RAW files - to the new compressed files?


Thanks!

Lossless jpeg typically compresses to around 50-60% of the original (14bit) size. The old dng export was actually adding 2 bits per pixel (14 to 16) so the ratio is better compared to those.

Your numbers sound quite small, bit it depends on content. If you have lots of blurred/out of focus content, the compression will work better.

I wouldn't recommend deleting original RAW or MLV files. Later I hope that MLV will support also lossless jpeg for archiving.

Good news. I've found the bug that was causing black frames in spanning RAW files. I wasn't correctly reassembling the frames cut across two files. Fix is now in git and will be included in 1.3.4 build in a few days.

I'm having a big issue.
When I convert to dng or watch my raw file taken with differents cards and differents resolutions in MlRawViewer 1.3.3 I get a lot of black/corrupted frame. If I convert the raw file with rawmagic everything goes fine. If I try to use 1.2.3 the conversion stop at the first black frame (I haven't tested with a corrupted one)

Here you can find two example, https://www.mediafire.com/?ukgavha2bqgtf5g one is taken from a video shooted a few days ago and the other from a test that I've done today while trying to understand the whole stuff.

What could be the problem? 

My specs:

I checked the black frame DNG, and there is nothing wrong with it. Apart from being black.

MlRawViewer should insert black frames when it thinks there is a frame missing from the original file (to keep audio sync correct).

The question here for me is whether MlRawViewer is making a mistake, and not finding a frame that is there in the file, or if other tools are just masking missing frames in a different way, e.g. skipping them or duplicating previous frames. But I can't answer that without having the original raw file to check.

Hi, baldand

1.3.3 has some errors running on Windows 8.1. x64.
I think you only test it on WINDOWS 7.

I used 3 PCs using windows 8.1 x64 genuine.
EVERY 3 PCs showed the same results. (No starting)


I found some clue. I hope this will help.

Windows 8.1 Event viewer
SideBySide Error (even ID 35)

Can not make an activation context on "mlrawviewer_1_3_3\mlrawviewer.exe.Manifest" file.
There are errors in Manifest or 4th line on "mlrawviewer_1_3_3\mlrawviewer.exe.Manifest" policy file.
The Component ID in manifest is not identified with required ID.

Reference: Microsoft.VC90.MFC,provessorArchitecture="x86,publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"

Definition: Microsoft.VC90.MFC,provessorArchitecture="x86,publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.6161"

For more information use sxstrace.exe.


Thank you for you hard working.

I don't believe this is a generic win8.1 issue as I am building and testing on Win8.1 these days. I'm not an expert on Windows app issues, but it sounds like a kind of site app policy checking issue. It's anyway not something I'm able to reproduce or debug.

@DeafEyeJedi many thanks for testing that. It's very useful to know that the most recent version of PPCC is working ok with MlRawViewer 1.3.3 compressed DNGs

@DavidSh which version of Premiere CC are you using? If not the latest, can you upgrade?

It sounds like it's probably a bug in Premiere. If that's the case, I won't be fixing it.

It sounds like Premiere CC doesn't like compressed DNGs, or at least it doesn't like MlRawViewer's compressed DNGs (even though they are fine in ACR, Resolve and all Linux/dcraw-derived tools).

Can anyone else confirm the same problem?

Any idea why premiere cc cannot read the CDng?
It says "The file appear to have no media data

Can you give more details please.
Is it a problem with all DNGs or just one file?
Did the same MLV file work when exported to DNG with 1.2.3?

1.3.3 is now the stable & recommended version of MlRawViewer. See the top post for links and usage.

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

Would it be possible to have the choice to have the mrx files not created or created all in a specific directory? If I've get it right they are for having options saved, I don't really need them and they give a messy look to all the folders

Everything else feels good.

Sorry, but I don't think that is going to change.

See the downloads page: https://bitbucket.org/baldand/mlrawviewer/downloads

Do you see all black frames or just additional frames? Drop frame setting does not apply to export.

Those 1D LUTs are all built in. You don't need to import or update them in MlRawViewer. The zip is only for reference to have same the LUTs available as .cube files.

Would it be possible to get access to the 1D Luts for Linear to Log-C, C-Log, S-log, and S-log2? AFAIK they are not included in the separate Lut download.  Would be very useful for compatibility tests.

Thank you 

I updated the LUT zip now:

https://bitbucket.org/baldand/mlrawviewer/downloads/MlRawViewer_LUTS_1_1.zip

An hour and 28 minutes later...

@DeafEyeJedi thanks for checking this out, but at the moment I haven't seen any clear evidence of a problem. @timbytheriver confirmed that his system was working fine, and there have been no other reports of a similar issue yet. By clear report I would expect you to write something like "1.3.2 export took 20 minutes, 1.3.3 export same settings took 60 minutes, 1.3.3 testing export same settings took 60 minutes". The screenshots are not so helpful.

By the way, I don't recommend you do concurrent exports from 2 instances of MlRawViewer. They will be competing for all the resources of your system and the result is likely to be slower than running 2 exports in sequence.

Silly question, where can I find 1.3.2?

Not silly. I deleted it from bitbucket already.

Why:

I have changed the development model recently so that there is a concurrent "stable" version and "testing" version.
The stable version (currently 1.2.3 - see the current title of the thread above ^) is the one I recommend people to use as it has had the most usage and has quite well known behaviour and features.
The testing version (currently 1.3.3) is the one which has more features but also more new bugs than the stable version. When I'm happy that the testing version is an improvement on the stable version, it will become the new stable version.
Each new minor version number indicates a new development series, which should hopefully finish with a stable version.
A consequence of this is that I don't want to leave multiple testing versions available for people. Either they should be using the latest stable version, or the latest testing version. Anything in between is likely to have more bugs.

At the moment I'm hoping 1.3.3 will become the new stable version soon.

I've experiences performance regression in dng export too. I don't know if I can test it today but I've not changed anything.

That's expected in DNG export at least compared to 1.2.x series as the DNGs are now compressed. Although the slow-down should not be extreme.

The issue here was with MOV rendering/export.

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

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

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)
- 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
- Time taken to encode same files with same settings with new version

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.

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

Well done to all the developers of MLRawViewer! 

Now I'm may be about to ask a silly question!  I have been happily using v1.1.6, but decided the other day to update to v 1.2.3.  But when I unzipped the file (I'm running win7), nothing would work.  The exe file does not run, nor if I drop an MLV file on it does anything happen. And no LOG file is produced in my User directory.  On further investigation, v1.1.7 will work, but not 1.2.0 or anything later (where there has obviously been a change since there were only 3 files in the zip folder up to v1.1.7, but 878 files for all later versions).  Am I doing something incredibly stupid?

Thanks.

It should have created a ".mlrawviewer" dir in your /Users/<username> folder. The log file is in there. After checking it, try deleting the whole dir and running again.