- This topic has 15 replies, 9 voices, and was last updated 2 years, 1 month ago by
.
-
Posts
-
The latest version of DisplayCAL (version 3.8.9.3) was released many, many moons ago, in 2019. I wonder if the software will still get updates or is it considered “finished” (ie. abandoned?). Or are there plans to continue the development later? Any comments from the author Florian Höch? You still seem to write here every now and then.
Any news still? Are there any plans to continue the development of DisplayCAL or is it abandonware?
There is news. I found a thread on pixls.us where both Florian and Graeme (dev of ArgyllCMS) have spoken. It’s called “RIP DisplayCAL ?”
A very talented dev offered to port the dependencies from Python 2 (now deprecated) to Python 3 and do all the hard work for him. All Florian has to do is open up the source code. He mentioned “bus theory” – where if something was to happen to Florian, what would happen to the project?
Florian’s response, copy pasted: (Dec 2020)
If this were a normal year, and if I would have only focused on getting a py3 version ready, that would probably have worked out alright. But this isn’t a normal year, not by a far stretch. And the main problem that I have is that I’m utterly out of energy, as well as “recharging the batteries” being difficult. E.g. the past years, one important way of recharging was going out with friends. Well guess what’s become increasingly difficult if not impossible this year, at least if you want to be responsible. I’m sure I’m not alone in this.
And another Florian response: (Dec 2020)
- SourceForge hasn’t been the place where DisplayCAL code development happens for over a year now. I moved to a different (currently private) repo.
- Move to python3 is only part of the ongoing work (can’t say more sorry). It will happen eventually, but on my schedule, not anyone elses (that should go without mention).
In May 2021, Graeme from Argyll joined in to discuss how opening it up would “dilute ownership” of Florian’s code. He was concerned that a “highly technical and specialised application” like DisplayCAL is “much less likely to survive a fork”. He would rather DisplayCAL stays on Python 2, instead of others doing all the hard work and porting it to Python 3 for him.
Florian has refused to update the SourceForge with his latest code. People cannot begin working on a port unless they have the latest code. Nor is he interested in any forks/collaborations.
I don’t even care about Python 2 vs Python 3. That’s irrelevant. What’s important is the state of the project. It’s unfair to 1) Prevent others from contributing, and then 2) Not update it. He could’ve taken help from some very talented people, but refused, because of his pride.
Either keep it as-is and update it, or open it up so others can do it for you.
While he’s preventing others from chipping in due to pride, paid proprietary software like Calman/LightSpace are gaining even more customers. With their extortionate $2000 licenses, proprietary software and exclusive closed-source manufacturer SDK access. It’s a complete racket. Calibration should be freely accessible for all. That’s why DisplayCAL is so important.
Calman, if we exclude propietary LUT uploading that will not be part of DisplayCAL (AFAIK), is not even close to DisplayCAL and do not overlap at all in functionality with the exception of validation reports, and Calman is niot even close to Displaycal.
If you wish a open source Calman you have to move to HCFR (ArgyllCMS code under the hood), which is releasing newer versions more oriented to raspberry pi patch generators to avoid dealing with HDMI issues on a lot of laptops. It’s Windows only AFAIK, but they did a port to mac in the past, IDNK if newer versions are ported to mac too.
Regarding Lightspace, it is the same, they pay those licenses because it has propietary SDKs to uplolad LUTs to several devices.
AFAIK even with a regulary updated DisplayCAL that functionality won’t be avialable because AFAIK Argyll or DisplayCAL will not have dependencies on those propietary SDK, although these functionality may be given if DisplayCAL/Argyll exported a lut-matrix-lut (Eizo CS line and others) or a 17x17x17 LUT3D cube (PA/CG-X) in an vendor independent format, then via “plugins” you could add each vendor propietary SDK if you could get it in a legal way.
AFAIK only Dell and HP provided this in the past and in newer SDK revisiosn Dell removed custom LUT uploading API, so vendors are not going to ease this.
Hence, without propietary LUT uploading, new features are limited beyond what we have excluding soem new validation features (like use simulation profile as dispaly profile without cleaning GPU 1D LUT= “I want to test if may display once calibrated-1DLUT- behaves like sRGB to play games or see movies”)I totally get it that the developer can stop developing a project for whatever reason. And he has the full right to do so. In this case it would be nice to get some kind of an announcement that the project is abandoned or on hiatus. Or whatever the situation is. And if there are no intentions to continue in the foreseeable future, it would be great if this project would be open sourced so that the maintenance could be continued by volunteers. DisplayCAL has a huge userbase and it is a great application. It would be a real shame if it just dies like that.
I agree with Paapaa Poopoo.
I love DisplayCal and I have been using it for years. It would be nice to know what is the future of this incredible software.
at this point it’s time to move to another software.
a developer have all the right to stop working on a free project but IMHO it’s pretty unfair to not open source it if he don’t want to work on it anymore.
I hate this kind of behaviour, this is why I have just uninstalled DisplayCAL.
There are no (free) alternatives with custom CCSS, ICC/LUT3D creation and unlocked i1d3 devices.
There is “colorprofiler” (source forge) but it is more oriented to printing. Instead of making your own bats this tool makes them for you:
https://sourceforge.net/projects/cprofiler2020/files/
Also AFAIK there is no USB signed driver over 2.1.2.Even with “abandonware” status there is no better tool … and if there is, I wish to know:
-xrite VCGT loader causes banding, same for basiccolor
-basiccolor has no WLED PFS support, NONE of them
-Spectracal/LightIllusion licenses are out of budget for 99.999% DisplayCAL users… and only LightIllusion is close to functionality available with DisplayCAL
-Coraye is more printing oriented and licenses are not cheap.Maybe making a fork of 3.8.9.3
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.(This is the copy/paste of my other post):
Hey guys,
I started porting DisplayCAL to Python 3.x now. And I’m happy to say that it started to breath. So the UI works with Python 3.9.7, albeit with a ton of bugs, I was able to calibrate and profile. But currently not able to install the created profile. But hopefully in short amount of time I’m expecting to fix those bugs too.
The GitHub repository is: https://github.com/eoyilmaz/displaycal-py3
Feel free to pull and test the code, and please create tickets so we can smash those pesky bugs ????
The code needs to be installed as an sdist (install instructions are there and if it is not working for you, please create an issue). There are people volunteered to create proper RPM, DEB, APP or MSI packages for wide variety of OSes.
I would love to be the next maintainer for DisplayCAL with Florian Hoch’s permission. I’m intending to keep all the donation links to stay intact, so he and Graeme Gill of ArgyllCMS still benefit from the donations.
Let’s keep the future of DisplayCAL bright!
Cheers,
- Offline
Will you also port it to Appel Silicon?
The current priority is to port DisplayCAL to Python 3.8+ (and I got a pretty good progress on this front, I have a working version!), then I would love to add new features and, port it to Apple Silicon too (btw, it depends hugely on ArgyllCMS’s support to Apple Silicon, which, currently I have no idea of).
I’ll feel confident when I have enough tests that covers a huge portion of the code (currently pytest-cov reports ~17% coverage), then with those tests in place I can do more.
