HCFR - Open source projector and display calibration software
41 - 60 of 13608 Posts
I have an I1 Display 2 LT, and looking to replace it with a Colormunki CMUNDIS(the cheaper new i1 D3) and have a new bulb coming for my projector next week so will need to do some calibration runs soon. I also have a little bit of Windows driver & DirectX coding experience.
I'll check out the git & dev list.
I'll check out the git & dev list.
Joined
·
9,493 Posts
Hey,
Deandob,
The colormunki version of the display3 reads slow... (in case you didn't know that.) It's cheaper but I don't think the price difference is worth it to have one they handicapped by design.
JohnAd,
Wow,... What can I say but thank you. You resurrected a fantastic program and I'm trilled. THANK YOU THANK YOU THANK YOU.
-Brian
Deandob,
The colormunki version of the display3 reads slow... (in case you didn't know that.) It's cheaper but I don't think the price difference is worth it to have one they handicapped by design.
JohnAd,
Wow,... What can I say but thank you. You resurrected a fantastic program and I'm trilled. THANK YOU THANK YOU THANK YOU.
-Brian
Requested features:
1. Setting a custom white point target.
2. Select which delta error formula to use.
3. Calculate target Y's of primaries and secondaries based on their measured coordinates. The formula for this is:
![]()
4. Measure luminance and saturation tracking of primaries and secondaries at 10% and 25% step intervals.
5. Fix CIE chart bug where some of the graphics disappear.
1. Setting a custom white point target.
2. Select which delta error formula to use.
3. Calculate target Y's of primaries and secondaries based on their measured coordinates. The formula for this is:
4. Measure luminance and saturation tracking of primaries and secondaries at 10% and 25% step intervals.
5. Fix CIE chart bug where some of the graphics disappear.
Requested Feature:
Any value that is too far deviated should be highlighted in dark yellow for a moderate deviation (visible by eye, like over dE 3), and highlighted in dark red for bad deviations (things that are way far off). This might be hard to do given the deviations will have to be calculated, but shouldn't be too bad. So the values appearing in the charts should be color coded by changing the text foreground color according to how severe the value's current state is. This will make the numbers much more useful at a glance without any number crunching in your head as they change and are moving dials around on the video device, hence it should make things faster to calibrate.
Another Suggestion:
I would create a master .NET managed wrapper / data API in C++ so that people can use alternative VS.NET environments instead of coding it in C++. I know you can access it directly with C#, but it will still be too much trouble creating custom wrappers unless there is a master wrapper that handles all the incoming data from the meter. It will be so much easier to create branch-offs or a new test area in the .NET framework than it will be in C++, especially easier will be data manageability and charting. Instead of modifying the existing code, I would then suggest creating a new branch of code completely that appears as additional menu options and forms. This might seem to be a larger project, but my bets is in the long run it would be more successful and allow more people to participate, I doubt anyone is going to want to do much with this trying to edit pre-existing C++ code, it is too time consuming.
Any value that is too far deviated should be highlighted in dark yellow for a moderate deviation (visible by eye, like over dE 3), and highlighted in dark red for bad deviations (things that are way far off). This might be hard to do given the deviations will have to be calculated, but shouldn't be too bad. So the values appearing in the charts should be color coded by changing the text foreground color according to how severe the value's current state is. This will make the numbers much more useful at a glance without any number crunching in your head as they change and are moving dials around on the video device, hence it should make things faster to calibrate.
Another Suggestion:
I would create a master .NET managed wrapper / data API in C++ so that people can use alternative VS.NET environments instead of coding it in C++. I know you can access it directly with C#, but it will still be too much trouble creating custom wrappers unless there is a master wrapper that handles all the incoming data from the meter. It will be so much easier to create branch-offs or a new test area in the .NET framework than it will be in C++, especially easier will be data manageability and charting. Instead of modifying the existing code, I would then suggest creating a new branch of code completely that appears as additional menu options and forms. This might seem to be a larger project, but my bets is in the long run it would be more successful and allow more people to participate, I doubt anyone is going to want to do much with this trying to edit pre-existing C++ code, it is too time consuming.
OK added to the list
OK added to the list
I'm not sure I understand why you'd want this and what the difference would be to simply supplying your own reference primaries taken from your actual primaries
OK added to the list
OK added to the list
OK added to the list
OK added to the list
Quote:
Originally Posted by assm0de /forum/post/21653192
3. Calculate target Y's of primaries and secondaries based on their measured coordinates. The formula for this is:
![]()
I'm not sure I understand why you'd want this and what the difference would be to simply supplying your own reference primaries taken from your actual primaries
OK added to the list
OK added to the list
Nice idea, some way of indicating error size should be possible.
I'd certainly agree doing GUI work in MFC is pretty painful, but at the same time editing anybody elses code is always a bit painful and from what I've seen .NET guis can be just as mangled as C++ ones.
A medium term goal of mine is to open up the meter reading and colour maths code as much as possible and I'd expect these to be in c++ on all platforms (Windows, Mac, Linux), .NET wrappers for the readings and maths would then be pretty trivial either via a COM layer or via a managed C++ layer or pinvoke.
If there was going to be a major shift in the GUI on windows I'd definitely encourage a move to something cross-platform. Mono is definitely an option but not all bells and whistles would be supported on all platforms. Could you look into this cross platform aspect a bit more?
btw are you on the dev mailing list?
John
Nice idea, some way of indicating error size should be possible.
I'd certainly agree doing GUI work in MFC is pretty painful, but at the same time editing anybody elses code is always a bit painful and from what I've seen .NET guis can be just as mangled as C++ ones.
A medium term goal of mine is to open up the meter reading and colour maths code as much as possible and I'd expect these to be in c++ on all platforms (Windows, Mac, Linux), .NET wrappers for the readings and maths would then be pretty trivial either via a COM layer or via a managed C++ layer or pinvoke.
If there was going to be a major shift in the GUI on windows I'd definitely encourage a move to something cross-platform. Mono is definitely an option but not all bells and whistles would be supported on all platforms. Could you look into this cross platform aspect a bit more?
btw are you on the dev mailing list?
John
Sorry, this is going to be a long post, but here are my thoughts...
I can help out on some ideas, but at this moment I do not have a lot of extra time for development. I will add myself to the list, that said I will be interested in helping if I can get enough spare time (lots of other stuff going on though).
Anytime you attempt to go the cross-platform route in a desktop application (non-web based), especially on a project without a lot of developer backing or financial incentive (open source), this is going to be a big compromise because even maintaining two code bases for two operating systems is most likely not worth it.
I would say from a development standpoint, the simplest cross-platform option is to use an intermediate layer running on a server that responds to data transformation requests and outputs the GUI back as HTML. This way all the raw number value code can be produced in any language (the data read from the meter on a MAC or Windows desktop (or any desktop), and the output GUI is produced by a server responding to those numbers. Hence everyone's desktop sends data to the server, server sends the data back encapsulated inside an HTML window in the Mac or Windows GUI. This creates a single platform to create the GUI in. The web based portion of the application could be just an addition to the existing application. For people that have a Windows desktop, they can OPT to run the server-side of the application locally on their own desktop, for the others, they use the transformation method. The ability to send data transformations to a centralized location would mean multiple web responses could be written in multiple languages as well, if someone so desired to create further improvements. It would also make the open source market for add-ons very simple for people to do. Start off by making it more of a server-only application, then once you get near the final version, it can be ported to run as a desktop application to generate the HTML locally on peoples' computers to get rid of the server layer later.
Sorry, this is going to be a long post, but here are my thoughts...
I can help out on some ideas, but at this moment I do not have a lot of extra time for development. I will add myself to the list, that said I will be interested in helping if I can get enough spare time (lots of other stuff going on though).
Anytime you attempt to go the cross-platform route in a desktop application (non-web based), especially on a project without a lot of developer backing or financial incentive (open source), this is going to be a big compromise because even maintaining two code bases for two operating systems is most likely not worth it.
I would say from a development standpoint, the simplest cross-platform option is to use an intermediate layer running on a server that responds to data transformation requests and outputs the GUI back as HTML. This way all the raw number value code can be produced in any language (the data read from the meter on a MAC or Windows desktop (or any desktop), and the output GUI is produced by a server responding to those numbers. Hence everyone's desktop sends data to the server, server sends the data back encapsulated inside an HTML window in the Mac or Windows GUI. This creates a single platform to create the GUI in. The web based portion of the application could be just an addition to the existing application. For people that have a Windows desktop, they can OPT to run the server-side of the application locally on their own desktop, for the others, they use the transformation method. The ability to send data transformations to a centralized location would mean multiple web responses could be written in multiple languages as well, if someone so desired to create further improvements. It would also make the open source market for add-ons very simple for people to do. Start off by making it more of a server-only application, then once you get near the final version, it can be ported to run as a desktop application to generate the HTML locally on peoples' computers to get rid of the server layer later.
coderguy
Thanks for that, as you point out this is probably all dreams at the moment. So the situation now is 2 native codebases.
I'm not sure I fancy doing anything server based but as you say local webservice is a fairly reasonable way of doing cross platform. I've seen a few successes with cross platform c++ gui toolkits but usually it's lowest common denominator stuff and looks a bit klunky on all platforms but usuable, forgotten about java but as you say cross platform jvm and jni issues probably make that harder but maybe not impossible.
Python might also be an option as getting stuff out of native into that is fairly straightforward.
I look forward to hearing your views going forward on the mailing list.
John
Thanks for that, as you point out this is probably all dreams at the moment. So the situation now is 2 native codebases.
I'm not sure I fancy doing anything server based but as you say local webservice is a fairly reasonable way of doing cross platform. I've seen a few successes with cross platform c++ gui toolkits but usually it's lowest common denominator stuff and looks a bit klunky on all platforms but usuable, forgotten about java but as you say cross platform jvm and jni issues probably make that harder but maybe not impossible.
Python might also be an option as getting stuff out of native into that is fairly straightforward.
I look forward to hearing your views going forward on the mailing list.
John
The main issue is that there are 100+ web programmers to every 1 C++ programmer in the open source arena, so if doing open source, it is much easier to get developers to contribute to a web based application. Server transformations are usually fairly simple, you can just post the data to the server with a script, you can write the raw data to a local directory using C++, use a filewatcher service or script running on someone's computer to then post the data to the server, no real C++ code required other than the raw output. I think trying to fix existing code is too complicated compared to generating new reports in a web-based application. I would use .NET or PHP for the server transformation, not Python or Perl.
Javascript and Flash or just plain HTML re-posts inside HTML forms are the only real way to make something cross-platform without a multimillion dollar budget, tried every other method, it is too expensive and tedious.
Javascript and Flash or just plain HTML re-posts inside HTML forms are the only real way to make something cross-platform without a multimillion dollar budget, tried every other method, it is too expensive and tedious.
Brian, for the occassional calibration, is the Colormunki that slow that its worth the extra $100 for the Display 3?
Coderguy, although I agree it would be nicer to be cross platform, the effort in the models you are describing seem an order of magnitude more work than patching the existing codebase as long as the feature requests aren't too extensive. Surely 90% of folks will have access to a Windows laptop to do the calibration, so the effort is better spent on building the features? Personally, I could contribute more if the GUI was in .NET or even Silverlight, as you say there are fewer C++ coders around.
Coderguy, although I agree it would be nicer to be cross platform, the effort in the models you are describing seem an order of magnitude more work than patching the existing codebase as long as the feature requests aren't too extensive. Surely 90% of folks will have access to a Windows laptop to do the calibration, so the effort is better spent on building the features? Personally, I could contribute more if the GUI was in .NET or even Silverlight, as you say there are fewer C++ coders around.
Well debugging one block of undocumented C++ code could in some cases actually be harder than writing an entire set of web-based reports. People really skilled at C++ are often in high demand these days because there are fewer people using it, and they don't have time to work on such apps, if you get inexperienced C++ programmers on it, then it'll just cause more problems than it is worth. With web-based apps, it's also easier to version and keep the internal code separated.
Joined
·
7,130 Posts
'fraid so
I'm using the drivers and code from the argyllcms project which seems to support it already so yes it's possible and with no licensing from x-rite required, that code is only compatible with open source software though.
John
Quote:
Originally Posted by kal /forum/post/21655808
Oh crap. Does this mean I'll have to update my guide ?![]()
'fraid so
I'm using the drivers and code from the argyllcms project which seems to support it already so yes it's possible and with no licensing from x-rite required, that code is only compatible with open source software though.
John
The hcfr code is OK, showing it's age in places but basically sound, it's not that hard to work out what's going on and it's not that big an app. I certainly don't plan to or need to rewrite the gui significantly, my point was that if someone was going to rewrite it then cross platform is something that would be good to consider. Agree that for adding a simple reporting layer then c++ to xml then xml to whatever can be written in whatever floats the developers boat.
John
The hcfr code is OK, showing it's age in places but basically sound, it's not that hard to work out what's going on and it's not that big an app. I certainly don't plan to or need to rewrite the gui significantly, my point was that if someone was going to rewrite it then cross platform is something that would be good to consider. Agree that for adding a simple reporting layer then c++ to xml then xml to whatever can be written in whatever floats the developers boat.
John
I'm not disagreeing, just discussing, but just worried some of those technical bugs could be a pain to work out in C++. I've been coding over 20+ years now (old guy from way back), but if you are wanting to fix the existing data, some of it might be flawed at the root source, and the reports might need re-done to provide an accurate application that can calibrate in all forms. People will hopefully test it against other apps and let you know, but still may just be easier to create a wrapper and throw the raw data somewhere else for re-compilation into new reports.
I will fully support whatever method you wish to go though, you won't get any grief here, just trying to offer an experienced opinion on how these C++ bug fix projects sometimes turn out, but it could turn out fine as well...
I'm not disagreeing, just discussing, but just worried some of those technical bugs could be a pain to work out in C++. I've been coding over 20+ years now (old guy from way back), but if you are wanting to fix the existing data, some of it might be flawed at the root source, and the reports might need re-done to provide an accurate application that can calibrate in all forms. People will hopefully test it against other apps and let you know, but still may just be easier to create a wrapper and throw the raw data somewhere else for re-compilation into new reports.
I will fully support whatever method you wish to go though, you won't get any grief here, just trying to offer an experienced opinion on how these C++ bug fix projects sometimes turn out, but it could turn out fine as well...
41 - 60 of 13608 Posts
Join the discussion
Join now to ask and comment!