Author Topic: MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]  (Read 1092275 times)

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #375 on: September 24, 2017, 07:49:41 PM »
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

  • Contributor
  • Hero Member
  • *****
  • Posts: 2011
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #376 on: September 24, 2017, 08:03:00 PM »
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...
5D3.113 | EOSM.202

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #377 on: September 24, 2017, 08:06:02 PM »
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

  • Contributor
  • Hero Member
  • *****
  • Posts: 2011
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #378 on: September 24, 2017, 08:08:51 PM »
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. :(
5D3.113 | EOSM.202

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #379 on: September 24, 2017, 08:57:27 PM »
This opposite behavior on osx and win is very strange.

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 2011
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #380 on: September 24, 2017, 10:58:27 PM »
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! ;D
5D3.113 | EOSM.202

ilia3101

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 990
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #381 on: September 24, 2017, 11:25:31 PM »
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

  • Contributor
  • Hero Member
  • *****
  • Posts: 2011
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #382 on: September 25, 2017, 08:53:08 AM »
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().
5D3.113 | EOSM.202

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #383 on: September 25, 2017, 09:16:35 AM »
@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

  • Developer
  • Hero Member
  • *****
  • Posts: 7397
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #384 on: September 25, 2017, 09:20:54 AM »

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #385 on: September 25, 2017, 09:22:36 AM »
Yes it's very fast, faster then searching bad pixels.

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #386 on: September 25, 2017, 09:29:53 AM »
@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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 990
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #387 on: September 25, 2017, 09:31:55 AM »
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 990
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #388 on: September 25, 2017, 09:34:07 AM »
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

  • Contributor
  • Hero Member
  • *****
  • Posts: 2011
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #389 on: September 25, 2017, 10:56:14 AM »
@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"
5D3.113 | EOSM.202

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #390 on: September 25, 2017, 11:58:58 AM »
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

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #391 on: September 25, 2017, 12:02:54 PM »
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

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #392 on: September 25, 2017, 12:07:39 PM »
This:
Code: [Select]
win32: TARGET = "MLVApp"
linux-g++*: TARGET = "mlvapp"
osx: TARGET = "MLV App"
did the trick.

revast

  • New to the forum
  • *
  • Posts: 24
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #393 on: September 25, 2017, 03:45:47 PM »
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

  • Contributor
  • Hero Member
  • *****
  • Posts: 849
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #394 on: September 25, 2017, 04:06:58 PM »
Thank you, but it's gonna make more sense if you make the binary static.

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 2011
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #395 on: September 25, 2017, 04:11:24 PM »
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/
5D3.113 | EOSM.202

revast

  • New to the forum
  • *
  • Posts: 24
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #396 on: September 25, 2017, 05:05:19 PM »

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

show me how.

escho

  • Contributor
  • Hero Member
  • *****
  • Posts: 563
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #397 on: September 25, 2017, 06:06:34 PM »
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.
https://sternenkarten.com/
600D, 6D, openSUSE Tumbleweed

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 2011
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #398 on: September 25, 2017, 06:09:20 PM »
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.
5D3.113 | EOSM.202

ilia3101

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 990
Re: Making a New MLV Processing App! [Windows, Mac and Linux]
« Reply #399 on: September 25, 2017, 07:15:18 PM »
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 :)