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 ________________________