Zum Hauptinhalt gehen

Rendering Intent Issues

Kommentare

4 Kommentare

  • BeO
    Top Commenter

    The rendering intent must be respected by the preview / viewer component, because color space conversions  are applied. At least if there are colors of the image which are out of gamut of the monitor color space (eventually intersected with the color space of the proof profile, when proofing).

    Whether or not you can see differences between the rendering intents depends on the image. If you are sure I suggest to report a bug (by submitting a request on top of this web page).

    btw, black point compensation cannot be set when proofing, rather only in the print dialog, I and others have already complained about it and/or requested a feature.

    0
  • BeO
    Top Commenter

    If you want black point compensation when proofing with printer icc profiles please request a feature too, as they didn't implement this though it is requested since years.

    0
  • Luiz Eustaquio de Lima

    At first, I was thinking with was an image issue but I did the following test:

    I've imported one of my RAW files from my Canon 5D III;

    I've set the proof profile as ProPhoto, TIFF 16-Bit using the recipe;

    As output for the Proofing tool (glasses icon), I've made a recipe using one of my printer's ICC.

    With all of this done, from my MacBook Air 2020 M1 with a P3 monitor calibrated using the i1 Studio, I've turned on the proofing tool and then I could see the difference between the gamut colors from what my monitor can show and what I could see from my printer. Until that, no issues.

    Well, keeping this workflow, when I change the rendering intent on preferences and switching on the proofing tool to proof my printer profile, there is no change on the image, but when I open the printer dialogue, switching rendering intent and black point compensation, I can see the difference as expected.

    I've tested this workflow using Affinity Photo with the soft proofing layer and I've gotten the same results, where I cold see the differences change rendering intent mode too.

    The point is: why need I to open the print dialogue to see the difference using rendering intent? The proofing is not only to check profiles print, its for every kind export mode, so it doesn't make sense proof from a big gamut to a small one without a possibility to check the interpolations mode. I've realized CO only shows Perceptual.

    I've download hight gamut test images to see if it was a problem with my RAWs files, but the results was the same.

    I think the rendering intent algorithm is implemented very well on CO, as we can see on dialogue print. What is missing is that options on recipes menu, together with black point compensation.

    I've requested those features on recipe. Lets see.

    Thanks.

     

    0
  • Chuck Loftis

    I have noted an issue with CO Render Intents when I came across a malformed ICC print profile for RedRiver Ultra Pro Satin paper for the ET-8550 printer. This is built to ICC ver 4 specs and has specific tables for intents -0, -1 and -2 (AToB0, AToB1, AToB1 device to PCS conversion tables). With the Apple Color Sync Utility you will see a huge spike from the green-blue region in the AToB0 table, extending past a reasonable gamut to the blue region. When printing with this profile, you might expect greens to map to blues, which is quite dramatic. This mathematical issue only exists in the AToB0 table for intent-0 (Perceptual). MATLAB Image Processing toolbox has verified this and the intent-1 and -2 tables are "clean".

    I've noted that the CO Preferences /Color / Render Intent has only a small effect on the display in the Catalog if the proof profile is set to this ICC profile. If the intent were set to Relative or Absolute Colorimetric you would not expect to see the issue, but you do. This is also true in printing with this profile. Regardless of intent we see the "spike" in the blue-green region for all intents with some variance.

    I suspect that CO is not using the specific intent tables (AToB1, AToB2) supplied in the ICC profile, but are performing some transformation on the perceptual table. (This may not be against ICC "rules", but if the tables exist, it would be better if the Application used them.) 

    This RedRiver profile only affects MacOS and a particular lower end Epson printer (ET-85xx). There are other RR profiles usable that don't show this errant feature. The profile itself is an anomaly, but tells me a lot about what these applications are doing in transformation to various intents.

    I just reported, that strangely, the Viewer does not show the profile artifact in soft proofing, but the Catalog and Exported and Printed files do.

    1

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.