- This topic has 13 replies, 2 voices, and was last updated 7 years, 7 months ago by
.
-
Posts
-
Hi Florian.
Well, it happened again at the same spot…Please see attached the .icm file you requested.
Please let me know if you figure it out!
I’m soooo frustrated. 🙂
Steve.
Also, I saved the other 5 files in that folder while the program was still ‘running’… Just ask if you need them for more information.
I sure hope you can figure out why this keeps happening to me…So strange.
Anxiously awaiting your analytical expertise! 🙂
Steve.
OK, I looked at the log file and it seems to have some pertinent information this time.
See attached.
Anything?
I noticed that the RAM was mentioned a couple of times in the log file…I checked the RAM usage while the program was still running – Ram=4.9G used out of 7.7G available.
Also the processor is running at 39% @ 4.38GHz.
No harddrive activity.
I was running 5000 patches and a full calibration combo…I’ve successfully run 11,000 patches on the same machine in the past more than once.
I can leave the program running for a while if there is anything else I could send you… (Assuming of course that you happen to come online soon) .. 🙂
Thanks, that’s very helpful. I’m investigating what it is about the profile that makes targen slow to a crawl.
Thanks so much! I feel that I am in good hands, doctor! 🙁
I had a thought: Do you think that since so much RAM is being relied upon that maybe I have a RAM hardware issue, ie. bad RAM module? (Maybe it only shows up during RAM intensive operations like this one).
Please Florian, if you could get back to me as soon as you have further information about this, I’d really appreciate it… I want to do a calibration today, but my hands are tied!
I tried to do a ‘Profile only’ using that calibration file that seemed to complete, but it didn’t seem to work. No calibration embedded afterword… Maybe I did it wrong.
Talk to you soon, I hope.
Steve.
I had a thought: Do you think that since so much RAM is being relied upon that maybe I have a RAM hardware issue, ie. bad RAM module?
Very unlikely I think. With your specific preconditioning profile that you attached, and using the same parameters from the logfile, I can reproduce the issue every single time. It’s a curious problem, though, because when I run measurements on my displays, again with same parameters, it works flawlessly.
I want to do a calibration today, but my hands are tied!
You could use a testchart from a previous run (i.e. set the testchart on the “Profiling” tab to the respective .ti1 file instead of “Auto”).
No calibration embedded afterword… Maybe I did it wrong.
Did you make sure the calibration was loaded into the videoLUTs before starting the profiling?
I have another idea… I have i1 Profiler, CalMAN, and DisplayCAL installed on my system along with their respective loaders. I am constantly switching back and forth between them. (Enabling\disabling them in windows task manager ‘startup’) … I’m wondering if I accidentally left DisplayCAL’s loader disabled or set it to reset video card table while running a calibration. Does DisplayCAL need the loader running and enabled for the calibration to be loaded before the profile run initiates? , or maybe there is some conflictual interaction between programs.
Not sure, but I think it happens a lot when I set profiling patches to the 5000ish setting.
Just did one successfully at 7000 patches.
Note, the successful 7000 patch run that I just mentioned above was run after a complete reinstall of DisplayCAL.
I also turned off my system overclock and reset the UEFI back to default. (Just in case the overclock was unstable and causing corruption in the program during installation or during it’s running.)
Finally I did a registry cleaning.
Running out of ideas here!
Does DisplayCAL need the loader running and enabled for the calibration to be loaded before the profile run initiates?
It’s not important how the calibration is loaded into the videoLUTs, just that it is being performed by whichever means the respective software provides. For CalMAN, that is probably Client 3, for DisplayCAL, it’s the profile loader (and the respective profile containing the calibration needs to be assigned in Windows’ color management settings). If CalMAN is saving the calibration data elsewhere (not sure), you could also use DisplayCAL’s curve viewer to save the current calibration from the videoLUT to a file, and then drag’n’drop that into DisplayCAL to be used as a base for profiling.
maybe there is some conflictual interaction between programs
The CalMAN calibration loader (CalMAN Client 3) tray application unfortunately has very poor integration with Windows’ own color management settings – whenever it runs, it’ll overwite profile assignments in Windows’ color management control panel with its own assignments. Therefore, the DisplayCAL loader will disable itself upon detecting Client 3.
Running out of ideas here!
I don’t think there is currently anything that you can do – this looks to me like a rare bug in Argyll’s targen. I’ll keep you posted when I learn more.
OK, thanks for your help Florian… I’ll let you know of anything new that might point to the problem… But it seems if I stay away from the 5000 patches level I’m OK, so far!
Peace.
you could also use DisplayCAL’s curve viewer to save the current calibration from the videoLUT to a file, and then drag’n’drop that into DisplayCAL to be used as a base for profiling.
Do you think there would be any advantage in using CalMAN’s calibrations – then drop it into DispplayCAL to do the profile? … Or are do both programs produce the same calibration quality? – (Say set at maximum).
