Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: Thenolands on January 14, 2018, 01:04:19 pm
-
I have an image I am printing that I added a border to in photoshop and saved as a TIFF. I am printing on Red River Aurora Art Natural paper and using their color profile. The actual image looks great but the border has a pink tint. Printing via lightroom on a mac. In print module I have RR's profile selected under color Management and relative intent. I have run into this problem once before using one of their gloss profiles but I use one of their luster paper profiles all the time without incident. Any ideas what could be causing this and any fixes? Again, the pink tint is only on the border and not on the whole image.
-
Sounds like the paper profile or an issue with it. What about Perceptual? Kind of doubt that is the issue but worth a try. A very, very old bug where a profile produced a 'scum dot' on paper white showed up in the past.
Do you see it if you test with say this document:
http://www.digitaldog.net/files/2014PrinterTestFileFlat.tif.zip
-
I have an image I am printing that I added a border to in photoshop and saved as a TIFF. I am printing on Red River Aurora Art Natural paper and using their color profile. The actual image looks great but the border has a pink tint. Printing via lightroom on a mac. In print module I have RR's profile selected under color Management and relative intent. I have run into this problem once before using one of their gloss profiles but I use one of their luster paper profiles all the time without incident. Any ideas what could be causing this and any fixes? Again, the pink tint is only on the border and not on the whole image.
When you say you "added a border", what do you mean? How did you do that? If you created a new background document in Photoshop and then layered the photo into that background, it could be that there is an error in your Photoshop settings that produced a slightly off-white background, which would show only on the borders exposed from the background, not the photo. To test your colour management set-up in Lr, I would suggest importing the photo into Lr WITHOUT that border you created and printing it. If any white areas within the photo print well, it would indicate the profile is OK and something was amiss in Photoshop. And, BTW, you don't need Photoshop to create margins for printing from Lr. You can do all that from within Lr's print module whether working from a RAW, TIFF, PSD etc. - much easier and with one piece less software, less room for error.
-
Thanks for the reply. For simplicity I said I created the border but really I did a digital reproduction of a pencil drawing and the artist took the file and added the border and feathered the edge to blend it into the border. The image printed without the border is fine so I agree with you that the profile is either not the issue or the profile is interpreting the border data incorrectly somehow?
Is there a better way to do it to eliminate the possibility of this pink cast if using photoshop? What presets or options might be causing this? I can tell you the border does not have a color when I review the photoshop file. But I am not a photoshop expert by any stretch.
I would love to use lightroom but the feathering he wants is an issue and the only thing I have ever seen in Lightroom is the border and stroke options which 1) have limited range of thickness and 2) shrink and crop the image as the border expands. Any way around these 2 issues?
-
You'd have to work directly with the artist to determine exactly what he did, how he did it, what all the relevant colour management settings in Photoshop or any other application he used, what colour management policies accompanied the file back to you, etc. It gets complicated and I don't think can be answered without in-depth first-hand review. As for page sizes and margins in Lightroom - this can be managed without shrinking the photos by creating and using custom settings. Perhaps see the chapter on printing from Lr in Martin Evening's book, or the Lr tutorials on this website.
-
As a quick and dirty work-around, try selecting the border and desaturating it completely.
Rand
-
Update:
I created my own photoshop file so I would know exactly what was done to it. I simply added the reproduction file and creating a larger "canvas" size than the print (I believe by default the "canvas" is transparent). I then saved as TIFF and imported into lightroom. I printed a relative colorimetric print next to a perceptual colorimetric and the results were MUCH different. The relative had the pink cast still and now that I see it next to the perceptual rendering, it does indeed have the pink cast over the entire print (not just the border). The perceptual rendering has the VERY SLIGHTEST color on the border though it is more of a gray than a pink cast. It is so faint I probably would not have noticed if I wasn't specifically looking for it.
So my first thought is the Red River profile for this paper (and a few others) simply are not very good. I could live with this and get a custom profile done or try a different generic profile however 1 question is still bothering me. Why would any profile, no matter how good or how bad, print anything on a transparent border? I could see the print having a cast due to a poor profile but why is anything being printed where there should be zero color data?
Regarding using lightroom. I would LOVE to use lightroom to add my border but I left out a few details about what I am printing with. I am printing on roll paper using an IPF8400. Due to using roll paper, I am needing the printer to add crop marks for cutting the paper after printing. So what I am needing is the image with a border around it with crop marks along the edge of the border for cutting. Now knowing those details, is it still possible to do this using lightroom? I tried using "single image/contact sheet" but the crop marks are still aligned with the image and not the border and I wouldn't be able to print multiple prints of varying sizes on a single print run using the contact sheet layout.
-
Are you actually printing on the edges, or is the pink cast just the "natural" white of the border without ink?
-
ink is definitely being applied. There is an obvious line where the border begins and ends. And, no, I am not printing edge to edge.
-
I'm obviously missing something here, which of course wouldn't be a totally new experience. I believe you have mentioned that the border is transparent. Therefore, when you look at the border in that file it is not white, but a white and grey checkerboard pattern, correct? If that's the case, why not fill the border with pure white and see what happens when you print it. If indeed the border does appear to be white, then obviously it is not transparent. Also, if the border in the file "appears" to be white, use the Eye Dropper tool and take a measurement of that border. Open the "Info" dialog and check the RGB numbers. If they are anything but 255, 255, 255, you do not have a pure white border. You can also use the Digital Color Meter, which you will find in Applications > Utilities. That will also determine if the border is indeed pure white. However, I believe you have determined that the whole image has a very slight color cast, which of course can be corrected in PS or LR. If the border has any density at all it will definitely pick up that cast. I would suggest that you do a selection of the border and fill that selection with pure white. If that's not an alternative you want to approach, perhaps get the digital file of the original and place it on a pure white background to produce the border you need.
In reference to the crop marks. Since most of my work is done in PS, I'm not totally familiar with how LR would handle that. I do not like the crop marks in PS, so I simply add a one pixel black stroke inside the image and crop to that. Works great!
Gary
-
Transparency will flatten and whatever color you've set for the background color will apply! Type the D key to reset the foreground/background color to default and try again. The enlarged canvas should of course read 255/255/255 after flattening and print paper white!
Or as suggested, just fill the border with white (Fill command will do so).
-
I'd like to thank everyone that has chipped in thus far. Truly amazing community here!
I created another file with a white (255/255/255) background layer. I used dropper tool and verified it was 255/255/255. Saved a TIFF (keeping the layers - would this matter?), imported into lightroom and printed using relative colorimetric intent and RR Aurora Art Natural profile and it still applied ink to the border.
Digitaldog, I know you are a wealth of knowledge regarding icc profiles, is it possible that a profile especially for a "natural white" paper would apply ink to a 255/255/255 area of a print? The thought being that on a "warm" paper like this there is not true white? That doesn't make a lot of sense but I am running out of ideas. This has me truly stumped! It obviously has something to do with the profile and the rendering intent.
To remove another variable and hopefully isolate the issue, I used lightroom's "photo border" option in the print module with an image of the reproduction without a border and it did not apply any ink to the border. Yay! That is great and, again, I would use this option instead but it crops with width of the image as the border thickness increases which the artist is not going to like (plus it only reads the border width in "its" and I would like to know exactly how thick it is.
So, the icc profile can read true white and not apply ink it seems but somehow the 255/255/255 border that i am applying in lightroom is not being interpreted as 255/255/255?
-
Be useful if you can upload the profile that's causing this issue.
-
Be useful if you can upload the profile that's causing this issue.
Profile attached
-
Good news, it's not a Version 4 profile. Somewhat bad news, made from a Spyder (not ideal) but not anything that would create a scum dot. The soft proof is pretty awful. Did you try using this profile on my Printer Test File (URL below) and did you see magenta within the image area where there is paper white?
-
Good news, it's not a Version 4 profile. Somewhat bad news, made from a Spyder (not ideal) but not anything that would create a scum dot. The soft proof is pretty awful. Did you try using this profile on my Printer Test File (URL below) and did you see magenta within the image area where there is paper white?
I’ll try the test print. I don’t see the url, though.
-
I’ll try the test print. I don’t see the url, though.
http://www.digitaldog.net/files/2014PrinterTestFileFlat.tif.zip
-
The problem may be the profile. If you convert a pure white image in 16 bit space using the RR profile and Rel Col, then convert back to Lab you get L*=100, a*=2.5, b*=1.9. This is abnormal behavior as well as an illegal Lab value (at L*=100, a* and b* MUST be 0).
-
The problem may be the profile. If you convert a pure white image in 16 bit space using the RR profile and Rel Col, then convert back to Lab you get L*=100, a*=2.5, b*=1.9. This is abnormal behavior as well as an illegal Lab value (at L*=100, a* and b* MUST be 0).
Interesting! Would never have found this on my own that is for sure! I will contact RR and at least let them know.
-
Interesting! Would never have found this on my own that is for sure! I will contact RR and at least let them know.
Looking at the profile with ProfileInspector, it's marked as a V2.0 profile but the math (BtoA1) appears to be that of V4 profiles. For instance L*=100 is encoded in the LAB PCS as 0xffff whereas it's 0xff00 for V2 profiles. This isn't enough for most people to notice. Usually. But it could be causing a color shift depending on whether color management engine detects this and adjusts to accommodate.
http://www.color.org/v2profiles_v4.pdf
-
The only time I've seen an unprinted white area looked pink was when the paper was saturated with OBAs, which if used to excess will cause this effect.
-
No OBAs used in production of this paper (per RR website) and the line is distinct and immediate after printing.
-
No OBAs used in production of this paper (per RR website) and the line is distinct and immediate after printing.
Have you tested that with your own UV light? I've caught other companies claiming "no OBAs" only to find when I checked myself they did have OBAs in them.
-
No OBAs used in production of this paper (per RR website) and the line is distinct and immediate after printing.
I see there has been a change to a somewhat heavier quality. The "Art" in the name is going along with that? Is it this year's January the website refers to?
http://www.redrivercatalog.com/browse/auroranatural.html
In the past the Aurora Natural and White had a gsm weight lower than what RR specs mentioned. I measured 230 gsm then. It looks like they have a new quality and I will try to get some sheets of it to add the measurements to SpectrumViz. The old Aurora natural had an odd drop in the spectral plot at the left side, UV absorption, but not a bulge in the blue that indicates OBA. More likely TiO2 or a similar whitening agent that absorbs UV but emits the converted energy beyond visible red. The Aurora White version had quite a similar spectral plot to Moab Endura Bright White then. All four were more or less dual side coated so I wondered whether there was more realtion between the qualities.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Looking at the profile with ProfileInspector, it's marked as a V2.0 profile but the math (BtoA1) appears to be that of V4 profiles. For instance L*=100 is encoded in the LAB PCS as 0xffff whereas it's 0xff00 for V2 profiles. This isn't enough for most people to notice. Usually. But it could be causing a color shift depending on whether color management engine detects this and adjusts to accommodate.
http://www.color.org/v2profiles_v4.pdf
Should be able to prove/disprove definitively if the RR profile is the culprit by simply printing a 255-255-255 block without a profile (in ACPU or something) or using an alternate random profile that does not have this problem.
-
This isn't an OBA issue, it's either the profile or something else like a bug in the product/driver etc.
To the OP, I suggest you try another profile, from another paper manufacture even if it's wrong! Using the same test images. Do nothing different but pick a different ICC profile from another source even if it is the wrong paper. Get a magenta cast on white? If not, it's the profile. If so, we need to drill down elsewhere in the print path.
-
Should be able to prove/disprove definitively if the RR profile is the culprit by simply printing a 255-255-255 block without a profile (in ACPU or something) or using an alternate random profile that does not have this problem.
This isn't an OBA issue, it's either the profile or something else like a bug in the product/driver etc.
To the OP, I suggest you try another profile, from another paper manufacture even if it's wrong! Using the same test images. Do nothing different but pick a different ICC profile from another source even if it is the wrong paper. Get a magenta cast on white? If not, it's the profile. If so, we need to drill down elsewhere in the print path.
Those are good ideas. The RR profile is an interesting beast since it's got V4 math in a V2.0 marked profile. The result depends on the CMM as well as whether the controlling software recognizes that it's malformed (bad PCS math) and how and if it attempts to correct things.
So running the test with an arbitrary, but properly formed printer profile, should isolate the problem.
I agree that it's not an OBA problem though it's possible OBAs could make scum dots more visible. However, there should be nothing printed with RGB 255,255,255 for either Perceptual or Relative Intents. Abs., of course, will.
-
Yes, I agree it doesn’t sound like OBAs. I have essentially already done the proposed 255/255/255 test print with the border around the photo. I will try using a different profile although I am out of the Aurora Natural paper samples I had ( need to see if RR will send me some paper to replace the waste that occurred due to their improper profile). However, for testing purposes is really shouldn’t matter water paper it is printed on as it should be applying ZERO ink to the border. I feel with the differences in relative and perceptual that I have already experienced it likely has to be a profile issue.
I have received a couple of responses from RR asking about my problem but they have er to provide any fixes. I am surprised I am the only one that has ever had this issue with their profiles although it is possible that if One wasn’t printing a white border one would not notice the magenta shift although when compared to perceptual intent the difference is pretty obvious.
-
Yes, I agree it doesn’t sound like OBAs. I have essentially already done the proposed 255/255/255 test print with the border around the photo. I will try using a different profile although I am out of the Aurora Natural paper samples I had ( need to see if RR will send me some paper to replace the waste that occurred due to their improper profile). However, for testing purposes is really shouldn’t matter water paper it is printed on as it should be applying ZERO ink to the border. I feel with the differences in relative and perceptual that I have already experienced it likely has to be a profile issue.
I have received a couple of responses from RR asking about my problem but they have er to provide any fixes. I am surprised I am the only one that has ever had this issue with their profiles although it is possible that if One wasn’t printing a white border one would not notice the magenta shift although when compared to perceptual intent the difference is pretty obvious.
Yep. The paper shouldn't matter. Just make sure when you test with a different profile that you keep the paper settings the same. Don't change any settings in the workflow other than the profile.
-
Will do.
Could anyone recommend a paper with available profile that might be most similar to Aurora Art Natural?
-
Will do.
Could anyone recommend a paper with available profile that might be most similar to Aurora Art Natural?
Another thought. What you are seeing is exactly what is expected when printing with Absolute Colorimetric Intent for most any profile. Verify that you haven't been selecting that inadvertently.
-
Thanks. I definitely have not selected that in Lightroom (doesn’t have that option). Now photoshop does and I am not sure what my defaults are there. Where can I go to check that? And would it matter if the final selection in Lightroom was relative? I guess it might.
-
Thanks. I definitely have not selected that in Lightroom (doesn’t have that option). Now photoshop does and I am not sure what my defaults are there. Where can I go to check that? And would it matter if the final selection in Lightroom was relative? I guess it might.
Abs. isn't possible in Lightroom, only Rel. and Perc. Abs. is selectable in Photoshop's print dialog box. It was just a thought since that's the only time I've actually seen this effect on a print. It's normal with Abs. Col. because it tries to print L*=100 and can't since no paper reflects perfect white.
-
It is a good thought that would also explain the Lightroom border tool not printing a pink tint since photoshop was not involved.
-
Well darn. I looked up my photoshop color settings and attached. Absolute is not selected.
-
Well, back to the drawing board.
I used your profile and compared it to a custom printing RGB 255,255,255 and 254, 253 neutrals in Rel Col. No evidence of any printing. Unprinted v printed Lab values read within .05 dE which is far below anything visible. L* started dropping about .3 for each step down on the neutrals for both profiles with only a slight difference in gain. This is what I would expect. So I have no idea what the cause is.
-
Thanks for the reply. For simplicity I said I created the border but really I did a digital reproduction of a pencil drawing and the artist took the file and added the border and feathered the edge to blend it into the border. The image printed without the border is fine so I agree with you that the profile is either not the issue or the profile is interpreting the border data incorrectly somehow?
Is there a better way to do it to eliminate the possibility of this pink cast if using photoshop? What presets or options might be causing this? I can tell you the border does not have a color when I review the photoshop file. But I am not a photoshop expert by any stretch.
I would love to use lightroom but the feathering he wants is an issue and the only thing I have ever seen in Lightroom is the border and stroke options which 1) have limited range of thickness and 2) shrink and crop the image as the border expands. Any way around these 2 issues?
Since we are all back to "Square One", I thought I should go there as well and see if there remains anything useful I can contribute at this late stage. We've seen that your Photoshop settings and your Lr settings are normal and that the photo prints correctly, but the borders do not. The borders are the only element that was beyond your control, because you say they were made by the artist and blended into the photo. The notion that the profile would treat the photo correctly but not the borders doesn't make sense to me, unless there is something embedded in the border data that is causing the CMM to misinterpret the colour. The one thing we don't know yet is what application the artist used to create those borders, what settings were used with that application, and how that information got handled in Photoshop in the file that came back to you. I don't know what, but it seems this is the only stone that we haven't turned up to now.
-
Sorry for the confusion Mark, I did clarify in a later post that the photo itself does have a pink cast on relative when compared to perceptual and that ink is applied to the border area on both relative and perceptual but much more ink applied with relative. I have also created my own photoshop file to take the artist out of the equation and it still printed the border.
I know basically nothing regarding Lab values and what they mean but I thought digitaldog had said the profile had an invalid value that could be causing this issue. Do we no longer think that is the case? I am going to follow up with RR today if there is still the thought that the profile is to blame.
-
Sorry for the confusion Mark, I did clarify in a later post that the photo itself does have a pink cast on relative when compared to perceptual and that ink is applied to the border area on both relative and perceptual but much more ink applied with relative. I have also created my own photoshop file to take the artist out of the equation and it still printed the border.
I know basically nothing regarding Lab values and what they mean but I thought digitaldog had said the profile had an invalid value that could be causing this issue. Do we no longer think that is the case? I am going to follow up with RR today if there is still the thought that the profile is to blame.
Ah - sorry I missed that; yes you did. This reverts the story back to the profile, because the profile specification includes the four Rendering Intents for handling out of gamut colours. I'm now wondering whether there is a problem with Relative Intent rendering of the White Point. Have you tried printing it in Photoshop with Absolute, which does not remap the White Point from the source to the destination? If the cast disappears in the Absolute print, it would seem to indicate a problem with the interpretation being applied with Relative.
-
I will try that this evening.
-
Well darn. I looked up my photoshop color settings and attached. Absolute is not selected.
And it shouldn't nor need to be. That's only going to be used IF you conduct a conversion to CMYK or RGB in "Mode Change" instead of the proper and more feature rich method: Convert to Profile. Then it bypasses the color settings to what you select there. Plus you can pick any RI and soft proof the results. And as stated, there's no Absolute Colorimetric option in Lightroom so this isn't really a necessary step.
-
Ah - sorry I missed that; yes you did. This reverts the story back to the profile, because the profile specification includes the four Rendering Intents for handling out of gamut colours. I'm now wondering whether there is a problem with Relative Intent rendering of the White Point. Have you tried printing it in Photoshop with Absolute, which does not remap the White Point from the source to the destination? If the cast disappears in the Absolute print, it would seem to indicate a problem with the interpretation being applied with Relative.
Mark, I did a test print directly from photoshop using absolute colorimetric and the cast did in fact disappear! So does this settle it once and for all? If I were to get RR to either create a better/accurate profile or get a custom profile created then I should be good, no?
-
Mark, I did a test print directly from photoshop using absolute colorimetric and the cast did in fact disappear! So does this settle it once and for all? If I were to get RR to either create a better/accurate profile or get a custom profile created then I should be good, no?
This is pretty much what I was expecting to hear back. It does appear to indicate that something may be messed-up with Relative Colorimetric White point mapping in the CMM, which may be due to an error in the profile. While this evidence is not conclusive, it is indicative enough to advise RR that they should revisit this profile to see whether they can (a) replicate the problem, and if so (b) re-issue a corrected profile.
-
It does appear to indicate that something may be messed-up with Relative Colorimetric White point mapping in the CMM, which may be due to an error in the profile.
Yeah, the profile itself (but not the CMM).
-
Sorry, CMM?
-
Sorry, CMM?
Color Matching Module (or Color Matching Method depending on who you ask). It's the part of the software that converts the data, the engine so to speak. Nothing you need to really worry about.
-
Yeah, the profile itself (but not the CMM).
Specifically, (Real World Color Management 2nd Edition, page 86) "The Color Management Module, or CMM, is the software "engine" that does the job of converting the RGB or CMYK values using the color data in the profiles.....The CMM provides the method that the color management system uses to convert values from source color spaces to the PCS and from the PCS to any destination spaces." (PCS is the Profile Connection Space). And yes, Andrew, nothing one needs to worry about. I was just trying to be precise about what happens under the hood and the role/importance of the information the profile provides to these calculations of the colour values that get printed. To be clear, I agree the user needs to be concerned about the profile, not the CMM.
-
Specifically, (Real World Color Management 2nd Edition, page 86) "The Color Management Module, or CMM, is the software "engine" that does the job of converting the RGB or CMYK values using the color data in the profiles.....
Not just RGB to CMYK conversions. ;)
-
Not just RGB to CMYK conversions. ;)
Sure, but that's not what this quote from the book meant.
-
Sure, but that's not what this quote from the book meant.
Isn't that what it said? I can look it up of course, I've got several copies. What does it mean?
Specifically, (Real World Color Management 2nd Edition, page 86) "The Color Management Module, or CMM, is the software "engine" that does the job of converting the RGB or CMYK values using the color data in the profiles...
-
Perhaps best you look it up and see what you make of it. But we're wandering OT. The main point is reply #42 emphasizing the need to look at the profile; the rest of it was just to explain the role of the profile relative to the conversions that take place in the CMM - as we agreed not something to be concerned about - with a good profile the CMM will just do its thing.
-
Perhaps best you look it up and see what you make of it. But we're wandering OT. The main point is reply #42 emphasizing the need to look at the profile; the rest of it was just to explain the role of the profile relative to the conversions that take place in the CMM - as we agreed not something to be concerned about - with a good profile the CMM will just do its thing.
As I said, it's not something the OP needs to be concerned with. But since he asked about what a CMM is, and since the text applied mentioned only RGB to CMYK, I think he should now know that any conversion uses the CMM. Convert CMYK back to RGB, or Lab etc. And yes, it was OT but I'd hate the OP to believe a CMM is only used with one kind of conversion.
-
As I said, it's not something the OP needs to be concerned with. But since he asked about what a CMM is, and since the text applied mentioned only RGB to CMYK, I think he should now know that any conversion uses the CMM. Convert CMYK back to RGB, or Lab etc. And yes, it was OT but I'd hate the OP to believe a CMM is only used with one kind of conversion.
Completely agree, and I did not interpret the sentence I quoted as meaning there is only one kind of conversion. No doubt in my mind the authors did not intend that either. Perhaps I should have quoted more of their paragraph to better clarify the context, but I was trying to cut to the bone - however not into it :-). Cheers.
-
Update on this topic: Red River sent me a new profile and I would say it is better (as in less pink) but there is still ink being sprayed on areas of 255/255/255. Now, they said they used a printer close to my ipf8400 (not an ipf8400 itself) but really for the problem I am having the printer shouldn’t matter, I imagine.
I suppose the answer is to buy a DigitalDog custom profile 🙂