Bug - Adjustment layer incorrectly applied on transparent

[manandmouse]

Exporting PDF using a placed masked image with adjustment layer, i.e Brightness/Contrast, the adjustment is applied on the Publisher page background.
Placing the same image in a Photo document, exporting PDF is just fine.

Coming from Photoshop and InDesign, adjustment layers are never done on transparent (i.e going "though" the image and passed on to the Designer background). This issue was a bit tricky to find due to the fact that it has never been an issue in other apps.

Zipped file with example files Publisher/Photo and an Image with adjustment layers. 

I know that there are workarounds, but this bug has to be fixed.

 

Adjustment_layer_on_transparent.zip

 

[Sean P]

Hi manandmouse,

The document you've sent is actually created in Publisher and not Designer (though can be reproduced when opened in Designer).

I believe the source of the issue here is that your 'Designer' document is actually in CMYK/8 where as the Photo one is in RGB/8. The text.afphoto file used in both documents is also in RGB/8.

When exporting the Designer document to PDF this text.afphoto is getting rasterised as an RGB image on export to PDF because the source is in RGB. Unfortunately it is also rasterising it with the background colour which is not completely matching because of colour conversions. What would be useful in this situation is if the object was getting rasterised and retaining its transparency. I'll pass that over to development to see if that can be done, as not all PDF versions support transparency on images.

To get around this depending on your needs you could, in the PDF Export Settings, set Colour Space: RGB and that will force everything to be in RGB on Export and stop the colour conversion happening. However I don't know what your exact needs are so that is something you will need to figure out yourself.



 

[manandmouse]

Sorry, quite right. Publisher it is. Edited.

No, the RGB doesn't matter. It has nothing to do with it. The problem is that the  adjustment layer works "through" the transparent onto the page background in Publisher.

If I/you make a merged variant of the image (Affinity Photo image), and switch of the adjustment layers, there is no problem (RGB image). 

It could have been a "feature", i.e applying adjustment layers on things below the image, I first thought that Affinity had done so (in contrast to Adobe). But since it works differently in Photo and Publisher, it's clearly a bug.

A note: transparent is transparent. RGB and CMYK has the "same" transparency, i.e 0%. So again, it's a bug, things are done in the transparency that it should never ever do.

Merged_transparent_Publisher.zip

[manandmouse]

Please confirm that this bug is going to be fixed. 

[Sean P]

On 2/9/2021 at 9:37 PM, manandmouse said:

Sorry, quite right. Publisher it is. Edited.

No, the RGB doesn't matter. It has nothing to do with it. The problem is that the  adjustment layer works "through" the transparent onto the page background in Publisher.

If I/you make a merged variant of the image (Affinity Photo image), and switch of the adjustment layers, there is no problem (RGB image). 

It could have been a "feature", i.e applying adjustment layers on things below the image, I first thought that Affinity had done so (in contrast to Adobe). But since it works differently in Photo and Publisher, it's clearly a bug.

A note: transparent is transparent. RGB and CMYK has the "same" transparency, i.e 0%. So again, it's a bug, things are done in the transparency that it should never ever do.

The problem is the adjustments are causing the object to get rasterised and it rasterises the background alongside, this means that there isn't any transparency on that object, so the colour mode does come in to play. If you investigate the resulting PDFs you can see their individual parts and see that happening. With that said I have passed an issue along to development as your object looks like it could retain the transparency when getting rasterised (due to the adjustments), unfortunately I don't have a time frame on when that will be done.

Your Photo document contains a 'Fill layer' which again isn't supported by PDF so gets rasterised to RGB, and the embedded photo is also getting rasterised to RGB, as they're both in RGB the colours are the same so no difference appears but when you actually investigate the PDF you will see that the embedded afphoto file is not transparent.

Now your Publisher document instead of using a Fill Layer uses a Rectangle which is supported by the PDF format, so this goes out as a CMYK vector object (as the Publisher document is CMYK and not RGB like Photo), however again as the adjustments are enabled, it is getting rasterised as RGB (because the embedded document is RGB) with the background and this is causing the colour difference. See below:


Finally when we look at the Merged document from the last zip you can see that this is not getting rasterised as there are no adjustments, and the transparency is retained on the object, as the AFPhoto contains a single pixel layer with transparency and doesn't require rasterisation.

[manandmouse]

Thanks for reporting it.

It's a bug however you may try to explain it. It has nothing to do with PreFlight checking unfortunately. It's a bug only appearing in Publisher.
- The (switched of) Fill Layer has nothing to do with it. I've attached a screenshot of an image where the fill layer is removed (has no fill layer, but still the same problem)
- CMYK/RGB has nothing to do with it either(and it shouldn't as transparency is the "same" for RGB, CMYK, LAB... Transparency is transparency in all color models, it has no "color")
  - Attached sample where there is RGB in both Publisher and Photo 
  - Attached sample where there is CMYK in Aff Photo "document" and the RGB in the embedded Aff Photo "image": Still no problem in Aff Photo.

The reason of reporting this bug is a "Workflow" matter:
Using the Affinity Photo image directly in Publisher instead of converting it to i.e PNG, is a great time saver and ensures quality.
It's also one of the best Affinity features to be able to work with the Aff Photo image within Publisher. Exporting as PNG disable that feature.
I always have a fill layer in my Photo images for workflow reasons, i.e checking that there is a smooth edge agains transparent. I may have different variants of the image etc etc etc.

Compared to Adobe Photoshop and InDesign there has never ever been a problem with this. Never ever. I've used this workflow for decades without any issue with Adobe products.

This is a bug ONLY in Aff Publisher, not in Add Photo.
If there was an issue with turned off fill layer, CMYK, RGB etc as you described, surely it has to be the same for Aff Photo - but it isn't.

The bug is very easy to replicate. I shouldn't be forced to  "prove" the bug over and over. It's a bug. It's not my documents. It's easy to replicate by anyone.

A note: Exporting the PDF from i.e Apple Preview as PNG may get rid of the error/bug. So it is some strange thing happening and there is "faulty" information in the PDF. Sending such a PDF to a Printing House you will never know the result as it depends of the Printing House's RIP.

 

[Patrick Connor]

28 minutes ago, manandmouse said:

Thanks for reporting it.

It's a bug however you may try to explain it.

The fact that Sean (a QA) has reported it (to the developers) means he agrees it needs looking at. Sean understands the problem and explained how it is currently functioning in case there is a work around, but only a developer can address it.

[manandmouse]

Ok. I know. But I clarified that this problem is not related to mixing CMYK and RGB. 
It's important to start to look for the bug at the right place.

I'll say that the bug is that the adjustment layers are "working through" the transparent areas (only in Publisher). As most page backgrounds are white, the bug has probably got unnoticed.

A note about same workflow with Photoshop/InDesign: Photoshop actually saves a merged image automatically (default setting, can be changed). This is how I worked around the problem here. I created a merged image and turned off all adjustment layers.

My wish is that Publisher will be a perfect competitor to InDesign. Therefore, it can't be bugs like this if you want to reach the professional market. As it is now, I can't trust the PDF export 100% when sending PDF to a Printing House. I've done it, and it works. But I've been working with Desktop Publishing for over 30 years and have handled PDF and PostScript problems over the years and knows what/how to check. However a "normal" user may end up with problems.

[Hangman]

@manandmouse and @Sean P I think you are both right and both wrong in part with what you are saying in that:

1. the issue in this instance is not specifically caused by the source Affinity Photo file being RGB and the Affinity Publisher file being CMYK
2. the adjustment layers are "working through" the transparent areas (only in Publisher). This is also not the case, if you place your source RGB graphic into a CMYK Affinity Photo file in the same way you are placing it into a CMYK Affinity Publisher document you will see exactly the same result when exporting to a PDF file, i.e. the lighter blue background where the background has been rasterised.

The issue has to do with how the file has been created. If you nest your adjustment layers as per the right hand layer panel layout below rather than sitting the adjustment layers on top of your graphic...

then placing your RGB graphic into your CMYK Publisher file and exporting as a CMYK PDF will give you the correct result as shown below.

faceplate_with_nested_adjustments.afphoto

faceplate_with_and_without_nested_adjustments.afpub

I can't upload the exported PDF at the moment, it just shows the file as 'Queued' and nothing happens but if you export the attached .afpub file page 2 and 3 spread you will see the results shown above.

[manandmouse]

Yes, you may nest the adjustment layers.
Again, you can merge all layers into one and switch the other off, as I find much easier.
You could probably solve it in some other ways as well, e.g masking etc.
It's a workflow issue. Some images may contain 10 layers, and then it's messy to nest things as suggested.
I also have customers using Affinity as per my recommendation. I really don't want to explain to them to how get around this bug. It's better for everyone that Affinity remove the bug.

It took me a while to figure out this bug. Most users would not find it and will most likely end up with problems.
I really want Publisher to be a good competitor to InDesign. As it is now, it's not 100% professional.

Still: It's a bug. It hasn't been fixed in 1.9.1.
The problem does not occur in Affinity Photo, only in Publisher.

The adjustment layers should never work on transparency. 
It doesn't in any other apps that I know of, and I have used DTP apps since the 90's on several platforms.

[Hangman]

@manandmouse I think both @Sean P and @Patrick Connor have ackowledged this as an issue and the thread has been given the bug report reference afd-5283 so I don't think anyone is suggesting this isn't potentially a bug, I was simply suggesting a way of overcoming the issue when using live placed images in publisher should you need to edit the source graphic and have it automatically update the graphic in publisher.

Obviously merging layers won't keep the graphic live and would mean re-importing after adjustment so it all depends what you are trying to achieve.

1 hour ago, manandmouse said:

It's a workflow issue. Some images may contain 10 layers, and then it's messy to nest things as suggested

Hardly messy, simply a case of placing the adjustment layers in a differnt position in the layers panel.

 

1 hour ago, manandmouse said:

It's better for everyone that Affinity remove the bug

Of course, we'd all love to see it fixed.

 

1 hour ago, manandmouse said:

The problem does not occur in Affinity Photo, only in Publisher.

This is not the case, it 100% happens in Affinity Photo as well. Place, (with emphasis on the word place, rather than simply export or copy and paste) your RGB graphic into a new CMYK Affinity Photo document and export it as a CMYK PDF and you'll see what I mean. Trust me, I tested this thoroughly.

 

1 hour ago, manandmouse said:

I really want Publisher to be a good competitor to InDesign. As it is now, it's not 100% professional.

As do we all, remember Publisher is still a 1.X release, InDesign is close to its 22nd birthday and it is still not exactly 'bug free' even now.

I think you will find the team at Serif far more responsive when it comes to addressing bugs than Adobe so this will be addressed but in the meantime you have a work around using my suggestion if you want to maintain a live link to the source file or you can simply merge layers if you don't have a need to maintain the live link.

It sounds as though you, like me, have been in this business since the inception of digital, remember it took Adobe six years to introduce layers to Photoshop and I still have nightmares about the all nighters I used to pull back in the 90s rendering After Effects timelines back in the days when it was a CoSA product, prior to being acquired by Adobe because it didn't have batch processing but the client deadline was 9am the next day which meant having to baby sit the renders just in case and being woken up at 2am in the studio when one render errored and the default error sound built in to the software was a massive car crash which sounded so real I actually though there had been a car crash outside!

Anyway, have faith, the issue has been acknowledged and as frustrating as it is, there are decent workable workarounds for both live and non live implementations and getting annoyed with Serif helps nobody. This will be fixed...

[manandmouse]

Ohh, I'm not annoyed. Far from it. I do express my opinion thou and doesn't agree with many statements. My experience may differ from others.

I'm really pleased that Affinity has created Publisher. Affinity have given us all a way to get rid of Adobe. But I do wan't Publisher to work for professionals, that's all.

However I've reported other bugs a long time ago that still are there. So... let's hope they get rid of this bug then.

[manandmouse]

Found the same issue in Designer now. Have the problem got worse since the latest updates? I didn't noticed the problem there before. However, when creating a high res PDF for printing, the problem was in Designer as well.

Affinity: This is a very serious problem. It shouldn't be very hard to fix it. If you find it problematic, do as adobe does with Photoshop images:
The save a "merged" image automatically. This image is used by other applications. That's an easy workaround.

The problem has to be fixed. You are targeting professionals with your apps and we expect your apps to create print-ready PDF's.

[Hangman]

Hi manandmouse,

Do you have a particular sample AD file and source AP file demonstrating the issue you are having in Designer so we can take a look or are you using the one from your original post. I'm not seeing the same issue in terms any of colour difference.

[manandmouse]

I already spent a lot of time proving the bug in Publisher. There is no point spending any more time. The bug is there and it can be reproduced. 

[loukash]

On 2/26/2021 at 8:11 PM, Hangman said:

I don't think anyone is suggesting this isn't potentially a bug

The actual issue that I'm seeing here is the lack of a reliable CMYK preview within Publisher/Designer. You really have to export a PDF first that you can inspect with a reliable tool like Acrobat to see what will potentially happen in print. And more often than necessary, you may want to bang your head against a wall.
That's bad.
And that should be fixed.

1 hour ago, manandmouse said:

The bug is there and it can be reproduced. 

The actual behavior of the adjustment layers from the placed Affinity document is completely logical, as already outlined in

The software only does what it's told. This is how the different layer modes and hierarchies are supposed to work. The adjustments remain interactive in a placed document. At best, it would be nice to have an option for placed Affinity documents à la "Preserve Alpha" or something like that.

So, if you want the adjustments to affect only the "Background" layer but not anything below, nest them, as demoed above. This workflow (as opposed to a "workaround", vive la différence) is as simple as double-clicking the linked object and edit it in the Photo persona to fix it accordingly.

[manandmouse]

No. I already explained this. Effects should not work through transparency. 

You may be right if the problem was intentional. But: then it should be the same in all Affinity apps, and it's not. So it's a bug however you see it.

And, as I explained, Photoshop has never done it like this. So no professional could ever be used to such a "feature". It took me a while to figure out this problem. And I'm a problem solver professional, that's one of my roles. Most people may never find this problem at all and maybe end up with leaving Affinity due to bad PDF files.

I've already suggested 2 solutions to Affinity. Your "Preserver Alpha" may be a third, but it's better they just fix the bug. Easier for the user.

[loukash]

1 hour ago, manandmouse said:

it should be the same in all Affinity apps, and it's not

It is the same, as explained above by others. Please read again, and more carefully this time.
This is how this workflow, er, works.
Adjustment/filter layers "printing through" alpha in this specific layer hierarchy in placed Affinity documents is something that other users may possible want as part of their specific workflow.
I, for one, didn't know that it behaves like this until I stumbled upon this thread earlier today. But now that I know and understand how it works, I can see its potential, and I like it.

So if you want it to behave differently, use a different workflow.

1 hour ago, manandmouse said:

Photoshop has never done it like this.

Placed PS files behave differently because its document format is not directly exchangeable with either the ID or the AI document format. Each Adobe document format lives in its own universe, and they can only interact to a limited degree by using import filters.

Not so the Affinity document format.

So you're comparing apples with … fish.
(Which reminds me: I should go and cook fish for dinner now. My wife's hungry! :D)