Opaque object placed on a page causes PDF colour issues

[FromTheDeep]

I have tested this on a range of colour profiles and in RGB/8 and RBG/16. Colours export fine to PDF without any opaque objects on the page, but as soon as I add a shape with even the slightest bit of opacity to the page, all colours get massively dulled in the PDF that is exported. 

Tried changing to a range of different PDF export settings, and made sure that colour space is set to use the Document Profile (Embed profiles is ticked too). 

"Flatten" is the only export preset that doesn't cause this issue, but I need to retain editability of the PDF. 

Sample 1.pdf shows a turquoise rectangle with no opacity (all colours are correct), Sample 2.pdfshows the results when I lower the opacity of the turquoise rectangle (dull). Please download PDFs and open in Adobe Acrobat to see the differences (colour differences don't show in browser). 

Using an iMac (Retina 5K, 27-inch, 2017) running Catalina 10.15.7

After switching from Adobe I'm loving AP and AD so far, please don't make me go back to Adobe! PLEASE I BEG YOU!!!  

Edited June 17, 2021 by Cvandiepen
Additional info about provided files

[thomaso]

Hi Cvandiepen,
Welcome to the Affinity Forums!

I can't see such massively dulled color difference when comparing your PDFs. Also Acrobat shows a minimal difference in the values for the blue background. But in PDF 2 there is an additional profile involved for transparency calculation (sRGB, "mischfarbraum"). – What profile do you use in Acrobat to view both PDFs? What if you export as PDF/X to force an output intent set for the PDF viewing app?

(note: the screenshots have their profiles stripped, so their appearance isn't equal to the view in Acrobat)

[walt.farrell]

1 hour ago, Cvandiepen said:

Colours export fine to PDF without any opaque objects on the page, but as soon as I add a shape with even the slightest bit of opacity to the page, all colours get massively dulled in the PDF that is exported.

I'm finding myself a bit confused. Did you perhaps mean to say "transparent" and "transparency" rather than "opaque" and "opacity"?

[Alfred]

10 minutes ago, walt.farrell said:

Did you perhaps mean to say "transparent" and "transparency" rather than "opaque" and "opacity"?

It would seem so.

1 hour ago, Cvandiepen said:

Sample 1.pdf shows a turquoise rectangle with no opacity (all colours are correct)

 

[FromTheDeep]

Thanks for your replies guys! 

I'm not sure of the exact terminology, but to be as clear as possible, what I'm referring to is the simple act of reducing the value of the Opacity slider in the layers panel. If I give a shape any value other than 100 (no opacity), it affects the colours of the entire page. It appears to reduce all colours to fit within the bounds of the very limited sRGB colour profile, even though I'm using the wider Adobe RGB profile in the Publisher doc, and exporting to PDF with a colour space of Adobe RGB and document colour profiles embedded. 

thomaso you seem to have found the bug - an sRGB profile added to the document when there is an opaque shape present. Is this a bug within the software do you think? 

You mention it being subtle, but with certain Adobe RGB colours the unwanted conversion to sRGB is really extreme. I really need to be able to trust that when I go to export a digital PDF with some opacity present, the colours will be accurate. 

I've tried exporting to all of those different PDF presets you mentioned and all show inaccurate colours. 

I was also able to recreate the problem again today after a fresh boot, using a fresh Publisher doc, and uninstall Adobe Acrobat and removing all custom preferences. 

Any ideas welcomed and thanks again.  

 

[thomaso]

7 hours ago, Cvandiepen said:

I'm not sure of the exact terminology

That makes it difficult to talk with unambiguous precision. In particular about color, color spaces, transparency blend spaces and their various profiles, respectively the difference between document / object profile versus device profile. Not to mention the monitor color space (hardware) and its assigned color profile (software).

Just saying "massively dull" doesn't help here, not only because it's not clear what is meant but also and especially if others don't see such on their screens. Then it is useful to talk about color values rather than visual impressions.

7 hours ago, Cvandiepen said:

with certain Adobe RGB colours the unwanted conversion to sRGB is really extreme. I really need to be able to trust that when I go to export a digital PDF with some opacity present, the colours will be accurate. 

Can you specify any of this "certain Adobe RGB colours" as numerical values, to concentrate on these in any test?

Any color conversion can influence the color values and their visual impression. Values & impression may differ and same values may appear different on different screens, where not only a monitor profile gets involved but possibly also one of the viewing app. To proof the consistency of a specific color value you need not only to know all influencing parts but also must ensure they are equal. – So, even a 100% consistent PDF (e.g. ~ pure Adobe RGB) can appear different at the viewers side just because of their involved hard- & software when displaying the PDF.

If you use transparency in a PDF then it requires a color space to convert the spaces of the involved items. In PDF this is the "Transparency Blend Space", which is used not only for reduced opacity but also for layer blend modes like "Multipy" etc.

7 hours ago, Cvandiepen said:

it affects the colours of the entire page.

I still can't reproduce your issue and can't neither see nor measure different colours "of the entire page".

The attached PDF has 2 pages, pg1 without any transparency, pg2 with a Transparency Blend Space, which seems to be in Affinity by default sRGB and apparently can not be custom set in Affinity by the user. Nevertheless, both pages show the same values for these blue + gray, accordingly I don't see any visual difference.

–> How does this PDF appear to you: What differences do you see on what page and area, what different values do you get / what differences does your Acrobat measure and what involved profiles reports your Acrobat preflight for this PDF?

v193 AdobeRGB_v1.7_AdobeRGB_embed&convert.pdf

Opened in 2 apps its screenshot doesn't show correct colors (because of its stripped profile) but also doesn't show an obvious, visually recognizable difference to me, neither between the 2 apps nor between its 2 pages. –> How about you for this image?

[walt.farrell]

13 hours ago, Cvandiepen said:

I'm not sure of the exact terminology, but to be as clear as possible, what I'm referring to is the simple act of reducing the value of the Opacity slider in the layers panel.

Thanks. That's a good description.

If the opacity slider is at 100, the object is opaque. If it's at 0, the object is transparent.

If it's somewhere in-between, I would say the object is partially transparent, or has some transparency.

[Alfred]

13 hours ago, Cvandiepen said:

If I give a shape any value other than 100 (no opacity), it affects the colours of the entire page.

The values are percentages, so 100 means ‘100% opacity’ (i.e. the object is fully opaque, or not at all transparent). 0 on the scale would mean ‘0% opacity’ (i.e. the object has no opacity, making it fully transparent).

[FromTheDeep]

Thanks Alfred and Walt for helping me out re: terminology. 

Thomaso you've described the bug perfectly, thanks. 

To summarise, when working with a Publisher doc that has an element on the page with any level of transparency, an sRGB colour profile seems to be automatically added to any elements interacting with the transparent element on export to PDF, causing all of their colours to be converted to the much more limited sRGB colour space. 

This happens regardless of what colour profile settings you set in the PDF export options. Importantly, it persists even if you specifically state you want the PDF to have the same colour space as the Publisher document.  

Assuming you like working with a much wider range of colours than sRGB (many of us I'm sure), and want to export PDFs for screen viewing and retain that wider gamut (pretty common!), this makes using Publisher with transparent objects a no-go. 

Thanks for the help in narrowing this down all, are we able to move forward and report this bug? 

Is there a typical timeline for these sorts of fixes? 

Edited June 19, 2021 by Cvandiepen

[thomaso]

13 hours ago, Cvandiepen said:

Thomaso you've described the bug perfectly, thanks.

I am not sure if it's a bug at all – or "simply" a missing option to define a profile as "Transparency Blend Space". I don't know if a PDF in general (by its technically requirements /specification) must have this profile with a specific, e.g. a wide gamut. Possibly sRGB is kind of common PDF standard meanwhile even for the "Transparency Blend Space" ?

Consider your PDF does contain your layout objects & colors with their initial settings. The sRGB profile is used only for output (–> display / print) to calculate the color mix required for transparency. Also note that it requires a wide gamut monitor hardware + software (profile and viewing software) to display a 100% color fidelity and make it visible to users. Additionally, with according tools this sRGB profile maybe changeable before output (e.g. by a RIP during pre-press process) without even touching your layout content.

I agree it can influence the result in a way which doesn't make use of the available profiles of the affected objects – but I am not sure if this would be a requirement which the PDF format would have to fulfill to be a "true" PDF.

Like every file format also PDF isn't fully compatible with every content, respectively without converting it and/or loosing its editability. If you want to maintain your Affinity layout fully editable it could be necessary to save it in a native Affinity file format (.afpub, .afdesign, .afphoto) – and use a separate file for web view as kind of preview.

Compare this PDF as Adobe reference for PDF v.1.7., "Specifying Blending Colour Space":
(click to enlarge)

 …

 

[FromTheDeep]

Thanks for your reply Thomaso. 

I can appreciate that for some users who only work in sRGB or CMYK, this is a non-issue, but for any designers who want wider rgb profiles in their documents and PDFs, this is verging on a deal-breaker. 

In comparison, Adobe inDesign exports PDFs with no such issue, and I’m seriously considering swapping back. 

With that being said, is there any way I can bring this to the developer’s attention? Regardless of whether this is a bug or a feature improvement, I’m confident it would be in their best interests.

[thomaso]

I still can't fully follow. In my understanding the Transparency Color Space influences the way how PDF content gets displayed, it does not alter the layout objects / PDF content, which is still present in its desired data.

Can you describe an existing use case where the Transparency Color Space in a PDF matters in a way that makes it 'verging on a deal-breaker'? Possibly with two PDFs which visualize the issue for comparison? With other words: are there any practical consequences that you have experienced or that could be caused by the transparency color space in the worst case but do not allow a different workflow / data transfer?

[FromTheDeep]

Hi thomaso, 

My use case is as follows:

I'd like to be able to send some PDFs to paying clients for viewing on their screens.

Some of the document's colours will be my brand colours, some of which will be outside the sRGB gamut. 

I also have some screenshots from a software program. I'm using a transparent yellow rectangle to highlight certain areas of the screenshots.

At present, I can't export to PDF without having the pages with transparent rectangles be converted to the sRGB colour space, while the other pages remain in AdobeRGB.  

This is causing huge differences in colour from one page to the next, making my document look very unprofessional. I have what I want to be the same full-page background colour on every page, but it is currently changing dramatically on seemingly random pages (each time transparency is used). This is just one example of the issue.  

As you can see this is not an unusual use case - anyone who creates PDFs for presentations or for screen viewing would likely run into this at some point. I would image many other designers would run into the same issue, a very unexpected result, and become very frustrated with the software. It is easy to recreate the issue, and if you need more help doing so just let me know. 

But please, if there is no opportunity to get Serif to hear this issue, please let me know so I can save my time. 

 

[thomaso]

12 hours ago, Cvandiepen said:

I'd like to be able to send some PDFs to paying clients for viewing on their screens.

This would require that every client's monitor, both hardware plus software (calibration / profile) is able to display the wide gamut, e.g. your preferred AdobeRGB. Otherwise they will get displayed colours according to their custom setup, which nowadays often is around sRGB. If this requirement is not met by the viewer's setup, even a PDF with wide gamut will look different.

12 hours ago, Cvandiepen said:

Some of the document's colours will be my brand colours, some of which will be outside the sRGB gamut. 

If a brand colour requires wide gamut for color fidelity it has no chance to appear correctly (= identically) across various media and will look different on screen versus printed media. – But: If such a color is displayed on screen without wide gamut (for instance because the PDF doesn't contain wide gamut exclusively) then its appearance will be closer to the appearance of a printed result, because the latter is not wide gamut, too. From this perspective sRGB can even cause a win-win situation for a consistent appearance of a wide gamut brand color viewed on various hardware (screens & papers) in its additive and subtractive occurrence.

For a consistent (brand) color appearance across all media this color must be part of the smallest possibly involved color space. Vice versa, if the color requires wide gamut then it will appear differently on various screens and in print, too – regardless of a purely wide gamut PDF. The device with the smallest color space is always a limiting bottleneck in the chain of creation –> transfer (e.g. PDF) –> display / print.

13 hours ago, Cvandiepen said:

But please, if there is no opportunity to get Serif to hear this issue, please let me know so I can save my time. 

The issue is likely known to Serif in connection with various reports about expected vs. resulting colour in PDF output. I guess at least every new topic, probably each single post, is read at least by one Serif moderator. As I understand it, it is not wasted time for you to deal with your concern until it no longer plagues you - either, for example, through an improved PDF export, an increased knowledge of managing colour, or a changed perspective on desire, possibility, and necessity, since or even though the perception of colour always has emotional aspects in addition to its physical complexity.

[Gabe]

Hi all,

Sorry for the delayed reply. 

I don't think we're all on the same page here. If you change the simulation profile to match the ICC of your PDF, you would get the result you were looking for. You have the same RGB values for the blue background (3,43,60). 

[FromTheDeep]

Hi Gabe, 

Thanks for the reply.

Yes you're right, thanks for mentioning that, however what ideally I'd like to be able to do is to not have to take this step to have the colours display in the correct profile that was set on PDF export. This is because my clients who are receiving my PDFs won't know how to simulate a profile like that. 

Coming from Adobe inDesign, my workflow for creating PDFs not intended for viewing online (for online I would work in sRGB) was as follows:

Open a new document and set colour profile to Adobe RGB to avoid unnecessary colour gamut limitations > Set Transparency Blend Space to RGB > Work on document until complete > Export to PDF with Adobe RGB profile embedded in PDF > PDF would display exactly the same colours as the inDesign doc I was working on, without exception > Curse Adobe for being so expensive > Go to bed. 

Now in Affinity Publisher, I tried to use the same workflow, but noticed that any time a page contained transparent objects, the colours on that page in the resulting PDF would not reflect the colours of the Publisher doc I'd been working on. 

Thomaso discovered that Affinity Publisher forces an sRGB transparency blend space on pages with transparent objects present which seems to be the culprit - I'm wondering if from your perspective it would be better to have the transparency blend space of the entire document just match the document colour space by default - I think this is the way inDesign works, which is why I've never had any colour changes on any inDesign PDFs with transparent objects present. The PDF matches the doc I've been working on every time, with or without transparent objects present. 

I use a "graceful degradation" philosophy like in web design, where I work with as little limitations on colour as possible in the development and concepting phase, and convert down to more limited gamuts as required depending on the end use case. I would think this would be a pretty common approach for designers these days. 

With the way Publisher is currently set up, every time I use transparency in my Publisher doc, I actually have to select all objects involved, export them and open in Affinity Photo, Merge them (removing the transparency), then save and place back into Publisher, deleting the original transparent objects. This means I lose the ability to tweak and make changes to the transparent objects after the fact, because they have been merged together in Affinity Photo. It's super time-consuming, and pretty painful. 

Let me know what you think and if you need more clarification, and thanks for your time.   

[Gabe]

It does sound fair. I'll log an improvement for this. 

[thomaso]

@Gabe, if I understand right, the OP wants to avoid the need for the PDF viewer (client) to adjust any setting to display the PDF in its initial colors, means to provide a PDF which always / only displays in the desired profile by default and is identical with the Affinity document's profile.

So, even if the PDF contains the document profile AdobeRGB as transparency blend space this would not ensure that this PDF gets displayed in Adobe RGB on every computer (regardless of the requirement for their hardware to be able to display AdobeRGB at all). The OP might possibly never notice any color differences without a direct, visual comparison of the PDF displayed on two setups (OP's monitor vs. client's monitor).

To auto-set a certain profile as the displaying simulation profile the PDF may have an Output Intent embedded, which can be achieved by PDF/X export in Affinity. Unfortunately by PDF specification the X standard allows print profiles only, and thus Affinity offers for an RGB document and PDF/X export only proof profiles – or uses the default CMYK profile (US web coated) as output intent, while none would display the colors with the desired RGB profile.

That means, to achieve a PDF which gets auto-displayed as desired by the OP it would require an RGB output intent / a PDF/A standard, which currently isn't available in Affinity. From that perspective improving the transparency blend space on Affinity export might be half way only and not meet the OP's use case.

[Gabe]

Agreed, what he's trying to do is not really correct from a colour management point of view. The actual bug here is that regardless of the document colour space (CMYK or RGB), when we export, we get the following Blending Colour space:

•  for PDF X4 we get Device CMYK (even for RGB documents)
•  any other format that supports transparency we get sRGB IEC61966-2.1 (Even for CMYK documents)

The blending colour space should be DeviceCMYK or DeviceRGB. Once that's sorted, his transparent document "should" match the one that's not transparent. We only care about the blending colour space at this point.

Previewing/colour managing outside our app would be a user responsibility. 

[FromTheDeep]

Hi Gabe, 

Thanks for that much appreciated!

Just as a P.S., are you able to give me any advice from a colour management point of view for this use case (i.e. delivering PDFs to clients)? My design training was definitely more theoretically-focused, and I've had to figure out the technical stuff as I go. 

Cheers  

[Gabe]

Apart from what thomaso has already said, there's not much you can do, as you rely on your customers to use the right tools to preview them. Not much different than supplying images with other than sRGB profiles. You rely on the 3rd party to properly display them in a colour managed way. 

[FromTheDeep]

Just an add on to this discussion, after working on some marketing materials for a client, I found that in-app colour conversion (RGB to CMYK for instance) works best on pixel layers with zero transparency. Any amount of transparency or using a layer that is listed as "Image" or "Shape" results in less desirable results with much wider colour shifts. I learnt this the hard way, having to manually go through and convert all layers to pixel and remove all transparency, and then make the conversion from RGB to CMYK for print, which gave me results comparable to RGB > CMYK colour conversion in Adobe Software. I'm not talking about PDF here, just focusing on in-software colour conversion. 

Definitely worth having a look at how Affinity handles colour conversion in relation to transparency, and layer types that are not pixel. There are some weird inconsistencies that are not present in Adobe, and this is something that will really take Affinity to the next level.