FreewayTalk

19 replies to this thread. Most Recent

Paul Scott

25 Apr 2019, 4:04 am

[Pro] Large responsive sites

I have been converting some cathedral photo sites made using exhibio to a new responsive format using backdraft. The old sites were about 150 Mb in size; the new sites are 0.5 Gb + in size.

The photo input is about 100 Mb in each case.

Is this expected? Thanks, Paul

Adelaide, Australia

Paul Scott

25 Apr 2019, 9:54 am

PS. The reason I raise this is that I am running out of RAM when trying to save the sites. I find that reducing the size of the Freeway pages has no effect on the overall size. Any other (easy!) ideas?

Paul

Adelaide, Australia

waltd

25 Apr 2019, 12:44 pm

Freeway documents cache all of the contained images (and all other resources) within them, as a last ditch rescue should the original images you “place” on the pages become lost. You can do two things to try to reduce the size of these backup elements. First, open the Edit / Resources dialog, and press the Resample All button. That should help out if you have large original images that were cropped, or resized very small.

Another thing you can do, which is slightly destructive (but only to the backup, not the originals, and not to the published site) is to open the File / Document Setup dialog, and change the Document Graphics picker from Millions to Thousands or 256. This will only affect how the images are displayed in the design view, and you’ll be hard-pressed to see a difference between Millions and Thousands. 256 will look a little ’90s perhaps. After you make this change, again press the Resample All button to enforce the change across existing resources.

See if any of this helps. The document itself is not likely really that large, and certainly should not be approaching a half a gigabyte in any case. My guess is that you have a lot of high-res images in your site, and the backups are choking you.

Walter

On Apr 25, 2019, at 12:04 AM, Paul Scott <[email protected]> wrote:

I have been converting some cathedral photo sites made using exhibio to a new responsive format using backdraft. The old sites were about 150 Mb in size; the new sites are 0.5 Gb + in size.

The photo input is about 100 Mb in each case.

Is this expected? Thanks, Paul

Freeway user since 1997

http://www.walterdavisstudio.com

Paul Scott

25 Apr 2019, 9:46 pm

Many thanks Walter. That is exactly the sort of reply I had hoped for! I will follow your suggestions and see what happens.

Paul

Adelaide, Australia

Paul Scott

26 Apr 2019, 10:14 pm

Hi Walter. Here is the link for my site for Ripon Cathedral:

http://paulscottinfo.ipage.com/england/cathedrals/ripon

I am delighted with the site and its functionality: it appears exactly right for desktop, iPad and iPhone. The only drawback is the size of the Freeway file: 1.56 GB! In fact I can live with this – my computer has plenty of memory, but the problem is the RAM. I could only save my file by closing all other applications.

I am working on a new site for Wells Cathedral which, with its garden, involves more photos. I may have to construct two linked sites!! Surely not?!

Out of interest, my original Ripon site constructed with Exhibio, was only 149.4 MB. Also, I save my photo files at 1 MB, but I understand that Freeway reduces them automatically.

Thanks for your help.

Paul

Adelaide, Australia

Paul Scott

26 Apr 2019, 10:17 pm

PS I thought I had answered your previous post, but I can’t see it. I am using the ‘thousand’ setting rather than the millions, and I ran the Resample All, but it had no effect on the size of the Freeway file. :(

Adelaide, Australia

Paul Scott

27 Apr 2019, 11:16 pm

PPS I thought I might have resolved this problem. I was thinking about your comments about backing up and resampling … . For the past seven years with my cathedral photography I have kept large files of original jpegs. Never caused any problems. For Ripon this file was about 1 GB. So maybe Freeway was linking to this? So I deleted the file and emptied the Trash, and then resampled and resaved. Acute disappointment!! No change in the size of the Freeway file …

Adelaide, Australia

waltd

28 Apr 2019, 1:54 am

Go back into the Edit Resources dialog, and see if that image is still in the list (marked as missing). If so, then the proxy image in your Freeway document is still there, still being used. Deleting the original if the image is still placed in your Freeway document is not going to shrink anything. Deleting an image from the page in Freeway, then publishing again, then resampling all, now that should shrink the document by an image-sized amount.

Walter

On Apr 27, 2019, at 7:16 PM, Paul Scott <[email protected]> wrote:

PPS I thought I might have resolved this problem. I was thinking about your comments about backing up and resampling … . For the past seven years with my cathedral photography I have kept large files of original jpegs. Never caused any problems. For Ripon this file was about 1 GB. So maybe Freeway was linking to this? So I deleted the file and emptied the Trash, and then resampled and resaved. Acute disappointment!! No change in the size of the Freeway file …

Freeway user since 1997

http://www.walterdavisstudio.com

Paul Scott

28 Apr 2019, 4:31 am

Hello Walter. Many thanks for persevering with me on this problem!

I don’t understand the term ‘that image’ in your last post, and with the Ripon files, there are none which are missing. Nevertheless, in the program I deleted the title photo and replaced it – it had to resize, so I thought that was encouraging. Then I clicked Publish, resampled and saved. The file came down from 1.56 GB to 1.54 GB!

So perhaps I’ll try this procedure with several other photos and see what happens!

Paul

Adelaide, Australia

waltd

28 Apr 2019, 3:39 pm

Freeway works somewhat like QuarkXPress or InDesign, in that the document stores a reference to an original image, and then when you print (either to HTML, in Freeway, or PDF, in the others) that original image is resampled and converted into the output stream. The Freeway (or other DTP app) document doesn’t store the original image, but rather just a path to find it on the Mac’s filesystem. Freeway also stores a proxy (resampled version) of the original image, which it uses to avoid having to re-process all the placed images on the fly every time it needs to show you what the page looks like. This proxy can be quite large on its own, and it does become part of the total file size. In a Freeway document where there are hundreds of photos, these proxies can start to add up.

The controls in the document setup dialog are there to help you balance the quality of the preview with the total file size.

If you find that your documents are getting really large, you may need to split your document, so that you don’t end up with such large file sizes that saving and opening take a really long time. The easiest way to do this is to find a natural break between parts of your site, maybe if you have organized your page URLs using subdirectories, like “products/widgets” and “products/salad_tongs”, you can duplicate your document, then delete all the parts that aren’t widgets. When you do this, Freeway will prompt you, something to the effect of “you are removing pages that are linked to other pages; do you want to delete the references, or replace them with manual links?” If you choose manual links, the site will continue to work, as long as you publish all of the separate documents into the same site folder.

Walter

On Apr 28, 2019, at 12:31 AM, Paul Scott <[email protected]> wrote:

Hello Walter. Many thanks for persevering with me on this problem!

I don’t understand the term ‘that image’ in your last post, and with the Ripon files, there are none which are missing. Nevertheless, in the program I deleted the title photo and replaced it – it had to resize, so I thought that was encouraging. Then I clicked Publish, resampled and saved. The file came down from 1.56 GB to 1.54 GB!

So perhaps I’ll try this procedure with several other photos and see what happens!

Paul

Freeway user since 1997

http://www.walterdavisstudio.com

grantsymon

28 Apr 2019, 4:12 pm

Paul, I’d say that your images are too large. I downloaded a couple and one was almost 7000 pixels across. The largest I use personally is 2500 max width. I would resize your jpegs, from the originals, using jpeg 60% or 70% quality setting.

I have many hundreds of jpegs on my site, but they are handled in image galleries, not directly on the page in FW … so my FW doc is 28Mb.

I also notice that there are quite a lot of artefacts in your images, especially noticeable in the skies … are these jpegs that have been re-compressed more than once?

I also notice, that one image is over 30 megapixels, whereas your camera produces a 24megapixel file. Are you actually upsampling some images??

Grant

Paul Scott

28 Apr 2019, 10:29 pm

Walter and Grant, thank you both so much for taking time on this.

Thoughts in order …

W1. It is obviously the proxies that are giving trouble here. Are they accessible (to me?!)

W2. I notice my image reduction control is on 75%. My images are of the order of 1 MB. Perhaps reducing the control to 50% might help?

W3. I understand about splitting the document, and can do that if necessary.

G1. Most of my images are around 1 MB. I have included some larger ZOOM images so that viewers can examine (cathedral) window details, for example.

G2. I don’t understand ‘artefacts’. For some images I replace a cloudy sky with a clear sky …

G3. I have no idea about the 30 MB image!! Which one is it?

My basic problem is that I have been producing FW cathedral sites for years without (much!) problem. Many of these have been produced with Exhibio. These latest sites have been produced directly, constructed with BackDraft. Same sized images. Now suddenly I am getting these enormous FW files. Is the new format handling the files differently?

I’m still suspicious of those very large ‘Original Photo Files’. In the case of Ripon even though this folder has been deleted, perhaps the contents are still stored in the ‘proxies’?

The large Ripon site is OK - and uploaded. I started a site for Wells Cathedral which is even larger and has become impossible. I plan to try another cathedral, and will dispense with any large original files before I start, and see if that makes a difference.

I am still open to any helpful insights! With thanks again,

Paul

Adelaide, Australia

Paul Scott

29 Apr 2019, 6:25 am

Here is a new cathedral website:

http://paulscottinfo.ipage.com/cathedrals/bunbury/stpatricks/

It is a smaller site than Ripon, but carries the same format and parameters. Constructed without any ‘extra’ folders, and a very reasonably sized 33.3 MB Freeway file!

So I’ll leave Ripon as is, and do Wells all over again. It appears to have been a glitsch with a slightly unclear cause, but one which can be avoided in the future.

Many thanks again for your efforts.

Paul

Adelaide, Australia

Paul Scott

29 Apr 2019, 9:41 am

Grant, can I ask about your image galleries, and how they work?

‘I have many hundreds of jpegs on my site, but they are handled in image galleries, not directly on the page in FW … so my FW doc is 28Mb.’

Adelaide, Australia

grantsymon

29 Apr 2019, 5:15 pm

Paul,

Pixels … it’s all about pixels (square dots). A computer monitor has a specific number of pixels (physically) and even although you can ‘fudge’ the monitor resolution in System Preferences … this doesn’t actually change the number of pixels your monitor has.

The only thing that matters for viewing an image on a computer monitor, is the pixel dimensions. DPI is irrelevant, as are any dimensions in inches or centimetres. Only pixels count.

So what you want to aim for with the images on your website, is the optimal image size … in pixels … to suit the largest number of visitors.

When you view a Responsive site, the computer that is being used to view the site, is resizing the images, ‘on the fly’ in order to fit them into the available space, so you want to aim for the largest monitor dimensions you decide is reasonable, because quality will be much better when an image is resized smaller, than when it is resized larger. This is because making an image smaller means throwing away available pixels, whilst making it larger means ‘inventing’ pixels, that do not actually exist in the image.

On your site, I noticed that the image dimensions in pixels was unnecessarily large for the 3 or 4 images I looked at. For example, 003NNaveandWTowers.jpg has pixel dimensions of 6157 × 5021. This makes it a 31 megapixel image (multiply the width x height = 31 million pixels … or 31megapixels). So this is important … the image is not 30Mb, it is 30megapixels. The byte size can vary widely, dependant on the format used for an image of fixed pixel dimensions. For example, a jpeg is much smaller in bytes, than a Tiff. But a Tiff is of maximum quality, whereas a jpeg ‘throws away’ quality to achieve a smaller byte size.

Your website, viewed on my 2560x1440 monitor, looks like this:

http://www.grantsymon.com/Grabs/PaulScottSite.jpg

I’d estimate that your page width in FW, or the box containing the images, is ~800 pixels wide. So even on a much wider monitor, the images remain at around 800 pixels wide. So your 6157 wide image, is being down-sampled by a viewer’s computer. So you are actually only using about 13% of the image’s available pixel dimensions. If you resize it down to 800 pixels, it goes from 1.1Mb down to 220K. Just 20% of the size (in bytes). This means much faster loading and thus a much faster website.

So you can make your site faster, by optimizing your images to their ideal dimensions. Personally, I generally make my images either 2000 or 2500 pixels wide, depending on the site … but images are my business, so I want them to be large to show them in their best light. For you to do something similar and for them to actually be viewable at these dimensions, you’d need to change your page width in FW, to allow them to be displayed accordingly. However … you may find 2500px to be unusably large, or unweildy, with the images always being full-browser-width. So you’d need to experiment a bit and see what suits you best. If you turn on the Developer Menu in Safari (via Safari’s Preferences / Advanced Tab) you can use the Responsive Design Mode, to get an idea of how your site will be viewed on various monitors/screens and you can reach a pretty good decision in this way.

Regarding the blue skies. It seems that you’ve used a sky, which is already a jpeg, of probably smaller pixel dimensions that the main image and which, when you save your composite as a new jpeg, is once again compressed (pixels thrown away) and you end up with a Georges Seurat pointillism sky. Perhaps it doesn’t matter to you … I’m just pointing it out. This is how it looks at 100% on my Mac.

(NB!! Anything that isn’t at 100% is either being down-sampled … or … up-sampled ‘on the fly’ by your computer. 100% means that each and every pixel in the image, is being viewed as a single pixel on the monitor. So the image is displayed exactly as it exists, with no ‘on the fly’ fudging of any sort.)

http://www.grantsymon.com/Grabs/PaulScottSite-2.jpg

For my own galleries, I use Juicebox Pro for some and Exhibeo Thumblie for others. Thumblie would work okay for your site I think. The crux to making the site being manageable (your original quesiton) is having the images as ‘passthroughs’ which means that FW will not resize them in any way … they will be exactly as you have saved them, with all exif intact etc. and they will not be a part of your FW document. FW will upload them to the Resources folder (which is a bit of an ugly way of handing them … but hey ho … perhaps FW8 will do something more elegant with them). The result of this approach, is that your FW file size remains small and manageable.

Ooof! :) :)

Grant

grantsymon

29 Apr 2019, 5:22 pm

I should add, that if you decide to use Thumblie, you need to set the Overflow in the Inspector to ‘Visible’ or it will not fit correctly when it is viewed on the smallest screens (portable phones) … at least … it doesn’t for me, but I’m certainly no expert!

Grant

waltd

29 Apr 2019, 10:05 pm

Grant — this is a very cogent and well written explanation. I just want to add one more thing, which ties directly into your point here:

On Apr 29, 2019, at 1:15 PM, grantsymon <[email protected]> wrote:

On your site, I noticed that the image dimensions in pixels was unnecessarily large for the 3 or 4 images I looked at. For example, 003NNaveandWTowers.jpg has pixel dimensions of 6157 × 5021. This makes it a 31 megapixel image (multiply the width x height = 31 million pixels … or 31megapixels). So this is important … the image is not 30Mb, it is 30megapixels. The byte size can vary widely, dependant on the format used for an image of fixed pixel dimensions. For example, a jpeg is much smaller in bytes, than a Tiff. But a Tiff is of maximum quality, whereas a jpeg ‘throws away’ quality to achieve a smaller byte size.

Regardless how the image is saved on disk (in a compressed format like JPEG or TIFF, or in an uncompressed format like PNG-24 or PSD), in order to display it on screen, your computer must decompress that image to its full size in memory. So your 31 Megapixel image (in RGB) will be 88 MB in memory. Modern operating systems and devices can handle this, but older (in Internet years) devices, or a wide swath of Android devices, will just die horribly when tasked like that.

Walter

Freeway user since 1997

http://www.walterdavisstudio.com

Paul Scott

1 May 2019, 9:37 am

Hi Grant and Walter. I wrote a long post a few days ago which didn’t appear on here for some reason. Using Grant’s suggestions I have now prepared

http://paulscottinfo.ipage.com/england/cathedrals/durham/

and am delighted with it. It has a small F/W file and will fill Grant’s large screen!

Thank you both so much,

Paul

Adelaide, Australia

grantsymon

1 May 2019, 9:48 am

On 29 Apr 2019, 10:05 pm, waltd wrote:

in order to display it on screen, your computer must decompress that image to its full size in memory.

Very good point Walter.

Grant

Back to Top

grantsymon

1 May 2019, 9:54 am

On 1 May 2019, 9:37 am, Paul Scott wrote:

Hi Grant and Walter. I wrote a long post a few days ago which didn’t appear on here for some reason. Using Grant’s suggestions I have now prepared

http://paulscottinfo.ipage.com/england/cathedrals/durham/

and am delighted with it. It has a small F/W file and will fill Grant’s large screen!

Thank you both so much,

Paul

Much better Paul!

You might still want to spend some time optimising your images, as suggested, from an aesthetic point of view … but they fill the screen now. :)

Ah yes … the disappearing long post problem. I’ve been bitten a couple of times by this. Effectively, you’ve been logged out, because you’ve taken too long to write your novel and hence it disappears into the ether. Solution: Always Cmd-A, Cmd-C your text before clicking the Send button. Reload the page after a minute or so and if your post hasn’t appeared, then fear not … you still have it on your Clipboard and can paste it in once again and Send again.

Grant