Jump to content
You must now use your email address to sign in [click for more info] ×

Low dpi images in document, when opened on other mac


Recommended Posts

If I create a AFpub doc on my MacBook or viseversa on my home mac mini and place pictures on the layout, linked or embedded makes no difference, safe/close the file and reopen it on that mac everything is fine.

If I open the document on the other Mac, the placed pictures are pixelatet. It looks as they have low dpi. But the resource panel shows all is "OK". On Export you got also the low dpi pictures. If you open the document on the Mac that created the doc, everything is fine.

 

You can also copy the document with all resources to the other mac. Same issue.

 

On both Macs is the AffinityShop Version 1.7.1 installed.

--

Regards

Torsten

Link to comment
Share on other sites

It is hard to judge because the placed image is quite pixelated by its design.

But the values of placed DPI in Resource Manager appear strange: for instance the item in the bottom right corner:
original: ca. 2000 px, 72 dpi
placed: ca. 4000 px, "144 dpi" ?
That can't be true.

If the placed image has twice the size of the original, so its DPI can not be doubled but must be the halved, means placed DPI is 35 dpi - instead 144.

484216313_collageoriginalsizevsplaceddpi.thumb.jpg.9c3e84a044bf72153d2d81bdb7317f1e.jpg

I know such a behavior of increased placed DPI from an earlier beta (I guess up to v293) but it got fixed before final release.

Also weird in your doc on my mac:
When I increase its document resolution (300 > 600) the placed image DPI increases, too (144 > 288). Which can't be true for the same reason mentioned above.
When I change the document units from pixels to millimeters > close window > change back to pixels then it is rather confusing: the former spread size of ca. 7000 px is now ca. 3500 px. Hm. The half. – Possibly you had switched document DPI and/or unit while creating the layout and confused the application that way?

If you can reproduce that weirdness: As a workaround I would copy all content and place it in a new document with the unit and DPI you really want.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

38 minutes ago, thomaso said:

If the placed image has twice the size of the original, so its DPI can not be doubled but must be the halved, means placed DPI is 35 dpi - instead 144.

Here's a test for you:

  1. Create a new Publisher document.
  2. Draw a Picture Frame.
  3. Place the Ohne Titel.tiff file in that Picture Frame.
  4. Look at the Resource Manager.

My results:

image.thumb.png.f1207f67e731b003308e8b4857dce1de.png

Calculating the size of the placed image: 1920px / (265px/inch) = approximately the 7.2 inch width shown in the Resource Manager.
And 1080px / (265px/inch) = approximately the 4.06 inch height shown.

Note that if the original 1920px wide image was at 72dpi as claimed in the Resource Manager, then the original would have been 26.7 inches wide. Compressing it down to 7 inches wide must increase the dpi. So it does not seem unusual for that to happen.

Also, Photo agrees that the original image is 72dpi, with a size of 26.667 x 15 inches.

 

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

@ Walt, when I opened the user1984's .afpub it had unit pixels in document setup. Therefore in Resource Manager the original and the placed size are both in pixels. And obviously (see screenshot) the original values for both dpi AND size are smaller than those of the placed. These "AND" can't be true, because the placed DPI does not increase together with the placed size.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

24 minutes ago, thomaso said:

@ Walt, when I opened the user1984's .afpub it had unit pixels in document setup. Therefore in Resource Manager the original and the placed size are both in pixels. And obviously (see screenshot) the original values for both dpi AND size are smaller than those of the placed. These "AND" can't be true, because the placed DPI does not increase together with the placed size.

I think that perhaps it does, but it's tricky to understand when looking at px values.

Perhaps this will help:

  1. The original .tiff file is 72dpi, and the image size is 1920px x 1080px (approximately 27 by 15 inches).
  2. The Publisher document is 300 dpi, and the page size is 7110px x 4748px (23.7 x 15.82 inches).
  3. That copy of the tiff file is being placed such that it is 3993.7px x 2246.5px in the Publisher document, which is approximately 13.3 x 7.5 inches.
  4. Placing (squeezing) the 27x15 inch image into a 13.3x7.5 inch space requires approximately doubling the dpi of the image.
  5. Therefore, that copy of the 72dpi original is 144dpi after it is placed.

 

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

This is only a testfile and I generated a tiff for that reason in a few seconds.

 

The Layout is the original but I can not publish the original tiffs in the forum. The resolution of the placed images is like the following. That are the original files. I scaled the images in the layout.

image.png.3c3b6e3b4c98bcc83885c1d07103e341.png 

 

That is NOT the problem. I can export the design as a tiff with no problems on the Mac where I have designed it. The problem is on my home Mac, there it is pixelated. The only solution is to replace all images in the document and that is no really good solution.

--

Regards

Torsten

Link to comment
Share on other sites

It is true, the document is in pixel without dpi.

 

When I change the document setting from "pixel" to "mm" with 300 dpi all images appear sharp and crisp. Then I copy the document to my other Mac and ... pixelatet! So I change the doc on my other Mac from "mm" to something else > safe > reopen again, everything looks fine!

I testet this a few times and it works everytime. Change the doc units to something else, safe, reopen, images are crisp and sharp.

Not a fine solution but better then replace all images again. So I say ... this is a bug!

--

Regards

Torsten

Link to comment
Share on other sites

12 minutes ago, user1984 said:

It is true, the document is in pixel without dpi. 

No, it's even worse. In document unit pixels a resources resolution depends on document resolution. But actually it just pretends to ...

 

2 hours ago, walt.farrell said:

it's tricky to understand when looking at px values.

I see and understand what happens if set to pixels: Then a resources resolution appears to increase with an increase of document resolution.

Or: if your resource is shown with too low placed DPI then you simply increase the document resolution and Resource Manager wants to make you believe the resources resolution is fine now. – A Horrible issue. Because:

That way you never know what the true resources resolution will be on output. [ Except: documents DPI = resources original DPI. ]

Don't you agree that will result in a lot of confusion and complaints? I definitely name this a bug.
(In AfPub beta it used to be the same for mm, inch etc. but got fixed. Guess why?)

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

6 minutes ago, thomaso said:

That way you never know what the true resources resolution will be on output.

Do you have a demonstration or proof that the dpi claimed in the Resource Manager is not correct?

Mathematically it works out, as I showed. I think the only way to show that it is not correct would be to Export a PDF, with the options set not to resample the embedded documents, and then examine the PDF to see what really happened.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

56 minutes ago, walt.farrell said:

Do you have a demonstration or proof that the dpi claimed in the Resource Manager is not correct?

This thread is one. It appears the low output resolution got fixed by switching the document unit.

Here is another one:

1. Create an image with 10 x 10 px. and save with 72 dpi. (<– a tiny icon for instance)
2. Place it in Afpub: 72 DPI, unit pixels.
3. Print (fill the sheet).
4. Increase the documents DPI up to 1200.
5. Print again.

Do you really expect the 2nd print will show the image in higher resolution (= sharper) than the 1st print?

Whereas the amount of printed 'dots' (='pixels') get increased by increasing the documents DPI – still the image (10 x 10 px) remains the same and never will become better by upscaling.
THAT is why vector is preferred.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

another, historical approach:

in early computers all fonts were pixels, no vectors. The letter O was not a round circle but a collection of squares arranged in the look of a circle. If you printed such an O in huge size (= with high print resolution = high DPI = a lot of pixels/dots on paper)  then the O did not become rounder but its steps became larger and more visible, more obvious.

The misunderstanding might come from two different usages of the term resolution: a.) the input = content / b.) the output = result.
Of cause one can print a low res a) with a high res b) – and that way your mathematics is correct: the printer does more work and puts more and tinier dots.

Resampling (or upscaling) does not reduce the amount of visible stair steps of the letter O from above. It simply shows the squares more detailed, usually by a softer edge (compare: Antialiasing).

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

1 hour ago, user1984 said:

Then I copy the document to my other Mac and ... pixelatet! So I change the doc on my other Mac from "mm" to something else > safe > reopen again, everything looks fine! 

That is strange because my mac opened your .afpub in pixels, means in the unit you had saved it.
So I wonder why your other mac did not see that setting in the .afpub.?

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

28 minutes ago, thomaso said:

That is strange because my mac opened your .afpub in pixels, means in the unit you had saved it.
So I wonder why your other mac did not see that setting in the .afpub.?

It sounds like @user1984 is saying that the images contained in his document appear pixellated (low-resolution, as though a linked-file were missing?) when the .afpub file is opened on another Mac, but you are talking about the document units (pixel vs inches vs ...)?

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

That is true!

My first thought was, the source files are not found, because of the copiing to another mac. But it was not. And it happened also, when I embed the images.

I think the other Apub App don‘t see the units of the doc. Maybe in the App that created the doc this info is somewhere in the cache ...?!

--

Regards

Torsten

Link to comment
Share on other sites

11 hours ago, user1984 said:

When I change the document setting from "pixel" to "mm" with 300 dpi all images appear sharp and crisp. Then I copy the document to my other Mac and ... pixelatet! So I change the doc on my other Mac from "mm" to something else > safe > reopen again, everything looks fine!

@user1984,

if your macs cache would be related then I would not see your preset unit "pixel" on my computer when opening your doc.
On the other hand I don't see in your doc any change of visual sharpness, regardless of the selected unit. – So I'd like to know what makes the difference indeed.

1. When you wrote how you solved the issue then you say first "from pixel to mm" and second "from mm to something else". Does it mean, you can see the image in expected resolution in every unit but must switch the unit first?

2. And, if you changed the unit, don't you see the new unit in the ruler immediately – without the need to save and reopen ?

3. And, possibly, see the better quality immediately as soon you select a blurry image frame – before save and reopen the .afpub ?

4. Can you reproduce this different image quality between your macs with others .afpubs ?

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

1. Yes, you must only change the units

2. The rulers change immediately but I have to safe and reopen the document to see the effect on the images.

3. This I have not testet. I‘n not on a Mac right now.

4. Yes, it also happens on other docs with images.

--

Regards

Torsten

Link to comment
Share on other sites

3 hours ago, thomaso said:

@user1984,

if your macs cache would be related then I would not see your preset unit "pixel" on my computer when opening your doc.
On the other hand I don't see in your doc any change of visual sharpness, regardless of the selected unit. – So I'd like to know what makes the difference indeed.

1. When you wrote how you solved the issue then you say first "from pixel to mm" and second "from mm to something else". Does it mean, you can see the image in expected resolution in every unit but must switch the unit first?

2. And, if you changed the unit, don't you see the new unit in the ruler immediately – without the need to save and reopen ?

3. And, possibly, see the better quality immediately as soon you select a blurry image frame – before save and reopen the .afpub ?

4. Can you reproduce this different image quality between your macs with others .afpubs ?

back on my mac

 

3. No this dosn't work. I have to save and reopen the file to have no blurry images.

It seems this is a document unit problem/bug! Hopefully it will be solved in a future version!

--

Regards

Torsten

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.