MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

[AF-OFF]

1. make your settings in the window
2. press "+"

Many thanks Masc, now it's working!

[togg]

It can be logo but for icon I think  only extension ".MLV" can be text. Also my idea was "RGB with Sliders". Thats what MLV Apps mostly doing.

I love all of this. Congrats

[masc]

Yes, I also like that one... just the slider could be there aditionally, like here:

Bouncyball helped to prepare MLVApp to be able to use document icons on Windows and I prepared it for OSX. On Windows we have some last little problems with registering...
Is there also a way for Linux? (Here I have absolutely no idea how it works.)
We prepared it for three different document icons: .MLV, .MASXML and .MARXML.
@Ilia: it is your app... how do you like these icons here?

[bouncyball]

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 (Ubuntu Linux mostly)

[bouncyball]

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

[masc]

I think app icon should be pure "3color + slider" without any ".MLV", application name etc...

That's what I meant.

[bouncyball]

Cool

[ilia3101]

I said some time ago, somewhere, to someone (I think @Luther) that MLV App's tint slider is not very good because it is done in final colour gamut -  I was mistaken. It is actually done at the very start, on camera RGB channels. So it is fine, rawtherapee even does all white balance that way, so doing a little part is not harmful. 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,.

[bouncyball]

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!

[garry23]

Keeping an eye on developments here, as, although I'm only a stills photographer, I am looking to use MLV App for long exposure processing.

On that topic, I wonder if those developing the App have considered eliminating the TIFF average limit, ie it's currently 128 frames - if possible.

Cheers

Garry

[Danne]

It's not. You have to modify ffmpeg code for all I know.

[garry23]

Oh bugger!!!

[togg]

I'm doing some light tests with my 5D3 and grabbing the stills with MLV App

[2blackbar]

Yeah You can use many full res raw dng files from other cameras as well, not only canons sooo..
This joke can be edited :
If you want to process DNGs, use DNGApp.com
to this :
If you want to process DNGs from cameras that shoot RAW, use Transcode and Import from MLVApp menu
 

Now with help of Ilia3101 and cmh i succesfully imported dngs from pixel2xl and sigma fp stills and video frame to mlvapp

[yokashin]

@yokashin:
thanks for reporting. Opening files from "zdjęcia" folder is a Windows only issue. Works fine here on Mac. Maybe I can debug this when I am back on a Windows PC.

Today I discovered a similar funny problem In the morning I set up the conversion of several files - task for 4 hours. Before leaving for work, I checked if everything is ok. After returning, I discovered that the target directory is empty Files were to be saved in the directory with the Polish letter "Ż". I conducted the test and in fact the application does not even create .mov and .wav files when starting the task. In the application window, everything goes correctly -% and task progress in subsequent files. There are no visible messages about any errors.

MLV.App.v1.10.Win64.static working on Windows 10 64bit

[masc]

@yokashin: hm, I was debugging this and found the function where the problem happens. No problem with all the german letters like äöüß, but with your polish letters. I tried out all alternatives Qt offers for such letter conversion - but without success. No idea how we could solve it. So for now I can just recommend to not use such letters, sorry. The problem exists only on Windows. On Linux or OSX it also works with those letters.

[yokashin]

@yokashin: hm, I was debugging this and found the function where the problem happens. No problem with all the german letters like äöüß, but with your polish letters. I tried out all alternatives Qt offers for such letter conversion - but without success. No idea how we could solve it. So for now I can just recommend to not use such letters, sorry. The problem exists only on Windows. On Linux or OSX it also works with those letters.

I understand. Now I know what to do to prevent this problem. Regards!

[masc]

I understand. Now I know what to do to prevent this problem. Regards!

Not really... or?! Sorry.
Problem is to convert QString to char*, where we use for Windows fileName.toLatin1().data(), in order to get the filenames from the GUI part to the C processing part. The conversion is done with toLatin1().data() for Windows, and with toUtf8().data() on Unix (which does not work at all for Windows). If someone has a better idea, please let me know.

[yokashin]

What I meant more was that I should not use Polish characters in directory names. It is possible that I spoke wrongly. Excuse me.

[masc]

Yes I understood... but the sounding was a little sarcastic, hehe (this is what I hear the whole day at work). 

[Luther]

@masc, I think that's because Windows uses UTF-16 instead of UTF-8. They have this function called "WideCharToMultiByte" to convert properly:
https://docs.microsoft.com/pt-br/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte?redirectedfrom=MSDN
https://stackoverflow.com/questions/215963/how-do-you-properly-use-widechartomultibyte/215973#215973

Dunno if this will solve the problem, I don't have knowledge in programming...

[masc]

Thanks Luther. Yes, that looks like to be the reason why. The processing code uses platform independant standard C libraries, which use char* to describe the filename. char is 8bit. If Windows (only) uses 16 bit now, we will never ever be able to convert that via 8bit variables. The only way to solve should be to rewrite all file operations in processing code (just) for windows (very uncool).

[Luther]

The processing code uses platform independant standard C libraries, which use char* to describe the filename. char is 8bit.

How about using wstring (const wchar_t)? I've read some people recommending while I was searching for solutions...

(just) for windows (very uncool).

Microsoft, as always. If we had an alternative to Premiere Pro in free unix-like systems I would never use windows again.

edit - this guy explains well:
https://stackoverflow.com/questions/402283/stdwstring-vs-stdstring/402918#402918

Applications using char are said "multibyte" (because each glyph is composed of one or more chars), while applications using wchar_t are said "widechar" (because each glyph is composed of one or two wchar_t. See MultiByteToWideChar and WideCharToMultiByte Win32 conversion API for more info.

Thus, if you work on Windows, you badly want to use wchar_t (unless you use a framework hiding that, like GTK+ or QT...). The fact is that behind the scenes, Windows works with wchar_t strings, so even historical applications will have their char strings converted in wchar_t when using API like SetWindowText() (low level API function to set the label on a Win32 GUI).

[masc]

Thanks again, Luther. Hm... but this means having all filename and file interaction standard C code twice inside the processing part of the app. That is very bad to debug and to support.

[ilia3101]

On macOS and linux file name handling is just UTF8 (compatible with char *) so no problems here?

Hm... but this means having all filename and file interaction standard C code twice inside the processing part of the app.

I think it would only require using a special wchar_t version of fopen on windows, everything else can stay the same. Glad libMLV won't be opening files directly


Sorry been inactive for a bit. Mourning the loss of my hard drive with a lot of recent raw videos. Fuck hard drives.