@gaaned92 If you managed to make a patch you’ll find it’s even easier to send a pull request but of course you don’t have to. @heckflosse has his own fork of lhdr and a working msys2 environment for the patch or the pull request.
@Hombre that’s what pull requests are all about. You clone the repository locally, make your changes and then send a pull request, you don’t have to have commit rights. If you send a PR to me I can review your code and decide to pull it effectively doing a merge/commit. And git is distrubuted so you can send the PR to someone else ( @heckflosse ) and he will decide to accept/incorporate your changes and then he can send a PR to me since I have commit rights to the repo considered (only by convention) the “OFFICIAL LHDR REPOSITORY”
@fcomida Yes, I forked LHDR and will work on it. I only worked on RT so far, so this is a new behavior for me, but I’ll stick to the rule 
@gaaned92 I’ll remove everything about AboutThisbuild. That’s not something lhdr is handling, so we won’t make things uselessly complex.
@Hombre no need for creating patches now, when you are happy with your changes just send a PR to @heckflosse fork, he can review/test them. I cannot do it right now.
Patch is almost done, only remaining things is how to find the location of the dependencies to create the Installer ?
I’ll be away for few hours. Let me post something around midnight or more probably tomorrow.
We have 2 situations to handle :
- The user build LHDR himself for himself, so he doesn’t need to copy the dll in the destination directory, adding msys64\mingw64\bin to the PATH suffice
- The user build LHDR to create a installable version, so the libs have to be copied to the base output dir before packaging.
My question is : do we care of point 2 in the cmakefile ?
I see no reason to care for point 2 in the cmakefile.
under Msys2, 64 bits dependencies(dlls) are found in /mingw64/bin
In linux we have rules in cmake for generating proper “make install” instructions and “make install” is also needed by rpmbuild for generating a rpm package (and maybe a deb package). In any case “help”, “icons” and “hdrhtml” folders must be subfolders of CMAKE_INSTALL_PREFIX for lhdr to run properly.
Edit:
What I mean is that, even without creating a package/installer, when run from <BUILD_ROOT> those folders are still relatives to <CMAKE_INSTALL_PREFIX>
Thanks to @heckflosse and @Hombre, LuminanceHDR can be built using MSYS2.
It is still a WIP and they need testers
A new version of W64 installer with align_images_stack.exe and dependencies correctly installed available here
https://drive.google.com/open?id=19L6jI85Q_MAXZhQkUBNuEuUrqUqFPxjA
It can be installed where you want and should not interfere with official stable version.
Please report test results at Issue 78
I got a bug report for the LHDR build for windows:
New HDR Image → Imported raw files from my GH5(still happens with jpeg’s) → Message, that if could’nt find the exif tags → changes the EVF from the photos Manually → Programm alligns the photos (auto allign photos and anti ghosting is on) → I click on finish ( Default settings) → programm crashed with a windows message, “luminance-hdr.exe isn’t working”
Thanks for reporting the bug. The anti ghosting crash is already fixed in master branch of my fork with this commit