Workflow for ‘remote’ profiling a non-colormanaged printer as a ‘back-box’
Hi color sync users. This is a question about my workflow for ‘remote’ profiling a non-colormanaged printer as a ‘back-box’. And if you can see any obvious mistakes in my workflow / thinking. One of our staff is using an external non-colormanaged print provider. And I'm wanting to help him prepare work for it. Test prints to this printer are in AdobeRGB1998 and prints come out over saturated. So I am attempting to profile the print process ‘remotely’ using i1 profiler. And to do the color conversion ourselves. I am familiar with profiling inkjet and laser printers where I work using i1Profiler, FieryXF and ColorBurstRIP. I thought it would be a fairly straight forward process, but I’m getting some unexpected results. I am not in a position to control this external printer in any way. I have already had TC918 RGB patches printed on this printer (patches assigned AdobeRGB1998) and I created a printer RGB ICC profile of this process. When I assign this printer profile to the original AdobeRGB1998 test image we printed I get a very good approximation of the over saturated test print we got. So far so good. So I Imagined I just needed to use Convert-to-Profile on our AdobeRGB1998 test image, to convert it into the printer color space that I built. Then to ensure it gets handled by the external printer in exactly the same way as before, I just assign it AdobeRGB1998 again. When I do that, the test image now appears less saturated than it was before. Great, that’s just what I would expect. With the boost of saturation of this print process it should return back to normal when printed. But what I did not expect was that the blackest pixels in the converted test image that started out as RGB 4,4,9 are now RGB 30,29,28 after conversion. That sounds crazy to me! I have not printed this converted test image yet. I don’t want to waste my money printing this converted file if I have got this wrong. But everything else looks like what I would expect. Anyone else familiar with profiling printers as a 'Black-box'?, is this kind of thing with the high black point normal? Thanks Peter Miles
What type of printer are we talking about here? Are you completely sure it’s not color managed? Is there a RIP involved? Are you sure this is an RGB profiled process? The fact that your AdobeRGB files look over saturaturated could suggest that it is color managed and is assuming sRGB for these files. Either way, I’d send the profiling targets untagged and simply convert images to you custom profile and again send as untagged. Scott Martin www.on-sight.com Imaging Science for Art
On Jul 14, 2021, at 8:45 PM, Miles, Peter via colorsync-users <colorsync-users@lists.apple.com> wrote:
Hi color sync users.
This is a question about my workflow for ‘remote’ profiling a non-colormanaged printer as a ‘back-box’. And if you can see any obvious mistakes in my workflow / thinking.
One of our staff is using an external non-colormanaged print provider. And I'm wanting to help him prepare work for it. Test prints to this printer are in AdobeRGB1998 and prints come out over saturated.
So I am attempting to profile the print process ‘remotely’ using i1 profiler. And to do the color conversion ourselves. I am familiar with profiling inkjet and laser printers where I work using i1Profiler, FieryXF and ColorBurstRIP. I thought it would be a fairly straight forward process, but I’m getting some unexpected results.
I am not in a position to control this external printer in any way. I have already had TC918 RGB patches printed on this printer (patches assigned AdobeRGB1998) and I created a printer RGB ICC profile of this process. When I assign this printer profile to the original AdobeRGB1998 test image we printed I get a very good approximation of the over saturated test print we got. So far so good.
So I Imagined I just needed to use Convert-to-Profile on our AdobeRGB1998 test image, to convert it into the printer color space that I built. Then to ensure it gets handled by the external printer in exactly the same way as before, I just assign it AdobeRGB1998 again.
When I do that, the test image now appears less saturated than it was before. Great, that’s just what I would expect. With the boost of saturation of this print process it should return back to normal when printed.
But what I did not expect was that the blackest pixels in the converted test image that started out as RGB 4,4,9 are now RGB 30,29,28 after conversion. That sounds crazy to me! I have not printed this converted test image yet. I don’t want to waste my money printing this converted file if I have got this wrong. But everything else looks like what I would expect.
Anyone else familiar with profiling printers as a 'Black-box'?, is this kind of thing with the high black point normal?
Thanks Peter Miles _______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/scott%40on-sight.com
This email sent to scott@on-sight.com
What is the first rule of characterization? A: The print condition must be consistent. Media coating. Humidity. Print driver settings. Can that be guaranteed? Even if it can, print condition optimization for end point aims and dot gain are missing. Don’t settle for hamburger when you need a tenderloin steak. - Jon Sent from my iPhone
On Jul 15, 2021, at 2:16 AM, Scott Martin via colorsync-users <colorsync-users@lists.apple.com> wrote:
What type of printer are we talking about here?
Are you completely sure it’s not color managed? Is there a RIP involved? Are you sure this is an RGB profiled process?
The fact that your AdobeRGB files look over saturaturated could suggest that it is color managed and is assuming sRGB for these files.
Either way, I’d send the profiling targets untagged and simply convert images to you custom profile and again send as untagged.
Scott Martin www.on-sight.com Imaging Science for Art
On Jul 14, 2021, at 8:45 PM, Miles, Peter via colorsync-users <colorsync-users@lists.apple.com> wrote:
Hi color sync users.
This is a question about my workflow for ‘remote’ profiling a non-colormanaged printer as a ‘back-box’. And if you can see any obvious mistakes in my workflow / thinking.
One of our staff is using an external non-colormanaged print provider. And I'm wanting to help him prepare work for it. Test prints to this printer are in AdobeRGB1998 and prints come out over saturated.
So I am attempting to profile the print process ‘remotely’ using i1 profiler. And to do the color conversion ourselves. I am familiar with profiling inkjet and laser printers where I work using i1Profiler, FieryXF and ColorBurstRIP. I thought it would be a fairly straight forward process, but I’m getting some unexpected results.
I am not in a position to control this external printer in any way. I have already had TC918 RGB patches printed on this printer (patches assigned AdobeRGB1998) and I created a printer RGB ICC profile of this process. When I assign this printer profile to the original AdobeRGB1998 test image we printed I get a very good approximation of the over saturated test print we got. So far so good.
So I Imagined I just needed to use Convert-to-Profile on our AdobeRGB1998 test image, to convert it into the printer color space that I built. Then to ensure it gets handled by the external printer in exactly the same way as before, I just assign it AdobeRGB1998 again.
When I do that, the test image now appears less saturated than it was before. Great, that’s just what I would expect. With the boost of saturation of this print process it should return back to normal when printed.
But what I did not expect was that the blackest pixels in the converted test image that started out as RGB 4,4,9 are now RGB 30,29,28 after conversion. That sounds crazy to me! I have not printed this converted test image yet. I don’t want to waste my money printing this converted file if I have got this wrong. But everything else looks like what I would expect.
Anyone else familiar with profiling printers as a 'Black-box'?, is this kind of thing with the high black point normal?
Thanks Peter Miles _______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/scott%40on-sight.com
This email sent to scott@on-sight.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/jonmeyer%40grafixgea...
This email sent to jonmeyer@grafixgear.com
Hi Scott Thank you for your thoughts. They have been very helpful in clarifying my thinking. My responses are below. From: Scott Martin <scott@on-sight.com<mailto:scott@on-sight.com>> Subject: Re: Workflow for ‘remote’ profiling a non-colormanaged printer as a ‘back-box’ <snip> What type of printer are we talking about here? <end snip> Our staff member is not sure other than it’s a vinyl ‘banner’ printer. I am guessing some kind of grand format inkjet. He says the media for this printer is about 3 meters wide, or there abouts. The vinyl prints are going to be 3.5 x 4 meters. I have asked him to get more details. <snip> Are you completely sure it’s not color managed? <end snip> I think it is colour manged, but not as well as we would like. Judging by the test print. (looking in our GTI viewing booth). The staff member was originally asked to provide files as “cmyk pdf’s”. I asked him to find out what color space they want the cmyk in. He later told me the shop was surprised by that question and had suggested “US SWOP coated V2 should be ok”. Some of the image colours we are trying to hit are outside that gamut. I asked him to see if the shop would accept PDFs in AdobeRGB 1998. (The files are natively AdobeRGB1998.) They told him that they were ‘very happy’ with AdobeRGB 1998 pdfs. So that’s what I prepared. <snip> Is there a RIP involved? <end snip> Yes. <snip> Are you sure this is an RGB profiled process? <end snip> I would be very surprised if the printer was being handled as an RGB device by the RIP. I choose to profile their RGB pipeline rather than their CMYK pipeline because I suspected that an RGB pipeline ‘happy’ with AdobeRGB1998 to be more likely to hit our saturated image colors than a CMYK pipeline expecting US SWOP coated V2. Conceptually, for profiling purposes, I am treating the RGB pipeline as if it were a black-box, with a ‘front end’ that takes untagged RGB content, Assigns it AdobeRGB1998, turns it into a PDF and then processes and prints it. Except that the ‘font end’ steps above I’m actually doing myself. I am doing those extra steps because I am hoping to get a wider gamut response from their printer by presenting it with AdobeRGB1998 tagged files. ( That’s why I sent the profiling patches as AdobeRGB1998 tagged pdf’s.) <snip> The fact that your AdobeRGB files look over saturated could suggest that it is color managed and is assuming sRGB for these files. <end snip> Thanks Scott. I didn’t think of that! I will have a look tomorrow when I’m back at work. <snip> Either way, I’d send the profiling targets untagged and simply convert images to you custom profile and again send as untagged. <end snip> Thanks Scott, sending untagged RGB would have been a lot simpler. But I feel reassured that essentially my work flow is sound. And the black point would lift? On reflection, wouldn’t that suggest that the print process is either clipping or compressing near-blacks in image? Or both? regards Peter Miles On Jul 14, 2021, at 8:45 PM, Miles, Peter via colorsync-users <colorsync-users@lists.apple.com<mailto:colorsync-users@lists.apple.com>> wrote: Hi color sync users. This is a question about my workflow for ‘remote’ profiling a non-colormanaged printer as a ‘back-box’. And if you can see any obvious mistakes in my workflow / thinking. One of our staff is using an external non-colormanaged print provider. And I'm wanting to help him prepare work for it. Test prints to this printer are in AdobeRGB1998 and prints come out over saturated. So I am attempting to profile the print process ‘remotely’ using i1 profiler. And to do the color conversion ourselves. I am familiar with profiling inkjet and laser printers where I work using i1Profiler, FieryXF and ColorBurstRIP. I thought it would be a fairly straight forward process, but I’m getting some unexpected results. I am not in a position to control this external printer in any way. I have already had TC918 RGB patches printed on this printer (patches assigned AdobeRGB1998) and I created a printer RGB ICC profile of this process. When I assign this printer profile to the original AdobeRGB1998 test image we printed I get a very good approximation of the over saturated test print we got. So far so good. So I Imagined I just needed to use Convert-to-Profile on our AdobeRGB1998 test image, to convert it into the printer color space that I built. Then to ensure it gets handled by the external printer in exactly the same way as before, I just assign it AdobeRGB1998 again. When I do that, the test image now appears less saturated than it was before. Great, that’s just what I would expect. With the boost of saturation of this print process it should return back to normal when printed. But what I did not expect was that the blackest pixels in the converted test image that started out as RGB 4,4,9 are now RGB 30,29,28 after conversion. That sounds crazy to me! I have not printed this converted test image yet. I don’t want to waste my money printing this converted file if I have got this wrong. But everything else looks like what I would expect. Anyone else familiar with profiling printers as a 'Black-box'?, is this kind of thing with the high black point normal? Thanks Peter Miles ________________________
On Jul 15, 2021, at 6:22 AM, Miles, Peter via colorsync-users <colorsync-users@lists.apple.com> wrote:
<snip> What type of printer are we talking about here? <end snip> Our staff member is not sure other than it’s a vinyl ‘banner’ printer. I am guessing some kind of grand format inkjet. He says the media for this printer is about 3 meters wide, or there abouts. The vinyl prints are going to be 3.5 x 4 meters. I have asked him to get more details.
I’ve tried to tackle this sort of problem before, not necessarily in the graphic arts industry. No good can come of it. I’m sure you’re aware that no company that builds custom profiles would touch this job with a ten-foot pole. The reasons they wouldn’t are the same reasons you shouldn’t. Take a step back, do it right. Insist that they do their part, such as tell you the exact make and model of the printer, what brand and type of media they’re printing on, what software they’re using to print, the works. The person at the other end can read the model number from the printer, from the box of media, all that sort of stuff. It’s a large-format printer; does this model automatically detect media types? If not, what media type does the printer think it’s printing to? I’ll bet you a cup of coffee that simply doing all this essential preliminary stuff will magically solve the problem. And, if it doesn’t, at least you’ll know what you’re dealing with. b&
On Jul 15, 2021, at 8:00 AM, Ben Goren via colorsync-users <colorsync-users@lists.apple.com> wrote:
I’ve tried to tackle this sort of problem before, not necessarily in the graphic arts industry.
No good can come of it.
+1 But even before this point, the OP should at the very least send the same untagged (yes untagged) profile target to the output device, say once a week for a month and plot the dE. If it’s off by a mile, which is quite likely, no reason to even consider a profile. Andrew Rodney http://www.digitaldog.net/ <http://www.digitaldog.net/>
“. . . send . . . target . . . once a week for a month and plot the dE."
That sounds like time and money. Hery Davis
On Jul 15, 2021, at 12:04 PM, Andrew Rodney via colorsync-users <colorsync-users@lists.apple.com> wrote:
On Jul 15, 2021, at 8:00 AM, Ben Goren via colorsync-users <colorsync-users@lists.apple.com> wrote:
I’ve tried to tackle this sort of problem before, not necessarily in the graphic arts industry.
No good can come of it.
+1
But even before this point, the OP should at the very least send the same untagged (yes untagged) profile target to the output device, say once a week for a month and plot the dE. If it’s off by a mile, which is quite likely, no reason to even consider a profile.
Andrew Rodney http://www.digitaldog.net/ <http://www.digitaldog.net/>
On Jul 15, 2021, at 10:11 AM, Henry Davis via colorsync-users <colorsync-users@lists.apple.com> wrote:
“. . . send . . . target . . . once a week for a month and plot the dE."
That sounds like time and money.
Trying to profile a moving target is even worse; pointless. Trying to profile a stable target isn’t too difficult. Andrew Rodney http://www.digitaldog.net/ <http://www.digitaldog.net/>
I understand and agree about a moving target but there are other moving parts such as the person driving the file. The same person drives the targets for a month and it’s stable. The job is sent and a different person drives that file differently - kaput. There has to be a precise and consistent process when doing remote profiling. This must be understood and communicated between everyone involved. Just send in targets for a month? That might be close to pointless as well. Henry Davis
On Jul 15, 2021, at 12:14 PM, Andrew Rodney via colorsync-users <colorsync-users@lists.apple.com> wrote:
On Jul 15, 2021, at 10:11 AM, Henry Davis via colorsync-users <colorsync-users@lists.apple.com> wrote:
“. . . send . . . target . . . once a week for a month and plot the dE."
That sounds like time and money.
Trying to profile a moving target is even worse; pointless. Trying to profile a stable target isn’t too difficult.
Andrew Rodney http://www.digitaldog.net/ <http://www.digitaldog.net/> _______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/davishr%40bellsouth....
This email sent to davishr@bellsouth.net
On Jul 15, 2021, at 10:33 AM, Henry Davis via colorsync-users <colorsync-users@lists.apple.com> wrote:
I understand and agree about a moving target but there are other moving parts such as the person driving the file. The same person drives the targets for a month and it’s stable. The job is sent and a different person drives that file differently - kaput.
Even a broken clock is right, twice a day. A process, a print process is either consistent based on measured data or it isn’t. That’s all we remote profilers have to worry about before even thinking of profiling remotely. Andrew Rodney http://www.digitaldog.net/ <http://www.digitaldog.net/>
Andrew’s weekly audit is a scientific approach to validating print condition consistency. Fail the audit? Forget remote profiling. Sent from my iPhone
On Jul 15, 2021, at 12:39 PM, Andrew Rodney via colorsync-users <colorsync-users@lists.apple.com> wrote:
On Jul 15, 2021, at 10:33 AM, Henry Davis via colorsync-users <colorsync-users@lists.apple.com> wrote:
I understand and agree about a moving target but there are other moving parts such as the person driving the file. The same person drives the targets for a month and it’s stable. The job is sent and a different person drives that file differently - kaput.
Even a broken clock is right, twice a day.
A process, a print process is either consistent based on measured data or it isn’t. That’s all we remote profilers have to worry about before even thinking of profiling remotely.
Andrew Rodney http://www.digitaldog.net/ <http://www.digitaldog.net/> _______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/jonmeyer%40grafixgea...
This email sent to jonmeyer@grafixgear.com
It sounded to me like sending profiles every week for a month might be taken as advice for others to follow when doing a remote profile. Henry Davis
On Jul 15, 2021, at 1:31 PM, Jon Meyer via colorsync-users <colorsync-users@lists.apple.com> wrote:
Andrew’s weekly audit is a scientific approach to validating print condition consistency.
Fail the audit? Forget remote profiling.
Sent from my iPhone
On Jul 15, 2021, at 12:39 PM, Andrew Rodney via colorsync-users <colorsync-users@lists.apple.com> wrote:
On Jul 15, 2021, at 10:33 AM, Henry Davis via colorsync-users <colorsync-users@lists.apple.com> wrote:
I understand and agree about a moving target but there are other moving parts such as the person driving the file. The same person drives the targets for a month and it’s stable. The job is sent and a different person drives that file differently - kaput.
Even a broken clock is right, twice a day.
A process, a print process is either consistent based on measured data or it isn’t. That’s all we remote profilers have to worry about before even thinking of profiling remotely.
Andrew Rodney http://www.digitaldog.net/ <http://www.digitaldog.net/> _______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/jonmeyer%40grafixgea...
This email sent to jonmeyer@grafixgear.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/davishr%40bellsouth....
This email sent to davishr@bellsouth.net
Peter,
One of our staff is using an external non-colormanaged print provider. And I'm wanting to help him prepare work for it. Test prints to this printer are in AdobeRGB1998 and prints come out over saturated.
First question would be if they look as if they have a profile applied to them at all. If the machine is a grand format RIP-driven printer, and you send it a file in any RGB colorspace, it’s pretty obvious to see if there’s an ICC profile applied or not. Neutral grey, for instance, will print as black only with no profile applied in this condition, whereas with an improper profile applied it will print in CMY or CMYK and typically have some kind of obvious color cast.
So I am attempting to profile the print process ‘remotely’ using i1 profiler. And to do the color conversion ourselves. I am familiar with profiling inkjet and laser printers where I work using i1Profiler, FieryXF and ColorBurstRIP. I thought it would be a fairly straight forward process, but I’m getting some unexpected results.
I am not in a position to control this external printer in any way. I have already had TC918 RGB patches printed on this printer (patches assigned AdobeRGB1998) and I created a printer RGB ICC profile of this process. When I assign this printer profile to the original AdobeRGB1998 test image we printed I get a very good approximation of the over saturated test print we got. So far so good.
So I Imagined I just needed to use Convert-to-Profile on our AdobeRGB1998 test image, to convert it into the printer color space that I built. Then to ensure it gets handled by the external printer in exactly the same way as before, I just assign it AdobeRGB1998 again.
That’s one of those things that sounds like it might work, and kudos to you if you managed to get a passable result… but you didn’t. There are so many variables involved though, that chasing them down now isn’t really an effective use of time. Why don’t you or your staff member simply call them and ask some questions?
When I do that, the test image now appears less saturated than it was before. Great, that’s just what I would expect. With the boost of saturation of this print process it should return back to normal when printed.
Note that the responder that said that might be because the printer was assigning sRGB to your Adobe 1998 file has that backwards. Assigning a smaller colorspace to an image created in a larger colorspace results in a desaturated image. Assigning a larger colorspace to an image created in a smaller colorspace results in over-saturation. Adobe 1998 is, of course, a larger colorspace than sRGB. Even sending Adobe 1998 though, it could be possible for the RIP to be assigning a larger colorspace. If the printer is doing something like running a Roland with Versaworks RIP and using the Max Impact preset. That preset, btw, does not honor embedded profiles in the incoming files. In fact, for your plan here to work, any RIP would have to be configured to honor embedded profiles. Otherwise what you’re doing will not work.
But what I did not expect was that the blackest pixels in the converted test image that started out as RGB 4,4,9 are now RGB 30,29,28 after conversion. That sounds crazy to me! I have not printed this converted test image yet. I don’t want to waste my money printing this converted file if I have got this wrong. But everything else looks like what I would expect.
This would indicate to me that the machine is applying some CMYK printer profile — which would of course imply that the printer is using some sort of color management -- with a not-very-robust black point. You might think that would be at odds with the rest of the image being over-saturated, but it’s really not. There are infinite ways to create a profile. Out of curiosity, what type of media is being used here? Mike Adams Correct Color
Hi List members. Thank you for all your input and help with this. Sorry to those who have asked me questions that I have not responded to. I have, however, carefully read every email I was sent and taken on board what you had to say. Happy to say it had a good outcome. After being reassured that what I was doing was basically right, I bit the bullet and sent our second test image to print in spite of the unusually high black point. For the second test image I converted the original (Adobe1998) image using the printer ICC profile I built. And for reasons I outlined before, I assigned it AdobeRGB1998 and converted it into a pdf and sent it to print. Happily, the second test did come out a very close match. Our saturation issues were solved. And the blacks came out quite well too. Well enough that we have prepared the final images and sent them to print. Thanks again everyone for your support. Peter Miles
participants (7)
-
Andrew Rodney
-
Ben Goren
-
G Mike Adams
-
Henry Davis
-
Jon Meyer
-
Miles, Peter
-
Scott Martin