Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bouncyball

Pages: 1 2 [3] 4 5 ... 34
RBF chroma denoise is much better then chroma blur though! Have you tried it? I find it much better. But most of the time I don't do any chroma noise reduction, don't like smeared colours.
Yup, sometimes chroma blur is good at the same time with RBF to further clean the chroma noise but very small amount of blurring have to be applied to not smear/wash colors out.

Also I did spend about an hour messing with the white balance function, so this could change soon.
As for the icon. I am thinking, soon will have an answer,.
Eagerly awaiting for changes! :D

Yes, I also like that one... just the slider could be there aditionally, like here:
I think app icon should be pure "3color + slider" without any ".MLV", application name etc...

All Linux flavors have such a large desktop managers + file managers range that I suspect this task gonna be mission impossible. We could just provide separate icon files for Linux and user can do with them whatever he wants.

Edit: I'm Linux user btw :P (Ubuntu Linux mostly)

The last shown proposal was the best I've seen since the discussion started. But I also like the slider splitting the colors. Text would be nice for the about box, for the app icon we don't need it. For files the ".MLV" and the sheet around would be okay IMO.

Yes in taskbar the border is really unnecessary

What do you think? RGB is there, could be 4 channel bayer RGGB though :P

Slider in this logo was good. Splitting colors above it. I liked it.

There is no need (even not recommended) to have whole application name in logo.

Or this should be done entirely as a letters logo. And this is another story because it must be as clean and visible as possible.


I like white ones.

The original logo is not bad as logo, but it looks not so good in system tray or status bar (win/linux) even in dock on MacOS. It is very complex and not suitable for small resolution at all.

Just MLV? All files are 15 GB...
Yes, that exact MLV which causes this error. Do not cut it, I need the original.

Edit: if you meant one clip is .MLV and subsequent .M01 ... .Mxx = 15GB, then eh... yup, I need whole clip ;)

I fixed it with mlvfs.exe (version "May 6 2017").
Strange. Give me that MLV to debug this issue please.

Yes @masc's right. Please try 1.9 non static 64 build and report back.

I thought I would let anyone else having the issue with MLVApp1.10 crashing on Windows 10 64
Could you be more specific about crashes?
At least:
1. can not be started, crashes imeadiately
2. runs but with random crashes
3. runs but crashes during export

P.S. Windows 64bit users please report back your experience.

This is to be expected. MLVApp is a video tool. Normally a video has many frames and the frames of one clip are sorted into a folder.
Yes. In case when all MLVs are 1 frame (raw2mlv converted) files. I thought DeafEye was talking about regular MLV exporting to jpeg2000 :D

There is already a discussion going on. But work hasn't been started.
Deleting the frame is a bad idea for video, because audio gets out of sync. For the new photo features it maybe makes more sense...
I've got a simple proposition. Let's assume we are searching for bad/pink frames and there are a FEW of them not many. So we can just manually mark them in the mlvapp as such (bad) frames, save this info to some array and use it during export, skipping or duplicating before/after frame or whatever.

There should be a possibility to auto detect frames like this though, with some % accuracy.

When we export JPEG's (JPEG200) it seems to spit out one photo per folder. Is this to be expected?
Not sure about answer, but it looks ridiculous :P

Hello guys!

I can admit I can see tremendous progress(es) all around :D


Hey guys!

I don't experience any crashes with dynamic build either but, I've managed to compile usual static win64 build for 1.9, give it a try and report back. Here is a link.


Okay. Puh. (In & Out has stolen some of my nervs in past. It is more complex than it looks like.)  ;D

In MLVFS this should work as Danne said.

Edit: not sure about success of this particular case though.

Hey guys!

Deflicker option was intended for DNG export only. Uses DNG tag feature for exposure compensation for each frame (absolutely needs the DNG processing app to be aware of this tag, ACR does).


If I open MLV App, then add that file, change Chroma Smooth to 5x5 and export in DNG Fast Pass with DaVinci Resolve naming it crashed MLV App instantly.
Even before progress bar shows.
When export is set to "Fast Pass" all raw corrections are skipped anyway, so CS 5x5 has none of impact on export as none of impact has naming scheme either.


I can not reproduce the crash either. Last frame is indeed corrupted and can not be exported as compressed .DNG, uncompressed/fast shows artifacts.

Otherwise exporting as compressed/uncompressed/fast with both naming schemes is perfectly fine here (Linux Ubuntu 16.04)

Edit: some amount of last frames playing silent.

And I think indexing in mlrawviewer is done in the background in a separate thread. File is playing with some hickups though, before indexing is fully done.

Pages: 1 2 [3] 4 5 ... 34