Re: BonoboPreview initiative - png in a control

[Charles Iliya Krempeaux <tnt linux ca>]

Hello,

On Mon, 2001-12-10 at 11:46, Joergen Scheibengruber wrote:

[...]

> There are two more disadvantages of using a thumbnail for the preview.

[...]

> What example for a mp3? Ok, that works already fine
> with nautilus, but what about movies? Wouldn't it be cool to have a
> preview of them, too? (0k, maybe that's exaggerated, but a component is
> much more flexible, if you understand what i mean, you can still have a
> thumbnail for all filetypes, where it's the best way)

We were actually discussing the thumbnailing standard and movie
thumbnails, just a little while ago on the matterial
<http://matterial.sf.net/> developers mailing list.

Our main solution is that the thumbnailing standard needs to be extended
to support a sequence of images.

Also, we discussed whether having a collection of PNG files (for a 
movie thumbnail) would be the best way to do it, since a sequence
of PNG files did NOT do an temporal compression.  We were not sure
if MNG supported anything like that, so we also considered other
formats.

Also, the question of Sound came up.  Using a collection of PNGs or
even a MNG would NOT give you any support for sound.

The exact format was left in question (in our discussion).  Do we
use a collection of PNGs, and have a separate file for sound?  Do
we use a MNG, and have a separate file for sound?  Do we use some
other format that supports both sound and graphics? Do we make up
our own format that would work with previewing better.

We came up with the following algorithm to choose what frames (of the
movie) to select for thumbnailing...

  Let's say we have a movie clip represented by the timeline below:

     [============================================================]
      0                                                          t

  Note that the timeline starts a time equal zero (at the left) and
  end with time equals "t" (at the right).

  You then could take a series of thumbmails, at the following time
  indexes:

     0, t,
           t/2, 
                t/4, 3t/4,
                           t/8, 3t/8, 5t/8, 7t/8,
                                                  ...

  And we continue that to get as fine a grain as we want.  To see
  this graphically, we have the following:

     Stage 0: Only have two thumbnails at the extremities.
     [============================================================]
      0                                                          t


     Stage 1: We add 1 extra thumbnail.
     [============================================================]
      0                            t/2                           t


     Stage 2: We add 2 extra thumbnails.
     [============================================================]
      0             t/4            t/2           3t/4            t


     Stage 3: We add 4 extra thumbnails.
     [============================================================]
      0     t/8     t/4    3t/8    t/2   5t/8    3t/4   7t/8     t

                               ... etc ...

     Stage N: We add 2^(N-1) extra thumbnails.
     [============================================================]
               Too many thumbnails here to show them :-)

                               ... etc ...

(Of course we'd come up with some reasonable measure of when to
stop following that pattern and stop making thumbnails.)

We make the requirement that we always follow the algorithm up
to "stage 1"; and thus always have at least three thumbnails:
the frame for time index 0, the frame for time index t, and
the frame for time index t/2.

For applications that want to show a single image for the preview
of the movie, t/2 should be the "dumb" choice.  This is because
0 and t will likely be garbage, and not a good representation
of the movie (for various reasons that I can get into if anyone
wants to hear it).

Also, there should be a mechanism were the user can choose what ever
frame they want (from the movie) to be the single image preview.  
(Instead of being forced to use t/2.)

By looking at the algorithm, you might see that it would be nice if
there was a video format that supported a kind of "progressive ordering"
of the frames.  Where as you read/downloaded/whatever more of the file
you got finer and finer grain (in terms of time) to the movie.  In
other words, the frames would be stored, in the file, in the order:

    This comes first: {0, t}

    Then: {t/2}

    Then: {t/4, 3t/4}

    Then: {t/8, 3t/8, 5t/8, 7t/8}

    Then: {t/16, 3t/16, 5t/16, 7t/16, 9t/16, 11t/16, 13t/16, 15t/16}

    And so on, up to the "Stage" in the algorithm that you went up
    to making thumbnails.

This is kind of like the "progressive" style of GIFs and JPEGs, but
instead of spacial, it is temporal.

Hmmm, I hope I didn't miss anything from our discussions (on the 
matterial Developers Mailing List).


See ya

     Charles Iliya Krempeaux
     tnt @ linux.ca
     ckrempea @ alumni.sfu.ca