Jump to content

Recommended Posts

Hi,

is there a way to non-destructivly resample embedded images in Publisher/Designer to make its files much smaller?

If not, it could be a good idea when creating a new Publisher document to have a "Resample to:" feature when "Prefer Embedded" is choosen?


Best regards,

Petar Petrenko
Typesetter, Graphic Designer, Photographer
Skopje, Makedonija

Windows 10 x64 Pro
Dell Inspiron 7559 i7
Intel Core i7-6700HQ (3.50 GHz, 6M )
16GB Dual Channel DDR3L 1600MHz (8GBx2)
1TB HDD + 128 GB SSD Hard drive
UHD (3840 x 2160) Truelife LED- Backlit Touch Display
NVIDIA GeForce GTX 960M 4GB GDDR5

Share this post


Link to post
Share on other sites

To save space, presumably you would resample to a lower number of pixels. That is by definition a destructive operation, because with fewer pixels you have thrown away information.

So, no, there's no way to non-destructively do a resample operation like that. I suppose it might be possible to provide some kind of pixel quantity or quality setting that would let the program throw away a certain percentage of the pixels, while still retaining the other benefits of (Image) layers. But it's not going to be non-destructive in the usual sense.

 


-- Walt

Windows 10 Home, version 1903 (18362.239), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.2.471 and 1.7.2.464 Beta   / Affinity Designer 1.7.2.471 and 1.7.2.4464 Beta  / Affinity Publisher 1.7.2.471 and 1.7.2.458 Beta

Share this post


Link to post
Share on other sites

I don't understand how this would be possible. If you have anything non-destructive then it has to have it's original source available, so you won't gain any savings in file size? If you resample the source then you are destroying the original. If you try to keep both then surely you can at best only get an increase in file size, even if it is just some additional sample resolution settings that are added.

If you export to PDF then you get to choose resolution at that point and it resamples the images to that resolution, but obviously that's not non-destructive and not the same as saving as an .afpub file.

Maybe I'm misunderstanding?
 

Share this post


Link to post
Share on other sites
15 minutes ago, walt.farrell said:

there's no way to non-destructively do a resample operation

Maybe this is meant in relation to the original. The embedded image remains the same, but only a copy of it is resampling (destructively).


Affinity Photo 1.7.1.404, Affinity Designer 1.7.1.404, Affinity Publisher 1.7.1.404. Affinity Store.
Windows 10 Pro, Version 1903, Build 18362.145.
Latitude E5570, i5-6440HQ 2.60 GHz, 8 GB, Intel HD Graphics 530, 1920 x 1080.

Share this post


Link to post
Share on other sites
5 hours ago, Petar Petrenko said:

resample embedded images in Publisher/Designer to make its files much smaller?

Note that an embedded image already is saved in a size according to its placed dimensions. Means a downscaled image already reduces the documents file size compared to an embedded image which still has its full size on page. So, the documents file size already changes with the dimensions of the embedded item on page in a non-destructive way. Therefore resampling the embedded file might not result in an amount of size reduction as you expect it would.

Is resampling possible inside AfPub/AfDesigner? –> Yes. Right-click the image or its layer and choose a "Rasterise ..." option.
– Be aware that the three dots "..." in this commands do NOT mean that an options window will appear before rasterisation. (Here these elipses are a UI labeling bug)
– Also resampling influences more than your .afpub's/.afdesign's file size:

If you rasterise the image it will be kind of resampled according to your documents resolution at the moment of rasterising. If downsampled that way the image loses unused pixels for ever (= destructive), according to its actual size in your document. Also it loses its resource status and is not handled any more by the Resource Manager, neither as an embedded nor linkable resource.


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites
1 hour ago, thomaso said:

Note that an embedded image already is saved in a size according to its placed dimensions.

I don't think so. An embedded image is still an (Image) layer, and all of its pixels are retained.

I just embedded an image in a Publisher file, and made it fill the page width. The Context Toolbar reports: image.png.c3e504d2f3d25b93078a24cb1ca55850.png

I then shrank it to about 1/4 page width, and the Context Toolbar reports: image.png.a479c890ab5fa7fddffbfe23fed4bdb3.png


-- Walt

Windows 10 Home, version 1903 (18362.239), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.2.471 and 1.7.2.464 Beta   / Affinity Designer 1.7.2.471 and 1.7.2.4464 Beta  / Affinity Publisher 1.7.2.471 and 1.7.2.458 Beta

Share this post


Link to post
Share on other sites
43 minutes ago, walt.farrell said:

I don't think so.

I think the topic is about saving file size of "Publisher/Designer" "files". (= file size of .afpub and .afdesign)

Even in case the topic is about image size on screen and page then your DPI samples don't matter at all, because size, in terms of dimensions on page, can have very different DPI, regardless whether linked or embedded. (... and is always non-destructive by the way)

So, to proof your thinking you would compare file sizes on disk.

Of course, you can understand "size" or "much smaller" in various ways. For instance you could comment an image of the Mona Lisa painting in 1" compared to a screenshot of your complete monitor in 15" as beeing "larger" or "greater" even though your screenshot's size is 15 times taller than the 1" image of Mona Lisa. In that understanding it is not useful for a discussion to argue by default about any or even every possible meaning of words but to concentrate on the intention of a post.


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites
4 hours ago, thomaso said:

Even in case the topic is about image size on screen and page then your DPI samples don't matter at all, because size, in terms of dimensions on page, can have very different DPI, regardless whether linked or embedded. (... and is always non-destructive by the way)

That is, of course, true. My point was that regardless of the size on the page, the embedded image, as a non-rasterized (Image) layer, has all the pixels of the original. Your statement was that the dimensions you place it at factor into the data size: "Note that an embedded image already is saved in a size according to its placed dimensions."

My demonstration was that the placed dimensions do not affect the number of pixels. The dimensions only affect the apparent DPI.

Thus, the placed dimensions are irrelevant (in terms of data used in the document) unless you rasterize that (Image) layer. Until such time as it is rasterized, all the image data is present, every pixel.

The only way to save data size in the document is to find a more efficient lossless compression algorithm, or to throw away data (resampling). Petar requested resampling, which by definition is a destructive method.


-- Walt

Windows 10 Home, version 1903 (18362.239), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.2.471 and 1.7.2.464 Beta   / Affinity Designer 1.7.2.471 and 1.7.2.4464 Beta  / Affinity Publisher 1.7.2.471 and 1.7.2.458 Beta

Share this post


Link to post
Share on other sites

Walt, once more, this topic is about documents file size. This size is related to the placed dimensions of an image. If you place an image in full page size at, for instance 300 dpi, then the resulting documents file size is larger compared to the same document with the same embedded image file in smaller dimensions at 1200 DPI on the page. I assume, possibly because of its preview image being saved in different sizes.

So, with writing...:

53 minutes ago, walt.farrell said:

Thus, the placed dimensions are irrelevant (in terms of data used in the document)

... it tells confusing thoughts that - as far as the understanding of file size is concerned - are simply wrong / or not correct / or deviate from my experience. I wonder why you spread your thoughts by suspecting, but in a way, knowing. This is not helpful for the forum topic.

53 minutes ago, walt.farrell said:

Until such time as it is rasterized, all the image data is present, every pixel. 

There was no doubt about. Still, the question was: file size.


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites
14 hours ago, thomaso said:

Walt, once more, this topic is about documents file size. This size is related to the placed dimensions of an image.

Nope. It is related to the number of pixels in the placed "(Image)" file, but the placed dimensions do not directly affect the file size, unless or until the image is rasterized.

If you are seeing something different, it is probably because native format files are serialized (so edits are added at the end of the file, increasing its size), the History is included, due to differences in file data compression or recalculation of mipmaps, or for some other reason not directly related to placed dimensions.


Affinity Photo 1.7.2, Affinity Designer 1.7.2, Affinity Publisher 1.7.2; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.2.153 & Affinity Designer 1.7.2.6 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

Interestingly, I've done some tests, and to my surprise the .afpub document size does indeed change it's filesize based on how big or small the image is placed on the page. I'm going to put this down to the thumbnail that gets saved along with the file.

My tests show that using a single placed (linked) image (identical image in each case):-

634kb for a bog standard placed image that takes up the middle portion of an a4 page
391kb for a tiny speck of an image just visible in the thumbnail (maybe 5 pixels width in the thumbnail)
1.02mb for a full page image
968kb for the same full page image slide across to show a different part of the image (less details there).

The last two results I think show that this must be based on the thumbnail and the amount of detail showing in that, however that does seem a lot of extra filesize difference for a thumbnail - if I saved that thumbnail as a jpeg I would expect it to be no more than about 25 - 30 kb, so I can only assume that the thumbnail image is either larger than I can display on my computer file browser, or that it's not being compressed. But if it's not being compressed you'd expect the two thumbnails to be exactly the same file size?
 

Now, embedding the image with exactly the same placement as the previous ( I opened the same files clicked the embed in the resource manager, then saved back out) I get in the same order as before
6.94 mb (I expected extra file size here)
1.75 mb (This totally doesn't reflect the same additional file size as the first example - why not? This looks more like it's just added the jpeg file size in, which would seem logical but doesn't explain the amount of extra file size in the first example)
7.07 mb
7.00 mb

The image I placed in was 4032x3024 pixels  (1.35mb jpeg file) very boring picture out of our office window!

If I export this image to a tiff file I get 8.90mb.

So that may very well blow my thumbnail theory.  Very interesting!

This may be irrelevant to the original conversation if we're talking about exporting files to pdf etc.

Share this post


Link to post
Share on other sites
25 minutes ago, Dazzler said:

I opened the same files clicked the embed in the resource manager, then saved back out

Thanks for your testing, and your report back to us.

I have not had time to test, yet, but I think any completely valid test probably needs to start from scratch each time, and start with the image initially embedded (that is, not using the Resource Manager to embed it after the fact). Otherwise, I think there are too many other factors that could give misleading results.


-- Walt

Windows 10 Home, version 1903 (18362.239), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.2.471 and 1.7.2.464 Beta   / Affinity Designer 1.7.2.471 and 1.7.2.4464 Beta  / Affinity Publisher 1.7.2.471 and 1.7.2.458 Beta

Share this post


Link to post
Share on other sites
25 minutes ago, walt.farrell said:

Thanks for your testing, and your report back to us.

I have not had time to test, yet, but I think any completely valid test probably needs to start from scratch each time, and start with the image initially embedded (that is, not using the Resource Manager to embed it after the fact). Otherwise, I think there are too many other factors that could give misleading results. 

You think the history may be having an affect here Walt?

Just done from scratch - using same image and brand new document each individual test.

linked 856kb, embedded 6.89mb with image placed by clicking the top left point of the page (no resize or positioning)
linked 399kb, embedded 1.84mb with image placed then reduced to 10% of it's dimension, then placed at 0,0 on page.

It would be really interesting to know what's happening here ... if there are any Affinity staff available for comment? I'm sure there is a logical reason for this.

*Additional Note: opening a non-embedded file, clicking the embed then saving out gives identical results to doing it from scratch in this case so I don't think anything else is having any effect on my previous tests.

Edited by Dazzler
Additional note

Share this post


Link to post
Share on other sites
2 minutes ago, walt.farrell said:

I have not had time to test, yet, but I think any completely valid test probably needs to start from scratch each time, and start with the image initially embedded (that is, not using the Resource Manager to embed it after the fact). Otherwise, I think there are too many other factors that could give misleading results.

Absolutely! As has been reported many, many times in these forums, every save in the native file format after the first one typically increases the file size by a certain amount.

One reason for that is because of serialization -- anything that modifies in the file since the last save is added to the end of the file, so the entire file does not have to be rewritten on each subsequent save. Obviously, this increases the file size. This continues until some threshold is reached, at which point on the next save all the additions are combined into the original saved data & the file size reduces. (Please note that this my own interpretation of how the developers have explained the process, so it may not be correct in all the particulars.)

Another reason is the native file format includes pre-calculated mipmap images with each save, used to improve pan & zoom performance, so how much of a placed image is visible will also have an impact on file size.


Affinity Photo 1.7.2, Affinity Designer 1.7.2, Affinity Publisher 1.7.2; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.2.153 & Affinity Designer 1.7.2.6 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
9 minutes ago, Dazzler said:

You think the history may be having an affect here Walt?

Yes, but also the factors that @R C-R mentioned :)


-- Walt

Windows 10 Home, version 1903 (18362.239), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.2.471 and 1.7.2.464 Beta   / Affinity Designer 1.7.2.471 and 1.7.2.4464 Beta  / Affinity Publisher 1.7.2.471 and 1.7.2.458 Beta

Share this post


Link to post
Share on other sites

I did save the embedded files as new differently named files each time in my original tests. And the clicking the embed button was the only action performed in each case.

In any case, the fact is that using an identical process there is a massive difference between file sizes of the document when the images are placed at different sizes. This is utterly surprising to me (as someone who has written some basic software in the past, so have a mild understanding of the sort of things that might be happening), considering the fact that the images are non-destructive.

Share this post


Link to post
Share on other sites
12 minutes ago, Dazzler said:

I did save the embedded files as new differently named files each time in my original tests.

What are the page/spread/canvas/artboard pixel dimensions in your tests & how does that compare to the pixel dimensions of the placed image files?

Also, how complex (compressible) are the placed images & what file types are they?


Affinity Photo 1.7.2, Affinity Designer 1.7.2, Affinity Publisher 1.7.2; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.2.153 & Affinity Designer 1.7.2.6 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

The different sizes could be related in part to the thumbnails as you mentioned, but we could confirm that by turning off the Preference to Save Thumbnails with Documents.

Or they could be related to the MipMaps that R C-R mentioned.

Or something else, of course.


-- Walt

Windows 10 Home, version 1903 (18362.239), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.2.471 and 1.7.2.464 Beta   / Affinity Designer 1.7.2.471 and 1.7.2.4464 Beta  / Affinity Publisher 1.7.2.471 and 1.7.2.458 Beta

Share this post


Link to post
Share on other sites
2 hours ago, R C-R said:

Nope. It is related to the number of pixels in the placed "(Image)" file, but the placed dimensions do not directly affect the file size, unless or until the image is rasterized.

How do you know? What makes you think so?

In this topic this part ...

On 8/14/2019 at 8:38 AM, Petar Petrenko said:

(...) to make its files much smaller? 

is the goal. – Whereas this ...

On 8/14/2019 at 8:38 AM, Petar Petrenko said:

to non-destructivly resample embedded images

... is one assumption to achieve the goal. I guess you agree, that an answer to reduce file size without resampling lossless would be more satisfying for the initial poster than an answer which resamples lossless but increases file size. Compare this conversation:

  • Q: "Where in this building is a supermarket to buy some bread?"
  • A 1: "There is no supermarket in this building"
  • A 2: "You can buy bread in the bakery on 1st floor but it is no supermarket to buy other things."

I guess you agree that answer A 1 is not helpful whereas answer 2 is.

In that way this topics focus is on file size, not on resampling.
[see also the original posters "like" at the 5th post which said "I think the topic is about saving file size of "Publisher/Designer" "files". (= file size of .afpub and .afdesign)" ]

Therefore I had placed yesterday an RGB .jpg into a CMYK .afpub and saved. No image edit, no history activated. Then I noticed the resulting document file size (which is in the interest of this topic) does change with a change of the dimensions of the embedded .jpg. Means the same number of pixels in the embedded .jpg does influence the .afpub file size in relation to its placed dimensions and DPI.

Then I posted this result. File size depends on placed DPI.

17 hours ago, thomaso said:

If you place an image in full page size at, for instance 300 dpi, then the resulting documents file size is larger compared to the same document with the same embedded image file in smaller dimensions at 1200 DPI on the page. I assume, possibly because of its preview image being saved in different sizes. 

And first Walt and then you insist that would or could not be true. – A really strange way of communication.
Walt's preferred reason: "I did not have time to test" makes me wonder why he has time to spread untested thoughts, again and again and again?

 

 


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites
2 minutes ago, R C-R said:

What are the page/spread/canvas/artboard pixel dimensions in your tests & how does that compare to the pixel dimensions of the placed image files?

They are just basic tests - new document A4 in every case. Anyway, I'll leave it up to you guys to run your own tests at a more scientific level. The MipMaps sound a likely culprit, but I would've thought they would be generated upon loading rather than stored as part of the file? or is that too inefficient? I suppose in the grand scheme of things with a massive document using a lot of images etc these sort of file size differences are kind of irrelevant.

Share this post


Link to post
Share on other sites
1 minute ago, thomaso said:

And first Walt and then you insist that would or could not be true. – A really strange way of communication.

What I said was "the placed dimensions do not directly affect the file size." I then went on in the same post to explain briefly what I meant by that. A few posts later, I explained that in greater detail, based on the incomplete info the developers have shared with us about their proprietary native file format.

It may not be a perfect form of communication, but it is the best I can do under the circumstances.


Affinity Photo 1.7.2, Affinity Designer 1.7.2, Affinity Publisher 1.7.2; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.2.153 & Affinity Designer 1.7.2.6 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
3 minutes ago, thomaso said:

In that way this topics focus is on file size, not on resampling.
[see also the original posters "like" at the 5th post which said "I think the topic is about saving file size of "Publisher/Designer" "files". (= file size of .afpub and .afdesign)" ]

Petar specifically requested non-destructive resampling to reduce the file size. My primary purpose in responding was to point out that that is impossible. Which is true. But I also mentioned that better lossless compression, if possible, might help as a way to reduce file size.

You are focusing on other ways of reducing file size, which is admirable and useful. But even if placing the images at a smaller size on the page does reduce file size, as you demonstrated and Dazzler has confirmed, that can't be the solution Petar wants, because it means changing the design of the page which would not be desirable.

We have no idea what Petar "liked" about your post, and will not know unless he tells us.

And we still don't understand why reducing the size of the placed image on the page has the effect it does. But, again, that can't be the solution Petar wanted as we wouldn't want to have to redesign the pages (by enlarging the images) once we reload the document to work on it. So we don't know if there's anything in that approach that could satisfy Petar's request.


-- Walt

Windows 10 Home, version 1903 (18362.239), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.2.471 and 1.7.2.464 Beta   / Affinity Designer 1.7.2.471 and 1.7.2.4464 Beta  / Affinity Publisher 1.7.2.471 and 1.7.2.458 Beta

Share this post


Link to post
Share on other sites
8 minutes ago, Dazzler said:

The MipMaps sound a likely culprit, but I would've thought they would be generated upon loading rather than stored as part of the file?

As I understand it they are stored in the file, encoded in some proprietary way the developers are not willing to explain in detail, much like the details of serialization.


Affinity Photo 1.7.2, Affinity Designer 1.7.2, Affinity Publisher 1.7.2; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.2.153 & Affinity Designer 1.7.2.6 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×