Asking for programmers willing to help update Photosphere for MacOS, Windows, and Linux.
As some of you know, it has been a challenge for me supporting Photosphere across platforms. The original version of Photosphere does not work past Mojave (10.14), as 32-bit applications have been deprecated. As for Windows, I hired Elena Eydelberg to port Photosphere using wxWidgets nearly a decade ago, but there have been no updates since then.
I have recently attempted to bring the wxWidgets version Elena ported back to MacOS in hopes of making it into a proper 64-bit application, with some success. (There is an alpha release at www.anyhere.com.) However, I don’t really have the time or know-how to fix the bugs in this back-port, nor time to update the Windows version or create a Linux version, both of which should be on the roadmap.
My current thought is to make Photosphere and the Pancine C++ HDR imaging library that underpins it open source. This makes sense if I can get the help needed to debug the wxWidgets version on multiple platforms and make this a free and useful resource to all.
If you are a C++ programmer with chops on any or all of these platforms and interested in taking this on as a side project, please write. If you know of someone who might be interested, have them write. I’m interested in hearing from anyone and everyone at this stage.
Likewise, if you have other ideas or suggestions for how to get this off the ground, I’m all ears.
Best wishes to all for 2021 – it’s got to get better, right?
-Greg
The HDR library doesn’t have a UI, right? It should be possible to just compile and distribute it as a library, possibly under the LGPL.
I am less sure about the app, though.
In fact, why compile the library? A simple start would be uploading to GitHub and providing a basic build script. If I do the script it’s going to be scons, though. 
Is there already a Makefile?
1 Like
This is not an area that I can personally help as a developer but as @Randolph_Fritz4 suggested I agree that the first step is probably to release it on GitHub so other developers can see the source code. We can probably start with automating the builds for the current versions and try to get more people to use/test it.
Yup, publishing the existing code under some OS license would be the
easiest
and fastest way to get more people involved.
Both on radsite (more focused) or on GitHub (wider audience) should be
fine.
Dunno how much of the functionality is in that pancine library vs. the
UI app.
The more that can be encapsulated in an UI independent way, the better,
so that
people can slap the thinnest possible layer of UI glue on top to port
it, which
doesn’t even necessarily have to be C/C++.
cheers
-schorsch
Thanks for the discussion. The functionality of Photosphere is split about 50/50 between the UI and the library. The only command-line tools I have are an HDR merge tool and an image converter, which can be built on various platforms with some effort (mostly getting OpenEXR to compile).
That said, I’m not particularly interested in making the library open source just to get these two tools working. If we cannot update Photosphere, then there’s not much point in releasing source code. Reimplementing the boundary between the library and the GUI would also be much more work than updating the wxWidgets port we have.
Cheers,
-Greg
Got some experience in wxwidgets, also got, besides a win64 bit machine, a mac 2017 for cross checking.
I’m interested, but I do have another hdr related side project wich I try to release by the end of this month (maybe next month if things does not work out well), after that I might find some time doing the conversion.
chris
1 Like
Hi Chris,
Thanks for your offer – if you have time to help us out next month, that would be amazing! Good luck with your release. (What software are you building?)
Cheers,
-Greg
Ok, will contact you as soon as I’m finished
I’m working on a set of three experimental programs to control dmx (and if things work out manually controlled lights) on basis of an hdri environment. (so ligth “calibration”, control and positioning). Currently I’m still on the calibration part, where I shoot myself constantly in the knee by allowing low cost “calibration” by an hdri / jpeg+exif data of a color checker. 
(In the first release it just have to be in the same ballpark as the luxmeter / spectrometer reading and also be useable for 3d related rendering)
I have also done a bit of that. It’s almost impossible unless you work from the RAW camera data, since the in-camera color transforms only work one-way (i.e. very lossy) on most devices.