Monitor question

[Adam K]

Hi,
Thinking to upgrade my U2410 monitor with
NEC MultiSync PA271W-BK 27"
, is this monitor really good and easy to calibrate?
Thank you

[Roger Breton]

The best.



/ Roger



From: argyllcms-bounce-***@public.gmane.org [mailto:argyllcms-bounce-***@public.gmane.org]
On Behalf Of Adam K
Sent: Sunday, December 29, 2013 2:18 PM
To: argyllcms-***@public.gmane.org
Subject: [argyllcms] Monitor question



Hi,

Thinking to upgrade my U2410 monitor with


NEC MultiSync PA271W-BK 27"


, is this monitor really good and easy to calibrate?


Thank you

[Adam K]

Really?

Post by Roger Breton
The best.
/ Roger
*Sent:* Sunday, December 29, 2013 2:18 PM
*Subject:* [argyllcms] Monitor question
Hi,
Thinking to upgrade my U2410 monitor with
NEC MultiSync PA271W-BK 27"
, is this monitor really good and easy to calibrate?
Thank you
--
Adam Kielcz

--
Adam Kielcz

Note: If you forward this email, please delete the forwarding
history, which includes my email address and any others you see in
this email. It is a courtesy to me and others who may not wish to have
their email addresses sent all over the world. Erasing the history
also helps prevent Spammers from gathering addresses and prevents
viruses from being sent to your friends and mine.
---------------------------------------------------------------------------------------
No trees were harmed in the posting of this message . . . however an
extraordinarily large number of electrons were horribly
inconvenienced.

[Andreas F.X. Siegert]

Post by Adam K
Really?
The best.____

You could by the SpectraView Reference variant from NEC which has been
hand selected.
Or an Eizo CG series but suffer the fan noise.
Since Quato went belly up, there are not many high quality screens
available. And Quato was modified NECs anyway.

So yes, a NEC PA series screen is definitely in the top tier.

You might want to look at the newer LED backlit PAxx2 models instead of
the CCFL backlit PAxx1 series. Usually a bit better contrast, less
aggressive coating, but more backlight bleed.
Check out the review section of prad.de for serious reviews (not all
reviews are translated to English though).

cheers
afx

[Arie]

One more thing to consider is that most ips screens are all made by the same manufacturer: LG. Individual monitor vendors make their own modifications (the coating, LUT access). But effectively, the NEC monitors use the same screens as Dell's ultrasharp range. I'd have a careful look at the NEC versus your current Dell before I would pull the trigger. You'll pay a lot more but you won't get a night-and-day difference.

Sent from my iPad

Post by Adam K
Really?
The best.____

You could by the SpectraView Reference variant from NEC which has been hand selected.
Or an Eizo CG series but suffer the fan noise.
Since Quato went belly up, there are not many high quality screens available. And Quato was modified NECs anyway.
So yes, a NEC PA series screen is definitely in the top tier.
You might want to look at the newer LED backlit PAxx2 models instead of the CCFL backlit PAxx1 series. Usually a bit better contrast, less aggressive coating, but more backlight bleed.
Check out the review section of prad.de for serious reviews (not all reviews are translated to English though).
cheers
afx
--
http://afximages.com/

[BC Rider]

Hi,

REQUEST: Currently Chartread can only populate one file when reading a printer target. My request is for Chartread to be upgraded to populate multiple (N) files by doing multiple (N) scans on each row before proceeding to the next row to scan.

BACKGROUND: I use a ColorMunki and typically print my target once but read it multiple times and then verify and average the results. This greatly improves the noise quality of the measurements prior to making the profile.

Currently multiple reads greatly increase the total time required. If, for example, scanning a single target takes 15 minutes then scanning the target four times will take an hour (one literally has to do everything four times). But the vast majority of the time is in moving and lining up the ruler for a given row. The actual scanning time and effort is trivial.

If one could instead scan the row four times before moving the ruler onto the next row, the total time (four scans) would not be much different than the time for a single scan. This suddenly makes multiple scans and averaging an easy process!

POSSIBLE IMPLEMENTATION: Change Chartread to take N files, with the first one being the normal INOUTFILE (Ti2/Ti3) and the remainder specifying subsequent output only files (Ti3). In actual use chartread will then scan N times putting each scan into separate files before moving on to the next row.

[Ben Goren]

I'd very much appreciate something like this, too -- and for spotread as well.

Perhaps, rather than create multiple files and have to deal with that, chartread and spotread could do the averaging in-memory before writing the final averaged values to disk? Unless one is interested in determining the behavior of the instrument, I don't see the advantage of hanging on to the intermediate values.

Cheers,

b&

Post by BC Rider
Hi,
REQUEST: Currently Chartread can only populate one file when reading a printer target. My request is for Chartread to be upgraded to populate multiple (N) files by doing multiple (N) scans on each row before proceeding to the next row to scan.
BACKGROUND: I use a ColorMunki and typically print my target once but read it multiple times and then verify and average the results. This greatly improves the noise quality of the measurements prior to making the profile.
Currently multiple reads greatly increase the total time required. If, for example, scanning a single target takes 15 minutes then scanning the target four times will take an hour (one literally has to do everything four times). But the vast majority of the time is in moving and lining up the ruler for a given row. The actual scanning time and effort is trivial.
If one could instead scan the row four times before moving the ruler onto the next row, the total time (four scans) would not be much different than the time for a single scan. This suddenly makes multiple scans and averaging an easy process!
POSSIBLE IMPLEMENTATION: Change Chartread to take N files, with the first one being the normal INOUTFILE (Ti2/Ti3) and the remainder specifying subsequent output only files (Ti3). In actual use chartread will then scan N times putting each scan into separate files before moving on to the next row.

[Graeme Gill]

Post by Ben Goren
I'd very much appreciate something like this, too -- and for spotread as well.

Hi,
I'm not sure what you mean WRT to spotread. Doesn't the -V option give
you this sort of functionality ?

<http://www.argyllcms.com/doc/spotread.html#V>

Post by Ben Goren
Perhaps, rather than create multiple files and have to deal with that, chartread and
spotread could do the averaging in-memory before writing the final averaged values to disk?
Unless one is interested in determining the behavior of the instrument, I don't see the
advantage of hanging on to the intermediate values.

Writing multiple results to disk when being read interleaved would be complicated and
messy. messy == unreliable code. Even doing averaging in memory means adding a degree
of elaboration, since currently chartread saves readings directly to the CGATS object.

Setting an outlier threshold value is not very desirable from a UI point of view,
since it is yet another parameter that people will wonder how to set.

I think it is possible to make a reasonable attempt to recognize outliers automatically
using robust mean type function, if a sufficient number of readings is done - ie. you
can't detect an outlier with less than 3 readings.

Graeme Gill.

[Ben Goren]

Post by Graeme Gill

Post by Ben Goren
I'd very much appreciate something like this, too -- and for spotread as well.

I'm not sure what you mean WRT to spotread. Doesn't the -V option give
you this sort of functionality ?

I don't think so.

The scenario I have in mind is measuring a camera profiling chart. For physical reasons, I can't do this in strip mode. I imagine I could hack together a suitable .ti2 file and use chartread in spot mode, but that seems unwieldily (though maybe it's a better option?). What I do is use spotread to write to a file, and then do a little bit of tweaking in a text editor to turn that file into the relevant sections of the .cie and .cht files.

It would be really nice to have some sort of super-accurate mode for this sort of thing, whether that means merging multiple readings or an especially long integration time or whatever.

Post by Graeme Gill
Writing multiple results to disk when being read interleaved would be complicated and
messy.

I can imagine.

How about, for chartread, attacking it from the other end? If chartread were to let you scan the same strip multiple times and write each to the same single .ti3 file, would colprof be smart enough to treat them as if they were additional patches on the chart? Seems to me that might not only be the simplest way to code it, but the one with the best chances of improving quality.

Cheers,

b&

[Graeme Gill]

Ben Goren wrote:

Hi,

Post by Ben Goren
file and use chartread in spot mode, but that seems unwieldily (though maybe it's a

So you are really talking about chartread in patch by patch mode, not spotread ?

Post by Ben Goren
How about, for chartread, attacking it from the other end? If chartread were to let you
scan the same strip multiple times and write each to the same single .ti3 file, would
colprof be smart enough to treat them as if they were additional patches on the chart?
Seems to me that might not only be the simplest way to code it, but the one with the
best chances of improving quality.

I'm thinking more along the lines of a flag to chartread that turns repeated
reads into robust averages rather than replacing the previous values.

So it would track the maximum number of reads of any strip/patch, and set that
as a target for each strip (or perhaps that could be an optional argument to
the flag). So typically you would read the first strip/patch the number of
times you want, and then it will not automatically advance on the next
strips/patches until you've done the same number of reads. Perhaps I can
print the worst case number of readings used in the average for each strip/patch too,
to track how many outliers are present.

Graeme Gill.

[Ben Goren]

Post by Graeme Gill

Post by Ben Goren
file and use chartread in spot mode, but that seems unwieldily (though maybe it's a

So you are really talking about chartread in patch by patch mode, not spotread ?

No, I'm actually using spotread, but in a manner not unlike how one would use chartread. But rather than go through the bother of creating .ti2 files to feed to chartread, I just save the output of spotread to a file (and then use vi to turn that into the relevant bits of the .cie and .cht files).

(Actually, for a 24 x 36 patch chart, I'll do each row separately to separate files so I can recover more readily from the inevitable brain farts.)

Post by Graeme Gill
I'm thinking more along the lines of a flag to chartread that turns repeated
reads into robust averages rather than replacing the previous values.

That sounds good to me. This is certainly much more your area of expertise than mine, such that I'm sure we're at that point where whatever you come up with is going to be better than whatever I think of.

Cheers,

b&

[Graeme Gill]

Post by Ben Goren
No, I'm actually using spotread, but in a manner not unlike how one would use
chartread. But rather than go through the bother of creating .ti2 files to feed to
chartread, I just save the output of spotread to a file (and then use vi to turn that
into the relevant bits of the .cie and .cht files).

Hmm. I'll have to think about that. I'm not sure if it's a good fit for
spotread though.

Graeme Gill.

[BC Rider]

----------------------------------------

Date: Thu, 2 Jan 2014 10:56:09 +1100
Subject: [argyllcms] Re: Feature Request - Chartread Multiple Scans
Setting an outlier threshold value is not very desirable from a UI point of view,
since it is yet another parameter that people will wonder how to set.

Yes, it is preferable for the program to automatically handle it.

A minimum of three for outlier detection seems OK. One needs minimum two for averaging in any case! Based on my tests, I'd probably use four.

Even doing averaging in memory means adding a degree of elaboration,
since currently chartread saves readings directly to the CGATS object.

Though not preferred, the original idea of creating/populating N CGATS objects and then writing them out as separate files sounds easier then.

I can't speak to the coding difficulties but the benefits of doing something are significant. Currently the overhead for extra averaging scans is quite high compared to intrinsically required. Hopefully something can be done.

[Elena [service address]]

I agree! Such a feature would be very useful indeed, and could save much time when
averaging multiple readings !
However I think keeping separate reading files just adds up mess since one will have
then to average them by hand and/or to cope with all those files.
Here's how I would implement it: an option to always make N scans of every line,
which will then be automatically averaged into a single file.
After N scans, the program would output a warning message if it detects that
some patterns differ too much between different scans (that could be a hint for the
user that something went wrong, and the program could ask him if he'd like to scan
the suspected problematic line again).
Of course the program should also be able to detect whether the user mistakenly
skipped to the next line before completing all the N scans (something that could
happen)

/&



Hello BC

Post by BC Rider
Hi,
REQUEST: Currently Chartread can only populate one file when reading a printer target. My request is for Chartread to be upgraded to populate multiple (N) files by doing multiple (N) scans on each row before proceeding to the next row to scan.
BACKGROUND: I use a ColorMunki and typically print my target once but read it multiple times and then verify and average the results. This greatly improves the noise quality of the measurements prior to making the profile.
Currently multiple reads greatly increase the total time required. If, for example, scanning a single target takes 15 minutes then scanning the target four times will take an hour (one literally has to do everything four times). But the vast majority of the time is in moving and lining up the ruler for a given row. The actual scanning time and effort is trivial.
If one could instead scan the row four times before moving the ruler onto the next row, the total time (four scans) would not be much different than the time for a single scan. This suddenly makes multiple scans and averaging an easy process!
POSSIBLE IMPLEMENTATION: Change Chartread to take N files, with the first one being the normal INOUTFILE (Ti2/Ti3) and the remainder specifying subsequent output only files (Ti3). In actual use chartread will then scan N times putting each scan into separate files before moving on to the next row.

Regards

[Serhat Abaci]

Sign me up for that! I own a munki too and doing this most of the time to
get accurate results

Post by Elena [service address]
I agree! Such a feature would be very useful indeed, and could save much time when
averaging multiple readings !
However I think keeping separate reading files just adds up mess since one will have
then to average them by hand and/or to cope with all those files.
Here's how I would implement it: an option to always make N scans of every line,
which will then be automatically averaged into a single file.
After N scans, the program would output a warning message if it detects that
some patterns differ too much between different scans (that could be a hint for the
user that something went wrong, and the program could ask him if he'd like to scan
the suspected problematic line again).
Of course the program should also be able to detect whether the user mistakenly
skipped to the next line before completing all the N scans (something that could
happen)
/&
Hello BC

Post by BC Rider
Hi,
REQUEST: Currently Chartread can only populate one file when reading a

printer target. My request is for Chartread to be upgraded to populate
multiple (N) files by doing multiple (N) scans on each row before
proceeding to the next row to scan.

Post by BC Rider
BACKGROUND: I use a ColorMunki and typically print my target once but

read it multiple times and then verify and average the results. This
greatly improves the noise quality of the measurements prior to making the
profile.

Post by BC Rider
Currently multiple reads greatly increase the total time required. If,

for example, scanning a single target takes 15 minutes then scanning the
target four times will take an hour (one literally has to do everything
four times). But the vast majority of the time is in moving and lining up
the ruler for a given row. The actual scanning time and effort is trivial.

Post by BC Rider
If one could instead scan the row four times before moving the ruler

onto the next row, the total time (four scans) would not be much different
than the time for a single scan. This suddenly makes multiple scans and
averaging an easy process!

Post by BC Rider
POSSIBLE IMPLEMENTATION: Change Chartread to take N files, with the

first one being the normal INOUTFILE (Ti2/Ti3) and the remainder specifying
subsequent output only files (Ti3). In actual use chartread will then scan
N times putting each scan into separate files before moving on to the next
row.
Regards

[BC Rider]

Post by Ben Goren
do the averaging in-memory before writing the final averaged values to disk? Unless one is interested in determining
the behavior of the instrument, I don't see the advantage of hanging on to the intermediate values.

I avoided this approach only because sometimes one gets outliers that should NOT be averaged (rather one should rescan the line with the chartread -r command and THEN average with the other readings once corrected). Currently that means separate files, then verify to confirm no outliers (a very important step), then average.

If that issue is addressed then I agree in-memory averaging would be better.

Elena's idea seems good. Chartread would need a user settable dE tolerance, at the end of the N scans the lines would be checked and rescan requested until the lines meet the dE tolerance (or user can give up at any time). This actually greatly simplifies the process of using verify and manually identifying outliers and manually rescanning if outliers found.

[Adam K]

Hi,
Thank you for all replies about NEC monitor.
Now, is much cheaper $350 *HP 27" WQHD LED
<http://woot.us1.list-manage1.com/track/click?u=e6217fba00b9cdcae52e4e72e&id=e00a75984b&e=12ac69e7a1>monitor*
worth
considering?

[Arie]

Hi Adam

First question: what is wrong with your current Dell Ultrasharp? It is a very good monitor by any measure.

Second question: what is your budget?

Third question: what will be the primary use for the monitor? And what else will you do on it?

Yours

Arie

Sent from my iPad

Post by Adam K
Hi,
Thank you for all replies about NEC monitor.
Now, is much cheaper $350 HP 27" WQHD LED monitor worth considering?
--
Adam Kielcz

[Adam K]

Arie,
Nothing is wrong with U2410.
I mainly edit photos on it.
You're right I'll keep it for now.
Thank you!

A. Kielcz

Post by Arie
Hi Adam
First question: what is wrong with your current Dell Ultrasharp? It is a very good monitor by any measure.
Second question: what is your budget?
Third question: what will be the primary use for the monitor? And what else will you do on it?
Yours
Arie
Sent from my iPad

Post by Adam K
Hi,
Thank you for all replies about NEC monitor.
Now, is much cheaper $350 HP 27" WQHD LED monitor worth considering?
--
Adam Kielcz

[BC Rider]

Hi,

I had a narrow strip of "Red River Ultra Pro Satin v3" paper left over so did a quick drift/noise test of the ColorMunki.

I created a two line target where each line consisted of 37 patches of the same color. I Then scanned the results. One line was dark purple (LAB=15, 41, -47) and the other light yellow (LAB= 74, 0.28, 72).

The patches were 8.2mm square and the lines about 330mm long. My guide won't align only two lines so I used a regular ruler and centered the Munki by eye. So this *could* be a source of error since patches this small really should have a mechanical centering guide.

I've attached screen shots of the L values graphed in Excel. There doesn't seem to be any particular drift and the variance is about +/- 0.1 dE2000 (which obviously includes the variance in the paper).

Unfortunately I have nothing to compare it to so can't say whether these results are good, bad or distinctly average. They *seem* decent to me. Maybe someone with some experience can comment?

Also FWIW, I scanned using chartread -T 0.2. There were no errors flagged. It would be interesting to know how this setting equates to allowable reading accuracy. I haven't a clue on that one.

Anyway, I thought some might be interested in the results so posted here.

[Graeme Gill]

Post by BC Rider
I've attached screen shots of the L values graphed in Excel. There doesn't seem to be
any particular drift and the variance is about +/- 0.1 dE2000 (which obviously includes
the variance in the paper).

Hi,

This would seem to be very good for a strip read consistency. The Munki is a bit more
repeatable than the i1pro due to the LED being a more repeatable light source,
but variation due to paper texture is typically of the order of 0.1 DE.

[ Note the i1pro has better low level repeatability due to electrical
sensor noise interference in the Munki. ]

If you look at <http://www.argyllcms.com/doc/i1proDriver.html>
then I got repeatability of the order of 0.01 DE for the i1pro under very carefully
controlled conditions, which included not moving the instrument so as to eliminate
paper and patch variation, as well as using longer spot reading mode. As soon
as the instrument is moved the repeatability typically drops to 0.1 DE or worse,
depending on the media and the printer.

Post by BC Rider
Also FWIW, I scanned using chartread -T 0.2. There were no errors flagged. It would
be interesting to know how this setting equates to allowable reading accuracy. I
haven't a clue on that one.

That option was intended to let more variable media (such as cloth) work.

Graeme Gill.