- This topic has 5 replies, 4 voices, and was last updated 7 years, 7 months ago by
.
-
Posts
-
First of all, thanks for writing this piece of software.
BUT…launched it, 48 minutes and announcing me 271 samples…again, thank for writing it, but it’s out of contact with reality…it takes 4 minutes with native software, plus the time estimates on the status windows are WILDLY off..at least be honest on the startup screen and say “the process will take 1+ hour and the estimates are not reliable”…that way, you won’t waste people’s time, they will launch the app when they have time to do it.
It is you who is out of contact with reality if you think this is an acceptable posting. The only reason I’ll leave it up is to serve as warning and example of how not to post. A few things:
it takes 4 minutes with native software
What a surpise! So it takes 10% of the time. If you had a speck of sense you would also realize that it also only measures 10% of the patches, so the time taken per read is no less, and as a result doesn’t achieve (not even close) the same amount of accuracy (you don’t have to take my word for it, you can verify it by measurements).
plus the time estimates on the status windows are WILDLY off
The only valid criticism in your entire post, but keep in mind that it does adaptive reads, i.e. darker patches will take considerably longer than lighter ones, and this in turn means estimates are harder to do. The estimates even out over time.
at least be honest
You make a paragon example of a not very well thought out, condescending and dishonest post full of not-so-well-veiled insults, and have the gall to call me on dishonesty? Classy.
Let’s see how you are able to deal with actual honesty.
One last thing. Self-reflection; it is an important skill. I am of the opinion you should learn it.
Hi Florian,
thank you for your (verbose) answer. You might want to consider adding a slider to your program, where users can choose between superior accuracy and speed.
Tschuess!
The slider of which you speak is already included! … Actually there are two sliders which will allow the user to set the time versus accuracy \quality variables.
(1) Under the calibration tab, labeled ‘Calibration Speed’ (Of all things) … 4 choices which allow you to increase or decrease the time it takes to complete a calibration. Which is directly related to accuracy\quality.
(2) Under the Profile tab labeled ‘Amount of Patches’ which gives you direct control over how many patches you want to run which is directly related to the time it will take to run those patches. More is better (to a point due to instrument and device drift) But generally 2000- 3000 will bring excellent results for most people, maybe fewer.
The timers can’t be accurate in the short run because every device\instrument combination is different. As well the user might have his brightness set too low which would will cause a much longer reading time of the dark patches causing the program to exhaust a pre-described number of attempts before it eventually gives up and moves on to the next patch, which of course will also fail to read, and so on…. This timing cannot be anticipated, so the timer works in an adaptive way which will eventually become more and more accurate as the end approaches… It’s the best you can do in the situation…But after you do it once, you could record the time it took to complete. Subsequent runs (using the same settings) will generality take the same amount of time, thus, now you have a very accurate timer!
I calibrate\profile the same way every time so I now know that it takes exactly 4 hours (Plus about 13 minutes of final computing time).
Peace.
If you don’t have the patience to wait 45 minutes for a quality calibration then you could always spend several months learning how to rum ArgyllCMS directly. Just ignore Florian’s hard work to bring you a simplified and colorful interface. And see where that brings you.
You complain about something that has been freely handed to you? … A workable solution that makes quality calibrations accessible to you.
