Re: Saving directory trees in Gtkam (hfiguiere)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Saving directory trees in Gtkam (hfiguiere)

Theodore Kilgore
Hub,

Skimming through your reply to Andrzej Zaborowski:

> Personally I think it is important to be able to recreate the state of
> the camera that you can see through gtkam on a harddisk. A user may
> have arranged the pictures inside the camera into groups using gtkam
> itself (...)


This pretty much sums up what is happening with the sq905
cameras.

>That is very unlikely on the camera, because it is not conformant with
DCF filesystem standard.

Here, my understanding is that one of our objectives is to support
whatever hardware is out there, insofar as it is possible for us to do so.
And lots of cameras do not in fact have a filesystem on them at all, only
a list of memory locations. Thus, for such cameras the "filesystem" is
added on after the fact. In such a situation, I do not understand what is
the relevance of something called "DCF filesystem standard".

Then you say:

> EXIF is your friend. I only trust that. The file time too.

and

> I'd love to be able to automatically download them and sort them in
folder timestamped using EXIF....

I can see how these remarks are pertinent to support cameras which will
provide EXIF data, timestamps, thumbnails, and all of that stuff which is
obviously very good stuff. i also strongly agree that such features need
to be supported and exploited to full potential for any camera which will
do them.

But what about those cameras which do not provide us with this, but only
take photos, keep them in volatile memory so that the user is recommended
to remove the batteries when not using the camera right now, do not have a
filesystem on the camera, no names for the photos, only a sequential list
of memory locations? For such cameras, what EXIF data do we have in mine,
and where is it supposed to come from?

Now, as I mentioned, it happens sometimes that the way the camera's
rudimentary list is constructed can require us to treat some photos
differently from others, and a convenient way to do this is to invent
"subdirectories" for the purpose of handling the photos in question
differently from others. Along these lines, I do intend to see whether or
not this patch is helpful. I think it might possibly be useful, there. I
also add that this patch would be an irrelevancy, as far as camlibs/aox,
camlibs/iclick, camlibs/mars, and camlibs/sonix are concerned, because the
problems which the patch claims to address do not come up for those other
cameras.

Theodore Kilgore


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Saving directory trees in Gtkam (hfiguiere)

andrzej zaborowski
On 09/09/05, [hidden email]
<[hidden email]> wrote:

> Hub,
>
> Skimming through your reply to Andrzej Zaborowski:
>
> > Personally I think it is important to be able to recreate the state of
> > the camera that you can see through gtkam on a harddisk. A user may
> > have arranged the pictures inside the camera into groups using gtkam
> > itself (...)
>
>
> This pretty much sums up what is happening with the sq905
> cameras.
>
> >That is very unlikely on the camera, because it is not conformant with
> DCF filesystem standard.
>
> Here, my understanding is that one of our objectives is to support
> whatever hardware is out there, insofar as it is possible for us to do so.
> And lots of cameras do not in fact have a filesystem on them at all, only
> a list of memory locations. Thus, for such cameras the "filesystem" is
> added on after the fact. In such a situation, I do not understand what is
> the relevance of something called "DCF filesystem standard".
>
> Then you say:
>
> > EXIF is your friend. I only trust that. The file time too.
>
> and
>
> > I'd love to be able to automatically download them and sort them in
> folder timestamped using EXIF....
>
> I can see how these remarks are pertinent to support cameras which will
> provide EXIF data, timestamps, thumbnails, and all of that stuff which is
> obviously very good stuff. i also strongly agree that such features need
> to be supported and exploited to full potential for any camera which will
> do them.
>
> But what about those cameras which do not provide us with this, but only
> take photos, keep them in volatile memory so that the user is recommended
> to remove the batteries when not using the camera right now, do not have a
> filesystem on the camera, no names for the photos, only a sequential list
> of memory locations? For such cameras, what EXIF data do we have in mine,
> and where is it supposed to come from?
>
> Now, as I mentioned, it happens sometimes that the way the camera's
> rudimentary list is constructed can require us to treat some photos
> differently from others, and a convenient way to do this is to invent
> "subdirectories" for the purpose of handling the photos in question
> differently from others. Along these lines, I do intend to see whether or
> not this patch is helpful. I think it might possibly be useful, there. I
> also add that this patch would be an irrelevancy, as far as camlibs/aox,
> camlibs/iclick, camlibs/mars, and camlibs/sonix are concerned, because the
> problems which the patch claims to address do not come up for those other
> cameras.
>
> Theodore Kilgore
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Gphoto-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gphoto-devel
>

It is not only this. For me a part of a well designed graphical user
interface that contains a tree view should be a way to store that tree
structure somewhere, to keep it in the computer's memory. Now, we know
that for many camera models this strange structure doesn't contain any
practical information, instead all the useful data about pictures can
be extracted from the EXIF headers, and the tree is sometimes just a
convenient way for the camera to arrange the image files in
directories without having a huge number of files in a single
directory. Nevertheless there is often more than one directory (node
of the tree) that contains pictures (leaves) and in order to save all
pictures in the tree a user needs to repeat the same action many times
(select the driectory, click "Save All", confirm) which should really
be a task of the interface. (For example my Canon camera does this, it
only writes a limited number of images into one directory, then it
make a new one).

Now, as Marcus Meissner proposed, gtkam could achieve this by saving
all pictures from the tree to a single directory, too. But then
there's no sense in having gtkam display a tree view, then it should
rather be a list view where all the pictures are together. But as
Theodore Kilgore has shown the tree's structure also carries a meaning
in some camera models. For the rest of the models the user (like
myself) might be unaware of that the directory layout isn't
significant or have made their own layout that they want to preserve.
--
balrog 2oo5


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Loading...