Loading ...
Sorry, an error occurred while loading the content.

FTM and file sizes

Expand Messages
  • Merv Leeding
    Hi Nancy ... Elizabeth has already pointed out that FTM dropped the LZW compression import several versions ago, not doubt to avoid paying license fees.
    Message 1 of 1 , Jan 13, 2002
      Hi Nancy

      >I have just started using Family Tree Maker (9.0) again, for its image
      >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
      great pity.

      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
      of gray)

      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
      calculation purposes.

      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
      JPG compression.

      Hope that throws some light on your questions.

      >I really like to know what the software is doing and FTM tries to hide
      >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?

      Not the only program that hides things from you. Few match the things
      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 file
      >was 3560 kb with no images, 3543 with the tif added, 3543 with that tif
      >removed and 3541 with the jpg added.

      Elizabeth has explained that and in fairness to FTM that is characteristic
      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.

      Regards, Merv
    Your message has been successfully submitted and would be delivered to recipients shortly.