FTM and file sizes
- Hi Nancy
>I have just started using Family Tree Maker (9.0) again, for its image<snip>
>storing and chart output strengths and I am baffled by what it does with
>the imported images. When I import the above jpg into the scrapbook it
>says it will take 5595 kb uncompressed and 2098 kb at the recommended
>compression (1/8). What is going on? Also, it will not tell me how much
>the space the tif will take and it will not accept the compressed tif.
Elizabeth has already pointed out that FTM dropped the LZW compression
import several versions ago, not doubt to avoid paying license fees. A
FTM is unusual in offering a ratio for compression, most just give a
numbered scale. I haven't asked the programmers how the use the algorithm
to achieve that but presumably they adjust whatever it is you do in
creating the JPG.
I can however explain some of the other anomalies since I spent quite a bit
of time examining these issues.
The true size of an image is the number of pixels. The resolution embedded
in the file merely tells the importing program the real size of the image
that is desired. If it is 600 pixels wide and the "set" resolution is
100dpi it is six inches wide. If you change the 100 to 300 and you can do
that in an image editing program without making any difference to the
picture content the importing program will display it as 2 inches wide.
The file size is related to how those pixels are stored. In TIFF without
compression you have 3 bytes for each pixel, one each for Red, Blue and
Green. (Four if you have a CMYK file.) Each byte can be from 0 to 255
levels of colour so for the three channels you have 256 x 256 x 256 or that
well-known 16.7 million colours. Now in TIFF you not only have a file size
in bytes of three times the pixel but also have extra bytes for information
about the intended resolution and other things.
Now JPG compresses the storage, not the pixels. If you compress to 10% you
still have the same number of pixels. This is why if you convert JPG back
to TIFF you get all those pixels at three bytes each.
Now FTM probably has no idea what compression has been used in the JPG. It
works on the number of pixels which is the same as was in the TIFF file
from which the JPG was created. So if you take a 1 million pixel TIFF which
will be just over 3mb uncompressed and convert it to JPG of say 1mb, 0.5mb,
0.3mb etc FTM will still look at the number of pixels (1 million) and for
the TIFF and all those JPGs will still give you the same predicted result.
The short answer is that the file size of the JPG is irrelevant to FTM and
what it will estimate. Since re-compression of JPG by FTM can lead to some
degradation albeit small, it does make sense to give FTM the TIFF original
if you have.
Remember that FTM's estimate is never going to be exact, since it does not
look at the picture content before estimating for you. If FTM did a pre-run
beforehand it would be time-consuming. That is not just an opinion based on
how quickly that FTM does the estimate. I made many files of the same total
pixel and file size in TIFF with widely varying content, based on some
content that JPG doesn't handle well. Every time, for that same pixel
content, FTM gave the same estimate. Every time I converted to a JPG the
estimate on the JPG was exactly the same as on the TIFF from which it was
Now if you started with a very highly compressed JPG and told FTM you
wanted minimum compression then FTM might just increase the family file by
more than the prediction. In most cases the prediction is optimistic.
If you have grayscale TIF then storage is one byte per pixel. (256 shades
Now JPG can be gray (8-bit) or colour (24-bit or 16.7 million colours).
There is no 256 colour JPG. So what does FTM do when you present it with a
256 colour TIF? It goes ahead and compresses it anyhow. How can it make a
JPG format that doesn't exist elsewhere. Well it doesn't. A 256-colour TIF
is one third the size of a 16.7 million colour TIF. What FTM does is
estimate the space required by multiplying the pixels in the 256-colour
TIFF and then it treats it as a standard 16.7 million colour TIF for
Remember a 16.7 million colour file doesn't have that many colours. That is
simply the number of different colours it can represent. Clearly a 1000
pixel file can never have more than 1000 different colours, each pixel only
ever has one colour. So I suspect FTM simply looks at the colour pixels in
the 256-colour file and re-maps them to a compressed 24-bit JPG.
It is important to note that 1-bit black and white images do not exist as
JPG and FTM compresses them well. I assume FTM simply uses well-known
industry compressions (ZIP, RLE, etc) rather than attempting any sort of
Hope that throws some light on your questions.
>I really like to know what the software is doing and FTM tries to hideNot the only program that hides things from you. Few match the things
>the details to make things seem simpler, I suspect. Any ideas? Is tech
>info about how image files are handled by this program available on the
>net or in the book they try to sell you?
Microsoft get up to in their operating systems. I don't think you will find
anything on the internet. Some of us who have been beta testers for several
versions are none the wiser, hence my own experimental work.
>I tried doing a backup of a very small test database and found the fileElizabeth has explained that and in fairness to FTM that is characteristic
>was 3560 kb with no images, 3543 with the tif added, 3543 with that tif
>removed and 3541 with the jpg added.
of all databases though some are self-compacting. A long gripe among FTM
users is the continued failure to put the compaction option in a menu where
it can easily be seen.