[argyllcms] Re: ArgyllCMS V1.3.6 Released

  • From: János, Tóth F. <janos666@xxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 20 Mar 2012 04:32:23 +0100

Or can a strange value be true? (if let's say the same image may takes
10ms in one and 20ms on the next refresh because of some unknow reson
related to how they implement tricks in the panel driving scheme...? -
Just an idea...)

2012/3/20, János, Tóth F. <janos666@xxxxxxxxxx>:
> Sorry, it seems my earlier email got lost.
> But you figured it out anyway. :)
> Yes, this is indeed reasonable. Moreover, I am happy if:
> 1: the PDP uses the extra refreshes to offer finer dithering
> 2: The ArgyllCMS code can handle this nicely
> But the refresh measurements of a different PDP were slightly
> different from what I expected. I can't post the log now (it was
> included in the lost email but I am not at home now) but as I remember
> it was ~30ms in 60Hz mode where I would expect ~17 or ~33.
> Can I override this manually? (Set it to the closest theoretical value...)
> 2012/3/20, Graeme Gill <graeme@xxxxxxxxxxxxx>:
>> János, Tóth F. wrote:
>>> A different PDP from anoter manufacturer measured close to 42ms with
>>> 23.976Hz input.
>>> According to the spec sheet, it displays 24Hz at 96Hz (otherwise the
>>> screen would flicker like hell).
>>> But the reading felt more consistent on this PDP.
>>> What kind of data can I collect to investigate this further?
>>> (If there is anything to investigate - I am not sure what that number
>>> really means, I am just guessing...)
>> Hi,
>>      sorry, it's not clear to me exactly what you are
>> referring to. If you mean the i1d3 refresh mode, then the
>> measured refresh period will be the longest one found above
>> 20Hz (==50 msec). This errs on the conservative side and allows
>> for possible sub-harmonics in (say) a temporal dithering pattern.
>> As long as the measurement period (integration time) is a multiple
>> of the actual refresh period, it will have better repeatability than
>> a measurement period that isn't matched. So a 96Hz refresh
>> would be expected to result in a refresh period measurement
>> of 41.66 msec, rather than the true refresh period of 10.4167 msec.
>> Graeme Gill.

Other related posts: