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

[bouncyball]

Is it possible to set the directory anywhere in the code (or at least printf the path)?

Path not changeable at the moment. What the console output says on mac when "Using focus pixel map: 'path/id_xres_yres.fpm' " is displayed?

Edit: fopen is done with file name without the path hence the dir always currentt dir.
Edit2: does ffmped calling work though QtCreator run?
Edit3: MLVFS also searches all its additional files in the current dir, so you absolutly need to cd to the MLVFS folder

[masc]

Path not changeable at the moment. What the console output says on mac when "Using focus pixel map: 'path/id_xres_yres.fpm' " is displayed?

Edit: fopen is done with file name without the path hence the dir always currentt dir.
Edit2: does ffmped calling work though QtCreator run?

ffmpeg runs also through QtCreator. In exactly the same folder I copied the fpm files. In the console there is nothing with focus pixels... all the other corrections write an output... strange...

[bouncyball]

In the console there is nothing with focus pixels...

This means the maps are not found. I need to look at how you are calling ffmpeg. Specifying the dir can be implemented anyway.

Edit: In debugger you can watch the fpm_status variable. If it stays 0 or equals to 2 maps are not found.

[masc]

WAIT! If I have the files next to the ffmpeg and start MLV App through QtCreator it works! Starting MLV App by doubleclicking it does not work. (Exactly the opposit from Windows)
Edit: it would be interesting to see where the app is searching.
Edit2: QDir::currentPath() and QCoreApplication::applicationDirPath(), both bring the folder where the fpm files are.

[bouncyball]

This opposite behavior on osx and win is very strange.

[masc]

Doubleclicking the App on OSX sets "/" as working directory for the C code part.
For the Qt part, the working dir is the path of the executable inside the app package.
If I copy the files in "/" it works.
@bouncyball: Any suggestion? Is it possible to implement a bypass to set the directory in the correction module?

Edit: I did a call in the Qt part:

Code: [Select]

chdir( QCoreApplication::applicationDirPath().toLatin1().data() );First test on OSX: works! :-)
Edit: Second test on Windows: works too!

[ilia3101]

Haven't followed the discussion much so not 100% sure whats going on
Does the app need to contain focus pixel maps or something for the llrawprocobject to remove focus pixels?

[masc]

Haven't followed the discussion much so not 100% sure whats going on
Does the app need to contain focus pixel maps or something for the llrawprocobject to remove focus pixels?

Yes. And they must be located in the working dir. Maybe you have to set the working dir in the C code (at least in Qt I had to do that, otherwise it was at "/"). But you could do that from the cocoa classes using chdir().

[bouncyball]

@bouncyball: Any suggestion? Is it possible to implement a bypass to set the directory in the correction module?

If you think this is the more correct approach we can pass the map directory as a parameter.

I got another idea. I'm gonna implement the on the fly pixel map generation code right into mlvapp, but there'll be possibility to override this behavior by manually placing the map to the working dir as now. What do you think about placing as few files in working DIR as possible without sacrificing functionality?

[Danne]

fpmutil code pure joy(fpm.sh on steroids ).
http://www.magiclantern.fm/forum/index.php?topic=15108.msg187641#msg187641

[bouncyball]

Yes it's very fast, faster then searching bad pixels.

[bouncyball]

@Ilia3101, @masc

I had a linking problem caused by "MLV App" space in the middle of TARGET name.
Can we rename the app binary to "MLVApp" of maybe just to plain "mlvapp"?

[ilia3101]

If you think this is the more correct approach we can pass the map directory as a parameter.

Yes! Yes! Yes!
I was just looking at the code, seeing how I could do that.
As the Cocoa API allows getting the path to the app bundle's resources directory, where they would be stored.
(It would be perfect!)

Seems like a directory path argument would need to be added to load_pixel_map (of course do it how you feel is right):

Code: [Select]

static int load_pixel_map(pixel_map * map, char * path, uint32_t camera_id, int raw_width, int raw_height, int dual_iso)And have a parameter for it inside of llrawprocobject which it will pass to that(Is that how it works?)

[ilia3101]

I had a linking problem caused by "MLV App" space in the middle of TARGET name.
Can we rename the app binary to "MLVApp" of maybe just to plain "mlvapp"?

Yea sure, why not rename the binary. On macOS this wouldn't even matter as the app bundle and binary can have any names at all.
Or maybe just rename it on Linux if that's the only place where it's causing problems?

[masc]

@Ilia3101, @masc
I had a linking problem caused by "MLV App" space in the middle of TARGET name.
Can we rename the app binary to "MLVApp" of maybe just to plain "mlvapp"?

We can rename it. Where do you have that problem? On Linux? On Win & OSX I never had a problem with that. Maybe change the .pro to that:

Code: [Select]

win32: TARGET = "MLV App"
linux-g++*: TARGET = "MLVApp"
osx: TARGET = "MLV App"


[bouncyball]

This was the error:

Code: [Select]

/usr/bin/x86_64-w64-mingw32.static-ld: cannot find ./release/mlv
/usr/bin/x86_64-w64-mingw32.static-ld: cannot find app_plugin_import.o
"mlv app_plugin_import.o" divided to "mlv" and remainder.

[bouncyball]

I thought about adding parameter "path" to related functions and can admit that this complicates things quite a bit and makes ugly, can we just use some global variable with working dir set?

[bouncyball]

This:

Code: [Select]

win32: TARGET = "MLVApp"
linux-g++*: TARGET = "mlvapp"
osx: TARGET = "MLV App"
did the trick.

[revast]

Linux compile howto & 64bit build

sudo apt-get install libpng16-dev qtmultimedia5-dev qt5-qmake qtbase5-dev

ubuntu 16.04 with kubuntu backports ppa activated, so qt 5.6.1


I had to change line 22 of MainWindow.cpp to

#include <libpng16/png.h>

and line 55 of MLVApp.pro to
linux-g++*: LIBS += -L/usr/local/lib/ -lz -lpng16

then the ususal

Code: [Select]

qt5-qmake MLVApp.pro

Code: [Select]

make
MLVApp + static FFMpeg, 64bit

[bouncyball]

Thank you, but it's gonna make more sense if you make the binary static.

[masc]

To not change MainWindow.cpp (OSX and Win port would be broken) you also could change line 56 in the .pro to:

Code: [Select]

linux-g++*: INCLUDEPATH += /usr/local/include/libpng16/

[revast]

Thank you, but it's gonna make more sense if you make the binary static.

show me how.

[escho]

Linux compile howto & 64bit build

sudo apt-get install libpng16-dev qtmultimedia5-dev qt5-qmake qtbase5-dev

ubuntu 16.04 with kubuntu backports ppa activated, so qt 5.6.1


I had to change line 22 of MainWindow.cpp to

#include <libpng16/png.h>

and line 55 of MLVApp.pro to
linux-g++*: LIBS += -L/usr/local/lib/ -lz -lpng16

then the ususal

Code: [Select]

qt5-qmake MLVApp.pro

Code: [Select]

make
MLVApp + static FFMpeg, 64bit

On my system ( Linux opensuse leap ) I don´t have to change MainWindow.cpp and MLVApp.pro to get MLV App compiled. Just the syntax is a bit different:

Code: [Select]

qmake-qt5
make
I need no static ffmpeg. I use the ffmpeg, installed with Yast. MLV App find the ffmpeg-bin via the PATH-envirement-variabe of my system.

[masc]

Yes! Yes! Yes!
I was just looking at the code, seeing how I could do that.
As the Cocoa API allows getting the path to the app bundle's resources directory, where they would be stored.
(It would be perfect!)

But would it be a problem to copy it to the resources directory and setting chdir to it? So (nearly) nothing has to be changed.

[ilia3101]

But would it be a problem to copy it to the resources directory and setting chdir to it? So (nearly) nothing has to be changed.

I guess I could easily do that and it's completely fine.
But it's app-global, so if ever another library gets introduced to the app that also happens to depend on being in a certain directory(which of course shouldn't happen), it will become an issue.
Maybe I'm being paranoid, but isn't it good practice to keep as much local as possible?

I'll do that for now anyway as it seems like it won't break anything