Saving directory trees in Gtkam

[andrzej zaborowski]

Hi there,
I thought it would be useful to have an option to download a whole
directory tree in Gtkam with a single command, I have also seen other
people complain about this on the web. I'm attaching a simple patch
that adds such option to the tree view's context menu. I hope you find
a useful thing to have. (I'm only not too confident about my use of
GTK)
Greetings
--
balrog 2oo5

[Marcus Meissner-4]

On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote:
> Hi there,
> I thought it would be useful to have an option to download a whole
> directory tree in Gtkam with a single command, I have also seen other
> people complain about this on the web. I'm attaching a simple patch
> that adds such option to the tree view's context menu. I hope you find
> a useful thing to have. (I'm only not too confident about my use of
> GTK)
> Greetings


Hmm.

The patch works. However ...

Do we really want to recreate the directory tree on the camera, or
download all files from the into the same directory?

Ciao, Marcus


-------------------------------------------------------
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

[Theodore Kilgore]

On Wed, 7 Sep 2005 [hidden email] wrote:

> Send Gphoto-devel mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/gphoto-devel
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gphoto-devel digest..."
>
>
> Today's Topics:
>
>   1. Re: Saving directory trees in Gtkam (Marcus Meissner)
>
> --__--__--
>
> Message: 1
> Date: Wed, 7 Sep 2005 21:39:46 +0200
> From: Marcus Meissner <[hidden email]>
> To: andrzej zaborowski <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [gphoto-devel] Saving directory trees in Gtkam
>
> On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote:
>> Hi there,
>> I thought it would be useful to have an option to download a whole
>> directory tree in Gtkam with a single command, I have also seen other
>> people complain about this on the web. I'm attaching a simple patch
>> that adds such option to the tree view's context menu. I hope you find
>> a useful thing to have. (I'm only not too confident about my use of
>> GTK)
>> Greetings
>
>
> Hmm.
>
> The patch works. However ...
>
> Do we really want to recreate the directory tree on the camera, or
> download all files from the into the same directory?
>
> Ciao, Marcus
>

Marcus,

I have not tried the patch, but I would say that it depends on the camera.
For example, the sq905 cameras could conceivably be helped by such an
arrangement. Here is the situation:

1. There are no actual directories on the camera, and no FAT. No names,
either. There is only something which might be considered as a sequential
list, with location of entries in it determined only by line number.

2. For each photo on the camera, one entry equals one frame, _except_ if
the entry is for a clip (which can be done on a certain camera setting by
holding down the shutter button, causing the camera to shoot frames until
either the button is let go or the camera is full). If a clip has been
taken, then that clip gets one entry in the list, along with an indication
of how many frames are in the clip.

3. The driver has to make sense of (1) and (2), in view of the fact that
the camera has no actual file system on it, so a file system is faked. It
is considered that, in "/" on the camera, each single photo is a file, and
each clip is a subdirectory, containing the individual frames in that
clip, as files in the subdirectory.

Clips of course could be handled differently; the OEM driver makes each
clip into an AVI file. But the way described seemed like at least one good
way to do it. So, the point is, I think it would be very nice to be able
to preserve this "subdirectory" structure when downloading photos. I tried
to do this at the driver level quite some time ago, and found out that I
could not because such a thing was not built into the infrastructure.

However, I am not aware of any other cameras for which any similar
situation applies. Come to think of it, I guess it could apply to a camera
which has an internal memory and also a memory card. In that case if there
were name collision (for example, IMG001.JPG is found both in the internal
memory and also on the card, which the camera thinks is a separate
location) then one might find such a feature useful there. But if the
camera numbers the photos sequentially regardless of the physical location
on the camera, there would be no need for this feature.

I suppose that I should try the patch. I did see the previous letter
announcing it, but IIRC the patch was munged for me by some funny way of
attaching it. Namely, I did not see anything in the "Attachments:" field,
but instead received a long message full of funny characters, apparently
containing the tarball as part of the body of the message, and I did not
know exactly how to deal with that. So, if someone would send it to me in
such a way that I can deal with it, I would be appreciative.

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

[andrzej zaborowski]

On 07/09/05, Marcus Meissner <[hidden email]> wrote:

> On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote:
> > Hi there,
> > I thought it would be useful to have an option to download a whole
> > directory tree in Gtkam with a single command, I have also seen other
> > people complain about this on the web. I'm attaching a simple patch
> > that adds such option to the tree view's context menu. I hope you find
> > a useful thing to have. (I'm only not too confident about my use of
> > GTK)
> > Greetings
>
>
> Hmm.
>
> The patch works. However ...
>
> Do we really want to recreate the directory tree on the camera, or
> download all files from the into the same directory?
>
> Ciao, Marcus
>

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, using the camera's interface or an external card reader. Also
having a copy of the whole directory structure it will later be
possible to restore the state of the camera seen from gtkam.
A potential advantage of downloading into a tree instead of the same
directory could be keeping the order of filenames assigned by camera.
Having them all in one directory could in some cases mix them up.
Beside this, both options can be added, I just found this one useful
and as my previous camera supported "usb-storage", I got used to
downloading the whole content of the card at once, and then moving the
the files between directories on the hard disk, which was much faster
than that camara's memory.
Greetings
--
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

[Hub Figuière-2]

andrzej zaborowski wrote:

> 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, using the camera's interface or an external card reader. Also
> having a copy of the whole directory structure it will later be
> possible to restore the state of the camera seen from gtkam.

That is very unlikely on the camera, because it is not conformant with
DCF filesystem standard.
As for already having done that using an external card reader then he
does not need it.


> A potential advantage of downloading into a tree instead of the same
> directory could be keeping the order of filenames assigned by camera.

The only issue I see is conflicting file names.

> Having them all in one directory could in some cases mix them up.

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

> Beside this, both options can be added, I just found this one useful
> and as my previous camera supported "usb-storage", I got used to
> downloading the whole content of the card at once, and then moving the
> the files between directories on the hard disk, which was much faster
> than that camara's memory.

I'd love to be able to automatically download them and sort them in
folder timestamped using EXIF....
I'll do that later, eventually

gtkam needs a lot of love.


Hub



-------------------------------------------------------
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

[patman (Bugzilla)]

On Thu, Sep 08, 2005 at 08:05:52PM -0400, Hubert Figuiere wrote:
>
> gtkam needs a lot of love.
>

:)

I don't know if any distros are including it anymore ... at least it is
not in fedora core 4. Seems kcamera (or ?) is expected to be use instead
with FC.

This means fewer users and fewer that will even know about trying to
improve it.

AFAIK there is no gui capture/control with the alternates, no ultra-cool
LCD like view you get with gtkam.

-- Patrick Mansfield


-------------------------------------------------------
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

[Hub Figuière-2]

[hidden email] wrote:

> I don't know if any distros are including it anymore ... at least it is
> not in fedora core 4. Seems kcamera (or ?) is expected to be use instead
> with FC.

Not even in extras?

But yes, Fedora seems to remove lot of things. For example Gnumeric and
AbiWord has been pushed to Extras, and I have ranted about that already.

gtkam is in universe in Ubuntu.

Hub


-------------------------------------------------------
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

[patman (Bugzilla)]

On Sat, Sep 10, 2005 at 04:33:44AM -0400, Hubert Figuiere wrote:
> [hidden email] wrote:
>
> > I don't know if any distros are including it anymore ... at least it is
> > not in fedora core 4. Seems kcamera (or ?) is expected to be use instead
> > with FC.
>
> Not even in extras?

Nope.

I installed it from an rpm at http://repo.nrpms.net, though I am using one
built from CVS (and went ahead and just removed my rpm one).

It is/was not in any of the repos contained in this rpm (an rpm that just
installs repos in /etc/yum.repos): http://www.fedorafaq.org/yum

> But yes, Fedora seems to remove lot of things. For example Gnumeric and
> AbiWord has been pushed to Extras, and I have ranted about that already.

I use both of those too. I still have oo installed (need ooimpress for
ppt) but oo is a pig to start and a large download for updates (~100MB,
and they seem to update about twice a month).

-- Patrick Mansfield


-------------------------------------------------------
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

[Theodore Kilgore]

Patrick Mansfield wrote:

>On Thu, Sep 08, 2005 at 08:05:52PM -0400, Hubert Figuiere wrote:
>>
>> gtkam needs a lot of love.
>>

>:)

>I don't know if any distros are including it anymore ... at least it is
>not in fedora core 4. Seems kcamera (or ?) is expected to be use instead
>with FC.

I do not keep up with these matters in any detail, but I would think this
is regrettable.

>This means fewer users and fewer that will even know about trying to
>improve it.

A problem, if true.

>AFAIK there is no gui capture/control with the alternates, no ultra-cool
>LCD like view you get with gtkam.

>-- Patrick Mansfield

Very true. And let me add to this:


Gtkam seems to me to work much more reliably than any of the other setups
which are supposed to do the same thing. I sometimes have problems with
it, but this is probably due to the fact that I deal with weird, el cheapo
cameras. I have had much more trouble with all of the alternatives to
gtkam that I know of. Some of them refuse to display thumbnails (perhaps
because those programs _assume_ that the camera is actually providing
thumbnails, or something like that?). Some of them will jam up when trying
to handle a difficult camera like an sq905 running in mixed single mode
and clip mode and will then munge the data in half of the frames. In
contrast, gtkam can handle the problems at least 98% of the time in those
special situations which probably do not come up with better-behaved
cameras. And if occasionally there is a glitch, then it will work better
if one tries again.

Thus, in the README and in the "manual" section for the cameras which I
support, I strongly recommend gtkam as a GUI frontend for the camera.

Perhaps this is a good occasion to let the gtkam developers know that
there is someone here who really does appreciate their work. Based upon
the good old empirical test, they have done a lot of things right.

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

[Till Kamppeter]

[hidden email] wrote:

>
> Patrick Mansfield wrote:
>
>> On Thu, Sep 08, 2005 at 08:05:52PM -0400, Hubert Figuiere wrote:
>>
>>>
>>> gtkam needs a lot of love.
>>>
>
>> :)
>
>
>> I don't know if any distros are including it anymore ... at least it is
>> not in fedora core 4. Seems kcamera (or ?) is expected to be use instead
>> with FC.
>
>
> I do not keep up with these matters in any detail, but I would think
> this is regrettable.
>
>> This means fewer users and fewer that will even know about trying to
>> improve it.
>
>
> A problem, if true.
>
>> AFAIK there is no gui capture/control with the alternates, no ultra-cool
>> LCD like view you get with gtkam.
>
>
>> -- Patrick Mansfield
>
>
> Very true. And let me add to this:
>
>
> Gtkam seems to me to work much more reliably than any of the other
> setups which are supposed to do the same thing. I sometimes have
> problems with it, but this is probably due to the fact that I deal with
> weird, el cheapo cameras. I have had much more trouble with all of the
> alternatives to gtkam that I know of. Some of them refuse to display
> thumbnails (perhaps because those programs _assume_ that the camera is
> actually providing thumbnails, or something like that?). Some of them
> will jam up when trying to handle a difficult camera like an sq905
> running in mixed single mode and clip mode and will then munge the data
> in half of the frames. In contrast, gtkam can handle the problems at
> least 98% of the time in those special situations which probably do not
> come up with better-behaved cameras. And if occasionally there is a
> glitch, then it will work better if one tries again.
>
> Thus, in the README and in the "manual" section for the cameras which I
> support, I strongly recommend gtkam as a GUI frontend for the camera.
>
> Perhaps this is a good occasion to let the gtkam developers know that
> there is someone here who really does appreciate their work. Based upon
> the good old empirical test, they have done a lot of things right.

Good point.

I have no cheapo cameras for testing (I have "only" the Canon EOS 350D,
the Fuji F10, and the Minolta DiMAGE F200, so only the 350D works with
GTKam), but I will keep GTKam in Mandriva Linux, as there are probably
enough people under our customers who have a cheap digital camera
without exchangeable memory cards.

    Till


-------------------------------------------------------
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

[Theodore Kilgore]

On Sat, 10 Sep 2005, Till Kamppeter wrote:

> I have no cheapo cameras for testing (I have "only" the Canon EOS 350D, the
> Fuji F10, and the Minolta DiMAGE F200, so only the 350D works with GTKam),
> but I will keep GTKam in Mandriva Linux, as there are probably enough people
> under our customers who have a cheap digital camera without exchangeable
> memory cards.
>
>   Till
>

Thanks. And there do exist people who use them, for various reasons. For
example, about a week ago there was a talk-back to an article featured on
Linux Today, and somebody brought up the usual whine about lack of
hardware support for Linux. He got a response from someone else, who
averred that the situation is just not so bad as it gets painted and
itemized several unusual items of hardware which seem to be well
supported. The first example was a Kidz Cam, bought for his daughter
(something like 6 to 8 years old). IIRC they had some trouble with the
camera in Windows, and they tried it in Linux. So the daughter fires up
Linux to download the photos from it. Made me really proud. The Kidz Cam
is one of those cameras you could buy last Christmas at WalMart for less
than $20, and it has in it an sq905.

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

[Hub Figuière-2]

> I have no cheapo cameras for testing (I have "only" the Canon EOS 350D,
> the Fuji F10, and the Minolta DiMAGE F200, so only the 350D works with
> GTKam), but I will keep GTKam in Mandriva Linux, as there are probably
> enough people under our customers who have a cheap digital camera
> without exchangeable memory cards.


With current CVS the other cameras should be supported too.

As for which cameras, currently all Kodak and Canon owner need
libgphoto2. That's quite a market share.

Hub


-------------------------------------------------------
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

[Marcus Meissner-4]

On Fri, Sep 09, 2005 at 01:34:43AM +0200, andrzej zaborowski wrote:

> On 07/09/05, Marcus Meissner <[hidden email]> wrote:
> > On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote:
> > > Hi there,
> > > I thought it would be useful to have an option to download a whole
> > > directory tree in Gtkam with a single command, I have also seen other
> > > people complain about this on the web. I'm attaching a simple patch
> > > that adds such option to the tree view's context menu. I hope you find
> > > a useful thing to have. (I'm only not too confident about my use of
> > > GTK)
> > > Greetings
> >
> >
> > Hmm.
> >
> > The patch works. However ...
> >
> > Do we really want to recreate the directory tree on the camera, or
> > download all files from the into the same directory?
> >
> > Ciao, Marcus
> >
>
> 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, using the camera's interface or an external card reader. Also
> having a copy of the whole directory structure it will later be
> possible to restore the state of the camera seen from gtkam.
> A potential advantage of downloading into a tree instead of the same
> directory could be keeping the order of filenames assigned by camera.
> Having them all in one directory could in some cases mix them up.
> Beside this, both options can be added, I just found this one useful
> and as my previous camera supported "usb-storage", I got used to
> downloading the whole content of the card at once, and then moving the
> the files between directories on the hard disk, which was much faster
> than that camara's memory.

I have applied the patch as-is now.

Ciao, Marcus


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel