Thanks Graeme—
I understand the workflow you’ve defined and I’ll give it a go tomorrow— I
think this is kind of aligned with my thinking in the beginning, but things
have gotten so convoluted that I keep forgetting where all the pieces are
supposed to fall—
I don’t have a way to control the colors on PrinterB, so I’m trying to
characterize it’s output so I can reproduce it’s malformed state on PrinterA—
essentially like trying to emulate an unprofiled display on a profiled one, but
specifically PrinterB’s type of unprofiledness, not just a random condition.
So I have complete control over the profile of the proofing printer, but no
control over the printer to be simulated, much as when one is trying to
simulate a proofing condition for a CMYK press on an inkjet, except we’re
staying in RGB. Regardless, I think you understood correctly, so let me report
back once I’ve tried what you have described. I was hoping that I could also
do iterative corrections to get the tolerances lower, also like when proofing
using a RIP like EFI or GMG—
-Cody
On Feb 20, 2020, at 6:29 PM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
Cody Ranaldo wrote:
Hi,
Basically, what I'm attempting to do is simulate the output of one printer,
through a (possibly old and outdated) ICC profile on another printer.
It's a little difficult to understand the nuances of what you are attempting.
If the profile you are using on your proofing printer is not accurate
because it is old and outdated, you a pretty much doomed, because this
is admitting that you don't have exact control over what colors
your proofing printer is going to print. (It's like using an
un-profiled display to evaluate images.) Is this what you were saying though ?
The gamuts of the two devices are very similar, and the paper is the same
paper, so there is not a ton of wiggle room here as there would be when
simulating a printing press on an inkjet printer. I'm fairly certain that
i've got the initial profiling charts set up properly, but anyway, here's
the workflow thus far:
PrinterA (my printer)
PrinterB (printer to be simulated)
1. Print RGB color chart with PrinterA with color management turned off.
This is used to generate an ICC profile describing this printer.
2. Print same RGB color chart with PrinterB with profile to be simulated
assigned (no number conversion) and measured.
3. refine -v -c "measuredchartB.ti3" "measuredchartA.ti3" "iccprofileA.icc"
[output initial abstract profile]
4. rebuild iccprofileA incorporating abstract profile generated in step 3
with "-p" argument
5. print desired image through rebuilt iccprofileA converting with relative
colorimetric
Sounds complicated. There are other simpler to understand
workflows that may give the result you want:
1) Profile Printer B in the configuration you want to emulate.
This defines the input space you are declaring your RGB images to be in.
2) Profile Printer A as accurately as you can, so that it can be
your proofing printer.
3) Print your images through profile B linked to Profile A. i.e.
define the Printer B profile as your RGB source space, and your
printer A as your destination space.
So tagging your images with the PrinterB profile effectively
converts the image RGB to the color PrinterB would produce (i.e.
think PCS/XYZ/Lab values), and then you can proof that on whatever
accurately profiled output device you have available, such as PrinterA.
You need to take care of choosing the correct intent for
each profile to achieve whatever you want, but typically
relative colorimetric if the paper is the same.
For better accuracy and more flexibility you could link
the two profiles into a device link and proof that way.
(Typical workflow with a device link would be to
convert RGB to RGB using the link using (say) cctiff,
then print to PrinterA with color management turned off,
the same way you printed the profile chart. This all
assumes that both printers are driven in RGB mode.)
If this isn't what you are trying to achieve, then
perhaps you need to explain in a bit more detail.
Cheers,
Graeme Gill.
