Strange feature in Argyll profile.. How to fix?

[thadwald]

I just spent time printing and scanning a 3000 patch target using Argyll. Cursory prints with it appear fine, but I haven't used it all that much.

When viewing the profile in Mac ColorSync utility, I can see two points that look like the scanner misread them. They skew the otherwise smooth profile volume inwards at a single point.  Is there any way to remove them? Should I just redo the whole thing?

I could share the files if anyone is interested in taking a look at them.

[degrub]

PM the developer GWGILL

[GWGill]

When viewing the profile in Mac ColorSync utility, I can see two points that look like the scanner misread them.

When you say "scanner" I assume you mean "measure using a print measuring instrument".

There is a way of figuring this out, but it's quite a manual process.
You run profcheck -v2 -s on the .ti3 and the profile. The first
result will be the patch with the biggest disagreement.  Note the sample ID (integer before the ":").
Look at the .ti2 file, and locate the line with the sample ID. Note the SAMPLE_LOC - that
tells you which strip to re-read. chartread will let you navigate to the corresponding
strip and re-read it. (You might want to backup your .ti3 before you try this.)
You might want to re-read any other strips that contain patches with high delta-E
as well.

Re-make the profile and check the self-fit error. It should have dropped.
If you think you have got all the mis-reads, try your test print again.

[thadwald]

When you say "scanner" I assume you mean "measure using a print measuring instrument".

Yes, that is exactly what I mean. I'm using an eye-one Pro.

So if I understand correctly, if I run chartread again with an existing .ti3 file in place, it will just edit that file and replace the data on those strips that I read.

I assume that when you say "biggest disagreement" you mean in absolute terms and not relative to adjacent patches.

Thanks! I will give it a shot.

[thadwald]

To answer my own question, no, running chartread again will create a new file; backing up the .ti3 file is not optional.

With your help, I was able to identify a mechanical issue with my manual line reading process.

If anyone is interested, here is a little script that will merge changes from a second .ti3 file into an output file.


#!/bin/bash

# Usage: ./replace_lines.sh target.txt source.txt output.txt
# Arguments:
#   1. target.txt: The file to be modified.
#   2. source.txt: The file containing replacement data.
#   3. output.txt: The output file with replaced lines.

# Validate arguments
if [[ $# -ne 3 ]]; then
  echo "Usage: $0 target.txt source.txt output.txt"
  exit 1
fi

TARGET_FILE="$1"
SOURCE_FILE="$2"
OUTPUT_FILE="$3"

# Create a temporary file to store results
TMP_FILE=$(mktemp)

# Read the source file into a dictionary (associative array)
declare -A replacement_lines

while IFS= read -r line; do
  key=$(echo "$line" | awk '{print $1}') # Extract the leading number
  if [[ $key =~ ^[0-9]+$ ]]; then # Check if the key is purely numeric
    replacement_lines[$key]="$line"
  fi
done < "$SOURCE_FILE"

# Process the target file
while IFS= read -r line; do
  key=$(echo "$line" | awk '{print $1}') # Extract the leading number
  if [[ -n ${replacement_lines["$key"]} ]]; then
    echo "${replacement_lines["$key"]}" >> "$TMP_FILE"
  else
    echo "$line" >> "$TMP_FILE"
  fi
done < "$TARGET_FILE"

# Save results to the output file
mv "$TMP_FILE" "$OUTPUT_FILE"

echo "Lines replaced successfully. Output saved to $OUTPUT_FILE."

[GWGill]

To answer my own question, no, running chartread again will create a new file; backing up the .ti3 file is not optional.

I think chartread -r will resume/re-read rows or patches.