Fork of HCFR Started - What's needed? - Page 2

Either way, adjusting gamma in HCFR is a PITA. I use ChromaPure, and adjusting gamma in it is a breeze.

Some excellent news, I've been in contact with Jerome who wrote the mac version and he's given me the latest source. I'll be adding that to git soon and then making sure I can get it compiled at the weekend.

John

I think I'm getting the picture on the gamma.

So basic processes that should be as easy as possible are:

1. setting white point
2. setting primaries
3. setting gamma

John

Current workflow for gamma adjustment is not that bad. The 10-90 target Y's appear in the table data after a grayscale run and then you use real-time measures to adjust. I guess it would be nice to have a real-time graphical display of the measure vs. the target rather than comparing two numbers.

For gamma the current dart target for the xy and some kind of 1-d error indicator for the Y would seem sensible.

John

Another thing that seems to confuse new users of HCFR is that reducing Delta E for colors does not necessarily mean that you're coming closer to a target calibration. For example if you have a clearly oversaturated green and limited display controls the formula in HCFR generally suggests that you can reduce Delta E by lowering the brightness of green. My personal opinion is that such a trend is likely questionable, if not simply incorrect, and the newer Delta E formulas don't share the same trend of implying that drastically changing brightness may result in less color error.

I would love to see the Y value reported on the CIE diagram when in continuous read mode, so you could see the effect on Y while adjusting saturation and hue.

The CIE diagram offers great real-time feedback when in continuous read mode when adjusting CMS controls for hue and saturation. Unfortunately, the hue and saturation affect the Y luminance value (which must be read off the Meaured tab). It would be nice to see it on the CIE diagram.

bruce

Thanks for all the comments so far, plenty to think about there.

The intergration of the new meters is coming on pretty well, there will probably be a release with just the new meter support next week sometime. The main annoyance will be the need to install different drivers but in this case that's the price of freedom....

After that I'll start looking at some of the other issues.

John

Thank you John. For freeware HCFR is pretty impressive, and having a couple of these features added & support for newer meters will be much appreciated.

I have programming experience VB mostly, C++ is pretty rusty, so could help , but I'm probably more help testing (although I'm not a calibration expert).

Great, testing is always helpful, also what meters do you have access to? I've got access to a colormunki and several i1Displays. Confirming it works with others before releaseing more widely would be very handy.

Signing up to the dev list is the best way of getting access to the hot off the press stuff.

John

FWIW I have an i1 Display 2 and 3, and driver (C/C++/kernel) experience on MacOSX. So when there is something to do on mac...

Excellent, the latest mac source is now in git, under the libHCFR and macSources subdirectories. Just getting the source and seeing if it builds for you would be a start.

John

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.

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

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.

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.

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

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

By the way I'll keep track of all the feature requests on the project wiki on sourceforge. No timescales though ....

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.

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

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.

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.

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.

Oh crap. Does this mean I'll have to update my guide?


Can that even be done given the way the Display 3 licensing works with X-rite? I could have sworn reading some posts from Tom of ChromaPure here on the subject and they made sense (can't find them now) ...

Kal

Nice guide BTW, I originally learned how to calibrate from your guide and we direct people to that site all the time in these forums to learn.

'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

Another item for the list. Thanks for kicking this off John!

I1 pro 3.33nm sampling

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...