- This topic has 15 replies, 4 voices, and was last updated 8 years ago by
.
-
Posts
-
I can’t quite figure out the issue I’m having. All I know is that I seem to be losing the bottom few values. Using a Colormunki, I’m trying to calibrate an NEC PA242 through Davinci Resolve (using the SpectraCal workflow) outputting through a blackmagic mini monitor. I’ve tried various combinations of things, but everything leads to the same result.
To make things simple, I’m using the video 3D LUT for Resolve preset as a starting point. That should help define the targets, etc. I’m aiming for. I’ve also read numerous things out there on what this could be, but am either not understanding it or the solutions don’t work for me.
Any help is truly appreciated. Thanks in advance.
Hi,
All I know is that I seem to be losing the bottom few values
How severe is the problem, i.e. how many levels do you loose, and how have you checked?
Using a Colormunki […]
ColorMunki Photo/Design or Display?
I’m using the video 3D LUT for Resolve preset as a starting point
Have you adjusted any of the preset target values? If so, which one(s) and to which new values?
Calibrite ColorChecker Studio on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.I am having a similar issue with my HP Dreamcolor z27x running via HDMI from a Black Magic Intensity Pro using the Resolve/3D LUT method. When running the output from resolve as ‘data levels’ the blacks are extremely crushed, but when I switch to ‘video levels’ the blacks return to a less-crushed, ‘normal’ state. I’m not sure if this has something to do with a bug in the Resolve calibration workflow in Displaycal, or if it more an issue on Black Magic’s end regarding their output cards (or their Desktop Video software), as the issue doesn’t occur on any of my other displays.
Hi Harry. I wish I could help you directly but don’t have that display. However, it would seem to indicate that the display is actually expecting video levels on the HDMI input. This may be configurable from the displays menu. Though I have noticed, sometimes this is only switchable for other inputs such DisplayPort.
In terms of the issue with DisplayCal. I think it may have come down to an impatient user error on my part due to the app freezing on larger patterns (and me wanting to test ways around it quicker). Just doing a few last tests and will report back soon.
I’m back to admit my mistakes 😉 And maybe point out a few things/issues.
The process that led me to my mistake:
– the application hangs on the first calibration. Right after the last swatch measurement, it doesn’t progress. I found another thread with a similar issue. Perhaps we can track down why this bug happens and solve it. After cancelling, it behaves well on subsequent attempts. Unfortunately I didn’t quite notice this issue until well into a few attempts.
– Which led me to try smaller test charts in order to not have to wait so long to see if the application froze and calibration failed. The test charts were so small in fact that it was no longer generating an XYZ LUT, but only curves. And with so few patches, I assume it didn’t have a chance to figure out the values down at the low end (and elsewhere). So this was my mistake and apologize for the confusion.Another bug (or something) I noticed that I thought I’d mention. During this process, I also came upon a strange profiling error that resulted in quite a jumble in the red values. Not sure what happened, but it hasn’t happened since.
– the application hangs on the first calibration. Right after the last swatch measurement, it doesn’t progress.
I’ve had a few reports of this in the past, but could never reproduce the issue myself. From the logs that people sent me I could see that they were running 1D LUT calibration as part of the overall process, and Argyll’s ‘dispcal’ command line tool wouldn’t exit after doing the last measurement. Is this the case for you as well? Which version of Argyll CMS are you using? It would help me if you could attach logs (“Tools” menu, “Show log window…”, click the small “Create compressed archive…” button which will create a ZIP archive including all relevant logs).
I also came upon a strange profiling error that resulted in quite a jumble in the red values.
Possibly a Resolve issue. The annoying thing about the Resolve inbuilt pattern generator is that it doesn’t send status information back (so there’s no way of checking if a pattern has been received by Resolve unless you examine the low-level network stack) and there can be considerable additional delay (not network delay) between Resolve receiving pattern values, and actual visual pattern change in Resolve (I measured up to around 500ms additional delay, and DisplayCAL uses 600ms to have a bit of headroom for that reason).
Thanks for the reply Florian. Yes, it definitely seems like there could have been an offset during the pattern generating/reading process. It was way off at a certain point, so it was easy to spot. But it definitely looks like it’s related to the timing related cause you described. Interesting to know.
As for the other issues. I’m running Argyll CMS 1.8.3. And yes, it seems to be the same behaviour you’re describing. Unfortunately, as always, now that I’m trying to recreate the bug on purpose it won’t happen. I just tried. Oddly, it happened everytime I previously tried. I’ll keep an eye on this though and will post a log when/if it happens again.
Unfortunately, as always, now that I’m trying to recreate the bug on purpose it won’t happen.
If you create a logs archive, the last seven days or so of logs will be included.
Hi Florian. Here’s a log of a calibration that was stuck after the swatch measurement for a long time. Seems to indicated measurements that didn’t go as expected. Not sure what caused it or what can be done here. Unfortunately there’s no way to know that this happened unless you cancel the process after a little while. This occurred a few times yesterday as well, and on the 3rd or 4th attempt it worked.
Please see the discussion over at AVSforum: http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms-135.html#post38694313
Hi Florian. I assume that’s in response to the Black level of Simoneov? I can post more logs as well. For some reason I can’t get calibrations to complete at all. I’ll do some more testing this evening.
I assume that’s in response to the Black level of Simoneov?
Yes, sorry.
For some reason I can’t get calibrations to complete at all.
You can just skip the calibration (set calibration tone curve to “As measured”).
Sorry, I mean the app just never finishes it’s measurements. It hangs after the last measured patch of the whole measurement procedure. Calibration of the device works fine. It then moves onto the measurements, but never finishes. I should have specific the difference between “hardware device calibration”, and the calibration/measurement that the app is built for.
