Many people have experienced problems when uploading media objects, resulting in an error message like:

Thumbnail ‘media/thumbs/wont_upload.jpg’ could not be generated automatically.

As said in the FAQ that this is almost always due to excessively large images, or not enough PHP memory. Then users have commented that sometimes one file, say 850KB in size WILL upload, but another, slightly smaller (say 700KB) will not. Here I would like to explain why this happens.

The reason for the confusion is that the size of the file that matters is that of the file BEFORE it was compressed (usually as a jpeg formatted image), NOT the size of the file as stored. This is because, in order to be able to create a reasonable quality thumbnail copy PHP first needs to uncompress the uploaded image to its original size, storing that full sized file in internal server memory, before it can then reduce it to the much smaller thumbnail size.

Because images can be compressed to greater or lesser degrees, an image stored as 700KB can easily be larger than one stored as 850KB. Most scanners and digital cameras automatically compress files when they create them, so “compressing” does not mean you or your relatives need to have done anything unusual.

If you are having problems, then this is how you can approximately calculate the REAL size of your images:

First identify the pixel dimensions of the image. That can be done in many ways, and is (or can) often be displayed in a file system on your PC, such as this from a Windows 7 system:

Note that the dimensions of the larger (875 KB) file are actually far less than the smaller (718KB) file, indicating very different levels of compression.

Next calculate the total pixels (px) per file:

will_upload.jpg = 863 x 1176 = 1,014,888 px

wont_upload.jpg = 3436 x 2410 = 8,280,760 px

To convert these to file sizes you neeed to know the “pixel depth” or number of colours used when this image was created. This is usually stored with the image information, and will need some form of image editing software to show it. In these examples, both are “RGB” (256 colours) or 8 bits per channel. The table below gives some alternative types. The depth (8 in this case) divided by 8 will give the number of “bytes” per pixel:

8 / 8 = 1 byte per pixel

(24 / 8 = 3 bytes per pixel, etc)

Therefore, for these images:

will_upload.jpg = 1,014,888 x 1 = 1,014,888 bytes

wont_upload.jpg = 8,280,760 x 1 = 8,280,760 bytes

There are 1,024 bytes in a KB, so the true ORIGINAL size of each image was:

will_upload.jpg = 1,014,888 / 1,024 = 991 KB (just less than 1 MB)

wont_upload.jpg = 8,280,760 / 1,024 = 8,087 KB (just over 8 MB)

Hopefully now it is clear why the “larger” image uploaded successfully, whilst the “smaller” did not. The smaller file was actually 8 X larger !

Here is a table of some common image sizes and their equivalent uncompressed file sizes for different types:

When you are considering uploading files to webtrees it is worth thinking about all of the following points:

• webtrees is a family history program, NOT a photo gallery. It does not need archival quality images, and will not work well if they are used.
• Not all your users will have ultra-high speed internet connections. So displaying a huge archival quality image could delay a page from displaying for several minutes in some cases.
• Reduce the resolution of images to around 72 px/inch. This is generally adequate for website display.
• Keep image dimension within what is reasonable for most computer screens. Something no wider than 1200 px is probably as big as you need.
• Convert images to black and white (1 bit) where that is appropriate. Many old documents were produced only in black and white, so high definition colour is pointless.
• Use image software to crop images to only use the parts you need. It makes the picture look better, as well as reducing its storage requirements.

« חזרה אל מאגר המידע