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

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?

All the latest releases of Designer, Photo and Publisher (retail and beta) on MacOS and Windows.
15” Dell Inspiron 7559 i7 Windows 10 x64 Pro Intel Core i7-6700HQ (3.50 GHz, 6M) 16 GB Dual Channel DDR3L 1600 MHz (8GBx2) NVIDIA GeForce GTX 960M 4 GB GDDR5 500 GB SSD + 1 TB HDD UHD (3840 x 2160) Truelife LED - Backlit Touch Display
32” LG 32UN650-W display 3840 x 2160 UHD, IPS, HDR10 Color Gamut: DCI-P3 95%, Color Calibrated 2 x HDMI, 1 x DisplayPort
13.3” MacBook Pro (2017) Ventura 13.6 Intel Core i7 (3.50 GHz Dual Core) 16 GB 2133 MHz LPDDR3 Intel Iris Plus Graphics 650 1536 MB 500 GB SSD Retina Display (3360 x 2100)

Link to comment
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
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

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?
 

Link to comment
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 Store (MSI/EXE): Affinity Suite (ADe, APh, APu) 2.4.0.2301
Dell OptiPlex 7060, i5-8500 3.00 GHz, 16 GB, Intel UHD Graphics 630, Dell P2417H 1920 x 1080, Windows 11 Pro, Version 23H2, Build 22631.3155.
Dell Latitude E5570, i5-6440HQ 2.60 GHz, 8 GB, Intel HD Graphics 530, 1920 x 1080, Windows 11 Pro, Version 23H2, Build 22631.3155.
Intel NUC5PGYH, Pentium N3700 2.40 GHz, 8 GB, Intel HD Graphics, EIZO EV2456 1920 x 1200, Windows 10 Pro, Version 21H1, Build 19043.2130.

Link to comment
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.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
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
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

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.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
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
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, 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.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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.

Link to comment
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
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

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
Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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
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

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.

Link to comment
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?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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
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

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.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
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.

Link to comment
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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
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
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

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.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

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.