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& On Dec 31, 2013, at 2:11 PM, BC Rider <bcrider99@xxxxxxxxxxx> wrote: > 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. >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
