APub 2.3: Images are upscaled when exporting to PDF

[k_au]

Latest APub on Win 10 x64

To reproduce:
The use case was a big banner to be viewed from a large distance. So make a project in a decent size, maybe 2m x 1m

Drag some (medium-res) images in and make them fit the big page.
Their actual resolution will be quite low (e.g. 40dpi)

Export the project to PDF using a dpi that's higher than that of the images (e.g. 60dpi).


Check the resolution of the images in the resulting PDF:
What should have happened is, that things like transparencies are flattened using 60dpi resolution, and the images remain at their lower native resolution.

But instead, the images will have been upscaled to the document resolution (here 60dpi)
That doesn't make sense to me, the upscaling is not really introducing better quality. It only increases the file size.

Some people reported this only happens with PDF/X files, I did not have time to check this.

 

See also the original question posed in the forum:

 

[NathanC]

Hi @k_au,

Initially following the steps strictly in this bug report post, I created a 2x1m 40DPI document, I then placed a 2560x1440 TIFF file at 100% scale on the page (40DPI) and exported the document to PDF using 60DPI. When I used Acrobat's object inspector the image had not undergone any upscaling and honoured the same resolution as my original Publisher file. I tried a few PDF/X methods as well as 1.7 but the result was the same.

However after an overview of your linked thread I am seeing the unusual upscaling as described in Lacerto's post when comparing an image that has been masked using a clipping mask to an image that has been masked via an image nested into a rectangle so it does look like this needs logging. However, your steps don't mention about a use of any type of mask and I can't replicate the problem without a mask. I've also tried this with JPEG via drag and drop into my document and then export but the result was the same as above with the correct scaling honoured. 

Could you possibly provide a sample .afpub document where you have experienced this scaling issue, along with the exported PDF equivalent and a screenshot of your export settings for comparison? I can provide a private upload link if needed

Many thanks

[k_au]

Hi @NathanC thanks for looking into this.
I've now made a series of tests to reproduce the issue. The files are attached.

I was wrong about the issue showing up with JPGs. It only shows up when transparency is involved.
So I made a small graphic and saved it as PNG, WEBP, TIFF and GIF with transparency and for comparison as a PNG without transparency.
I dragged these into APub and resized the images so that they have a real resolution of about 148ppi.

Then I exported the project to PDF using all the presets (PDF resolution 300dpi).
The issue only appears when exporting to PDF/X1a or PDF/X3.
Then the transparent images will be scaled up to 300dpi, with the exception of the non-transparent PNG and the GIF.

Also interesting: If I leave the "change image colours" checkbox empty when exporting PDF/X3 the transparent PNG, WebP and Tiff will still be converted to CMYK! The GIF and the non-transparent PNG remain RGB.

upscaling-tests.7z

[NathanC]

Hi @k_au,

Thanks for the test documents and detailed explanation. The PDF/X1a and PDF/X3 standards prohibit transparency, therefore these images are getting rasterised/flattened on export to opaque images and are upscaled to the DPI set on export similar to if you had rasterised all the image layers and then exported. As a result of this rasterization, they have been converted to CMYK in line with your document profile. PDF/X3 allows for RGB images, whereas PDF/X1a does not, which is why all the images are converted to CMYK in the PDFX1a document.

However, in your test document you appear to have found a bug with regards to the Transparent GIF export as this transparency has been maintained despite it being prohibited by these two PDF/X standards, so I'll be getting this issue logged with the developers.

[k_au]

Thanks for looking into this!
I understand the transparency getting flattened, but it's a bad habit to upsample lower dpi images. Downsampling from higher resolution makes sense, of course. Artificially raising the dpi (effectively inventing data that just isn't there) does not add any quality, it only makes the files bigger. IMHO this is a bug.

 

[DWright]

I have logged this with our developers

[PE1]

On 12/8/2023 at 1:23 PM, k_au said:

I understand the transparency getting flattened, but it's a bad habit to upsample lower dpi images. Downsampling from higher resolution makes sense, of course. Artificially raising the dpi (effectively inventing data that just isn't there) does not add any quality, . . .

I believe the DPI settings that you entered is the reason your images have higher DPI on export. You used the presets. Based on what I read, the application was simply doing what you told it to do. I believe, you do have the ability to change this for your banner requirment.

I downloaded your pdf with the stars graphic each having 148 DPI as described in your setup and successfully exported it to PDF x1a, X3 and 1.7.  with all of the images maintaining thier 148 DPI. None of the images DPI changed because of the settings I used. Is this the result you are looking for? 

 

[k_au]

Hi PE1, thanks for your help.

The bug is a bit different than what you have done:
In any print product, it may be that there are images that don't have the required dpi available. If that's the case, these images should not be automatically re-computed to fit the output dpi. Re-sampling will not make the quality better (unless maybe in the future there are improved "AI" algorithms at work). 
So if I have a print job that requires 300 dpi, and some of my images have only 200 dpi at the size used, then I want these pictures to retain the "true" 200 dpi and not be artificially upscaled to 300dpi. The rest of the PDF should use 300dpi, e.g. for flattened transparency or other images that were 300 or more dpi. Down-sampling from (much) higher dpi is a good thing.

Hope it's clearer now what my problem was!