Hey--
Got back around to this finally after being under the weather for the last
few days--
I've gotten the closest by assigning the profile for PrinterB as you
suggested, then converting to the profile for PrinterA. It doesn't seem to
matter at all what rendering intent I choose, which is odd, but Rel Col w/
BPC, without BPC, and AbsCol all gave the same result-- It's in kind of
the right direction, but not really that close at all if you look at
contrast or saturation of specific colors.
All the conversions have been done through photoshop at this point, I
haven't used cctiff for any of this, but I can't imagine that it would make
THAT much of a difference...
If i'm still not explaining this quite well enough, I wanted to try
reiterating in a different way--
Basically, I get a lot of requests from people who are not color savvy to
reproduce prints that they have made on their home/studio printers. Often
times they are very set on the exact characteristics of that specific
printer, which is commonly an Epson using a canned profile for whatever
type of paper they are using. The problem there is that they can't print
big enough, and I can, so now I have to match as exactly as possible what
that canned profile is doing on a different printer-- this often takes many
rounds of proofing until we get to the desired result, and even then it's
always somewhat of a compromise. It has been a thought in my head for
years that it should be possible with ICC profiles to match one printer to
another, after all, why wouldn't it be simply "this is what the red looks
like on printerA, and this is what it looks like on printerB, subtract one
from the other and you have your correction offets". Obviously if the
second printer doesn't have a wide enough gamut it might not be able to hit
certain targets, but it seems like this should be a relatively simple thing
to do... Isn't it kind of like throwing a colorchecker into a shot (known
values) and figuring out what's required to shift all colors to those
values?
-Cody
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.
On Thu, Feb 20, 2020 at 7:37 PM Cody Ranaldo <lessbones@xxxxxxxxx> wrote:
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:printer,
Cody Ranaldo wrote:
Hi,
Basically, what I'm attempting to do is simulate the output of one
attempting.through a (possibly old and outdated) ICC profile on another printer.
It's a little difficult to understand the nuances of what you are
though ?
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
same
The gamuts of the two devices are very similar, and the paper is the
thatpaper, 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
here'si've got the initial profiling charts set up properly, but anyway,
"iccprofileA.icc"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"
3[output initial abstract profile]
4. rebuild iccprofileA incorporating abstract profile generated in step
relativewith "-p" argument
5. print desired image through rebuilt iccprofileA converting with
in.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
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.
