Creating the safest electronic family album with which program?

Discussion in 'Digital Cameras' started by Freddo, Oct 27, 2005.

  1. Freddo

    Freddo Guest

    Maybe someone here would know or maybe suggest where I can ask this

    Would it be best to show photos and captions in a MS Word document and
    archive the family album this way for future generations to easily access?

    Advantages I see -
    Can be easily printed as a paper copy of the album,
    Can be password protected against accidental alteration,

    Disadvantages -
    Word document file size will be big

    So, MS Word or some other program?
    Freddo, Oct 27, 2005
    1. Advertisements

  2. Freddo

    Paul Allen Guest

    Don't use Word, or any other proprietary format. There's no way to
    know you'll be able to run the program that created the format in
    50 or 150 years. You don't need to worry about password protection,
    since you'll be archiving on read-only optical media, right?

    For your simple requirements, I'd put caption text in files with
    the same basename as the image they go with and a .txt extension,
    organise them in directories as seems to make sense to you, and
    burn the whole mess to a DVD. A simple perl script can then render
    the result as HTML, or as paper, or on the cranial implant display
    of the 23rd century.

    Note that you are getting into the digital archiving business.
    That means keeping multiple copies of the archive in geographicaly
    diverse locations, rotating the archive forward onto new media and
    new technologies on a regular schedule, making sure that future
    generations care enough to maintain the archive, etc.

    Paul Allen
    Paul Allen, Oct 27, 2005
    1. Advertisements

  3. Freddo

    Freddo Guest

    Appreciate your answers.

    R.J. I backup files on 3 HDs at different locations. I'm thinking of an
    album on computer but no-one has suggested Powerpoint which can be seen on
    TV too.

    I hear what you guys say about avoiding proprietary formats which I guess
    includes Powerpoint or even PDF. You provided some valid and interesting
    points, just great.

    Paul, yes, a big mess (lol) is what I don't want. Very clever idea about
    the caption storage and a script editor for an album display and cranial
    implants, wow! What if a photo name should change and not the associated txt
    file? I'm not sure that future generations would understand 'script editor'
    nor would willingly maintain txt files.

    Yes, finalized data DVDs (version dated) can be given to family members to
    help secure longevity. Naturally I will continue to keep the album and image
    files on computer for any future alterations.

    HTML then. Can be viewed from a web site too! Someone in another group
    said ACDSee has HTML export which I have yet to check. Importantly, the
    album needs to display text other than captions, get my drift.
    Freddo, Oct 28, 2005
  4. Freddo

    Paul Allen Guest

    Ummm... Powerpoint has the same problem as Word. It's a complex and
    closed format that you may not be able to read in 20 years. As far as I
    know, it doesn't know anything about TV output. If your video card has
    a TV output you can show whatever you want on a TV.
    PDF's an interesting case. I'm told it is an open format. It also is
    highly complex and changes over time, so long-term compatibility might
    still be an issue. It does allow for very nice presentation, however.
    Actually, all Humans are programmers but most don't realize it. That's
    why my software presents a graphical point-and-click interface. What I
    had in mind with the text files notion was to preserve the important
    stuff (images, information about them, and about relationships between
    them) while giving future generations the flexibility to adjust the
    presentation to their liking. If you lock things up inside Word or PDF,
    how easy will it be for your great-great-great grandchild to do data
    mining on your archive?

    One solution to the "image gets renamed" problem is to store all of
    the metadata inside the image file itself. It turns out that the JPEG
    format is remarkably extensible that way. My software doesn't do that
    yet. It squirrels imported images away in its own private stash that's
    somewhat awkward for users to stumble over. If I change the name of
    an image inside the stash, the database can no longer find it.
    Yup. My first efforts at "presentation" were hand-crafted HTML. That
    gave me complete creative control, but was way too labor-intensive. The
    current scheme auto-generates HTML that presents a "gallery" containing
    one or more "rooms". The gallery's lobby, each room, and each image
    have their own chunk of text in the database. When you look at an image
    or a room in the GUI, you see the associated text and can change it.
    When you push the "export as HTML" button, you get the images and the
    text all wrapped up for presentation in a browser. And if some family
    member decides that the 2005 family picnic should be organized by
    "shots of ice cream making" and "shots on the beach" rather than by
    "shots of the elder generation" and "shots of kids", they can just do
    it with a few clicks.

    Rembember, HTML, Powerpoint, and PDF are presentation formats. If you
    archive your images unencumbered by presentation, or at least in
    parallel with the presentation of your choice, future generations will
    be more likely to benefit from your work.

    Paul Allen
    Paul Allen, Oct 28, 2005
  5. Yes, I'd agree with using HTML, particularly because (as already
    mentioned) you still have the images separately if you have trouble
    reading the HTML itself in the future.

    One caveat though: some HTML-generating tools (and not only those from
    Microsoft) produce absolutely terrible HTML: bloated, invalid syntax,
    only works in the current version of Internet Explorer (and not always
    then). It's a good idea to check the HTML with a validator such as or and
    try to get it right.

    Having valid syntax doesn't guarantee longevity but it improves your
    chances. It also gives you a better chance that it can in the (far)
    future be simply converted to whatever HTML-like syntax is then in use.
    Stephen Poley, Oct 28, 2005
  6. Freddo

    HvdV Guest

    Agreed. If PDF appeals to you for reasons of convenience you might consider
    Postscript too. AFAIK images in PS files are stored base64 encoded without
    lossy compression while the surrounding ascii based postscript 'program' can
    remain fairly simple. Still, as the most basic but not-too-simple storage
    format I'd vote for Tiff with lossless compression: there are very good open
    source Tiff readers, e.g. libtiff, which guarantee that Tiffs are readable
    for a *long* time. But even without such a library (say in AD 2500) one
    doesn't need a lot of programming experience to write a Tiff reader. A JPG
    decoder might be more tricky..
    BTW, one can easily store text in the Tiff description tag.

    For long term storage I'd say avoid *any* kind of proprietary format or
    proprietary database, but also anything complex, even if it is open.

    -- Hans
    HvdV, Oct 28, 2005
  7. Freddo

    Freddo Guest

    Thanks Paul .. metadata inside the image file itself and auto generated HTML
    at any time is most interesting and makes heaps of sense. But how would you
    add text to the auto generated HTML that is not associated with a photo when
    you auto generate? Does the auto generated HTML create photos of the size
    you want or in the place you want? How do I try it, with a simple perl
    script thing?

    Thanks Hans, bitmap is ok would you say? No-one mentions Bitmap to store

    Thanks Stephen about an HTML validator, essential I think.
    Freddo, Oct 29, 2005
  8. Freddo

    Paul Allen Guest

    Metadata inside the image file is interesting. I think I'll keep the
    metadata in my database for performance, but replicate it in the JPEG
    EXIF structure for fault-tolerance.

    A script that was generating HTML could simply ask the user if he wanted
    to add any text that was not already in the metadata associated with an
    image. In the context of perl and Tk, you would pop up a Toplevel
    window containing a prompt, a scrolled Text widget for input, and a
    couple buttons with labels like "Doit" and "Skip". It seems to me that
    the text should be captured in the database already, so the HTML
    generation step can proceed automatically, but perhaps that's just me.

    The autogenerated HTML does exactly what you want, by definition. My
    script generates HTML for a new gallery in a new directory that it
    creates in my web staging area. It creates copies of the images
    constrained to 400x400 and 800x800 bounding boxes, as well as native-
    resolution. The page for each room in the gallery contains the room's
    descriptive text followed by <img> tags pointing to the 400x400
    versions. Links to the 800x800 and native-resolution versions are
    to the right of the images. Below each image is the descriptive text
    for that image. At the bottom of each page are navigation links to
    other rooms or back to the lobby. I use the same staging area for all
    HTML output because that simplifies transferring the current state of
    the staging area to a web server. Lately, that means burning the
    staging directory to a DVD and slipping it in the drive on my web

    How you try it depends on your familiarity with perl or some other
    scripting language. Visual Basic might be more natural on a Windows
    machine. The basic concept is that you loop over your images, printing
    HTML to an output file. A really simple script to wrap HTML and some
    text around an image could look like this:

    print "<html>\n";
    print " <head>\n <title>My HTML Page</title>\n </head>\n";
    print " <body>\n";
    print " <p>This is an image</p>\n";
    print " <img src=\"p7230067.jpg\">\n";
    print " </body>\n";
    print "</html>\n";

    As I said in another post, I think all Humans are programmers, but
    most don't realize it. We operate VCR's, drive cars, modify recipes,
    etc. Telling a computer what to do is just more layers on top of
    the way we already think. To get started with perl on Windows you
    need ActiveState Perl and an introductory book like "Learning Perl",
    by Randal Schwartz. Later on, "Programming Perl" (Wall), and
    "Mastering Perl/Tk" (Lidie and Walsh) might be useful, as would
    "HTML & XHTML, The Definitive Guide" (Musciano & Kennedy). I'm
    sure there are lots of reference works on VB as well.
    Looking to the future, I'd be generating XHTML and using an XHTML
    validator. That means you've got well-formed XML that can be
    parsed by whatever comes down the pike long after HTML is dead
    and gone.

    Paul Allen
    Paul Allen, Oct 29, 2005
  9. Freddo

    223rem Guest

    Use the simplest public domain image format possible -- ppm for example.

    Use plain text for captions.
    223rem, Oct 29, 2005
  10. Freddo

    HvdV Guest

    IIRC microsoft .bmp files are limited to max 8-bit RGB colors, maybe not
    ideal. As another poster mentions, ppm (Portable Pixel Map), is another good
    alternative. What's nice is that the header is plain ascii, the image data
    can be in ascii too. Supports 16 bits per color, no dedicated space for
    comments but you can insert comment lines in the header by preceding them
    with a '#'. Simple! See for more
    and for a C-library.

    -- Hans
    HvdV, Nov 1, 2005
  11. Freddo

    Freddo Guest

    Thanks Hans

    Freddo, Nov 1, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.