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

Started by ilia3101, July 08, 2017, 10:19:19 PM

Previous topic - Next topic

0 Members and 9 Guests are viewing this topic.

AF-OFF


togg

Quote from: ozcancelik on December 05, 2019, 09:18:16 AM
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.

only-text-with-rgb" border="0


I love all of this. Congrats

masc

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

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?
5D3.113 | EOSM.202

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

bouncyball

Quote from: masc on December 10, 2019, 08:03:18 PM
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

Quote from: bouncyball on December 11, 2019, 01:50:32 PM
I think app icon should be pure "3color + slider" without any ".MLV", application name etc...
That's what I meant.
5D3.113 | EOSM.202


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

Quote from: Ilia3101 on December 12, 2019, 06:05:04 PM
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

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


garry23


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
:D

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

yokashin

Quote from: masc on November 30, 2019, 09:43:29 AM
@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
70D.112 [main cam] | M.202 | S110 [CHDK]

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.
5D3.113 | EOSM.202

yokashin

Quote from: masc on December 19, 2019, 08:14:31 PM
@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!
70D.112 [main cam] | M.202 | S110 [CHDK]

masc

Quote from: yokashin on December 19, 2019, 08:21:46 PM
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.
5D3.113 | EOSM.202

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.
70D.112 [main cam] | M.202 | S110 [CHDK]

masc

Yes I understood... but the sounding was a little sarcastic, hehe (this is what I hear the whole day at work).  ;D
5D3.113 | EOSM.202

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 :P (very uncool).
5D3.113 | EOSM.202

Luther

Quote from: masc on December 21, 2019, 10:20:02 AM
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...
Quote
(just) for windows :P (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
Quote
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.
5D3.113 | EOSM.202

ilia3101

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

Quote from: masc on December 22, 2019, 11:09:47 AM
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 :D


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