NSLU2-Linux
view · edit · print · history

Applications.DigitalCameraBackup History

Hide minor edits - Show changes to markup

May 13, 2008, at 10:00 AM by Alex Scott --
Changed line 49 from:
  1. udevinfo -a -p /sys/class/usb_devices/usbdev1.X
to:
  1. udevinfo -a -p /sys/class/usb_devices/usbdev1.X/dev
Added lines 104-105:

May 06, 2008, at 10:00 PM by de --
Added line 191:
Added line 193:
May 06, 2008, at 09:56 PM by de -- Added an alternative udev rule and script
Changed lines 102-194 from:

--- Alex Scott

to:

--- Alex Scott

udev rule for my cardreader:

BUS=="usb", KERNEL=="sd*", SYSFS{product}=="USB Reader", NAME(all_partitions)="%k", SYMLINK+="card_cf%n", \
 RUN+="/etc/udev/scripts/cp_pictures.sh %k cf", OPTIONS+="all_partitions"
BUS=="usb", KERNEL=="sd*", SYSFS{product}=="USB Reader", NAME(all_partitions)="%k", SYMLINK+="card_mmc%n", \
 RUN+="/etc/udev/scripts/cp_pictures.sh %k mmc", OPTIONS+="all_partitions"
BUS=="usb", KERNEL=="sd*", SYSFS{product}=="USB Reader", NAME(all_partitions)="%k", SYMLINK+="card_ms%n", \
 RUN+="/etc/udev/scripts/cp_pictures.sh %k ms", OPTIONS+="all_partitions"
BUS=="usb", KERNEL=="sd*", SYSFS{product}=="USB Reader", NAME(all_partitions)="%k", SYMLINK+="card_sd%n", \
 RUN+="/etc/udev/scripts/cp_pictures.sh %k sd", OPTIONS+="all_partitions"

And the script cp_pictures.sh i use for downloading from my cardreader which holds the media of a Canon 300D:

#!/bin/bash
cf=/dev/$1
lock=$1
if [ -z $cf ]; then 
 cf="/dev/card_cf1" 
 lock="card_cf1"
fi

today='uploaded_'$(date +%F)
cfdev=/mnt/cardreader/$2
fotos=/mnt/hdd1/data/webfotos/unprocessed/$today
lockfile="/mnt/hdd1/data/webfotos/unprocessed/"$lock"_cp.lock"

ext=("*.crw" "*.thm" "*.jpg")

lockfile -r0 -30 $lockfile
if [ "$?" -ge "1" ]; then 
 exit 1
fi

mount -s -t auto $cf $cfdev
stat $cfdev/dcim/*canon &> /dev/null
if [ "$?" -ge "1" ]; then
 rm -f $lockfile
 umount $cf -lf
 exit 1
fi

/etc/nslu2/melody_disk_on.sh
/etc/nslu2/leds_vegas.sh
logger udev.info "cp_pictures.sh called with $1 and $2"
count=$(ls $cfdev/dcim/*canon/* | grep "" | wc --lines)

if [ "$count" = "0" ]; then
 umount $cf -lf
 rm -f $lockfile
 exit 1
fi

logger udev.info "cp_pictures.sh: $cf, $2, cp $count photos to $fotos"
mkdir $fotos
for e in $( echo ${ext[
} ); do
 for i in $( find $cfdev/dcim/*canon/$e ); do
  echo "copying: $i"
  file=$i
  cp -Puf $file $fotos
  if [ "$?" = "1" ]; then 
   echo "file: $i copy error"
  else
   echo "$i copied."
   rm $i
  fi
 done 

done

chmod 770 $fotos -R chown samba:sambausers $fotos -R

files=$(ls $cfdev/dcim/*canon/* | grep "" | wc --lines) if [ "$files" = "0" ]; then

 echo removing directories...
 rm -rf $cfdev/dcim/*canon
 umount $cf -lf
 rm -f $lockfile

else

 echo more files than expected, exiting.
 rm -f $lockfile
 exit 1

fi

/etc/nslu2/melody_disk_on.sh /etc/nslu2/leds_off.sh exit 0 @] It expects 2 parameters: the device and a name for a lockfile which prevents the script from being started twice. It then mounts the device, creates a folder with the actual date, copies files one by one and umounts the device. It additionallz plays a melody after successfull recognition and umount (these scripts use the leds command).

/de

May 04, 2008, at 01:41 PM by Alex Scott --
Changed lines 60-63 from:

SUBSYSTEM=="usb_device", SUBSYSTEMS=="usb", ATTRS{idProduct}=="3146", ATTRS{idVendor}=="04a9", MODE="0666", SYMLINK+="cannon_40d", RUN+="/usr/scripts/canon_40d.sh"

On detection of the USB camera by udev, this rule uniquely identifies the camera using the idProduct and idVendor numbers, it then sets the access mode to 0666 (read and write access for everyone), it also creates a symbolic link /dev/canon_40d (note, this dev can not be used for much as the device uses PTP). Finally the rule runs my script located at /usr/scripts/canon_40d.sh

to:

SUBSYSTEM=="usb_device", SUBSYSTEMS=="usb", ATTRS{idProduct}=="3146", ATTRS{idVendor}=="04a9", MODE="0666", SYMLINK+="cannon_40d", RUN+="/usr/scripts/canon_40d.sh"

On detection of the USB camera by udev, this rule uniquely identifies the camera using the idProduct and idVendor numbers, it then sets the access mode to 0666 (read and write access for everyone), it also creates a symbolic link /dev/canon_40d (note, this dev can not be used for much as the device uses PTP). Finally the rule runs my script located at /usr/scripts/canon_40d.sh

Changed lines 72-73 from:

My very simple canon_40d.sh script is the following

to:

My very simple canon_40d.sh script is the following

Added line 80:
Changed line 82 from:

KERNEL=="event[0-9]*", ATTRS{name}=="ixp4xx beeper", MODE="0666"\\

to:

KERNEL=="event[0-9]*", ATTRS{name}=="ixp4xx beeper", MODE="0666"\\

Changed lines 85-86 from:

The actual getting of the photos from the camera is not done here, but rather I call another of my simple scripts get_photos.sh. This is because udev is blocked until returned from the canon_40d.sh script.

to:

The actual getting of the photos from the camera is not done here, but rather I call another of my simple scripts get_photos.sh. This is because udev is blocked until returned from the canon_40d.sh script.

Added line 88:
May 04, 2008, at 01:36 PM by Alex Scott --
Deleted line 47:
Changed line 64 from:

To reload this new rule run

to:

To reload this new udev rule run

Changed lines 79-80 from:

(note 'beep' just beeps the on-board buzzer to let you know the camera has been detected, if you want to make the buzzer accessible by normal users edit the /etc/udev/rules.d/permissions.rule and add the following rule KERNEL=="event[0-9]*", ATTRS{name}=="ixp4xx beeper", MODE="0666"

to:

(note 'beep' just beeps the on-board buzzer to let you know the camera has been detected, if you want to make the buzzer accessible by normal users edit the /etc/udev/rules.d/permissions.rule and add the following rule
KERNEL=="event[0-9]*", ATTRS{name}=="ixp4xx beeper", MODE="0666"\\

May 04, 2008, at 01:33 PM by Alex Scott --
Changed line 35 from:

Find udev information for your camera, firstly install the udev-utils package

to:

Firstly, to find udev information for your camera install the udev-utils package

Changed line 40 from:

Now plug in the USB and turn on the camera and make sure it has been identified by the USB system

to:

Now plug in the USB plug and turn on the camera and make sure it has been identified by the USB system

Changed lines 70-72 from:

Now turn of and then turn back on the camera for it to be picked up by the new udev rule (or run #udevtrigger)

to:

Now turn off and then turn back on the camera for it to be picked up by the new udev rule (or run #udevtrigger)

May 04, 2008, at 01:27 PM by Alex Scott --
Changed line 31 from:

A summary of the steps is as follows

to:

A summary of the steps is as follows\\

Changed lines 35-36 from:

Find udev information for your camera Firstly install the udev-utils package

to:

Find udev information for your camera, firstly install the udev-utils package

Added line 48:
Added line 52:
Changed lines 55-60 from:

Now some of the device details from udevinfo output are used to create a udev rule that uniquely identifies the camera

For an excellent explanation of udev rules see writing_udev_rules by Daniel Drake

For my Canon 40D, using some of the outputs from udevinfo I created the following udev rule and added it to a new file /etc/udev/rules.d/10-local.rules

to:

Now some of the device details from udevinfo output are used to create a udev rule that uniquely identifies the camera.

For an excellent explanation of udev rules see http://www.reactivated.net/writing_udev_rules.html by Daniel Drake.

For my Canon 40D, using some of the outputs from udevinfo I created the following udev rule and added it to a new file /etc/udev/rules.d/10-local.rules

Changed lines 63-65 from:

This rule uniquely identifies the camera using the idProduct and idVendor numbers, it then sets the access mode to 0666 (read and write access for everyone), it also creates a symbolic link /dev/canon_40d (note, this dev can not be used for much as the device uses PTP). Finally the rule runs my script located at /usr/scripts/canon_40d.sh

To reload the rules run

to:

On detection of the USB camera by udev, this rule uniquely identifies the camera using the idProduct and idVendor numbers, it then sets the access mode to 0666 (read and write access for everyone), it also creates a symbolic link /dev/canon_40d (note, this dev can not be used for much as the device uses PTP). Finally the rule runs my script located at /usr/scripts/canon_40d.sh

To reload this new rule run

Changed line 80 from:

(note 'beep' just beeps the on-board buzzer to let you know the camera has been detected, if you want to make the buzzer accessible by normal users edit the /etc/udev/rules.d/permissions.rule and add the following rule

to:

(note 'beep' just beeps the on-board buzzer to let you know the camera has been detected, if you want to make the buzzer accessible by normal users edit the /etc/udev/rules.d/permissions.rule and add the following rule

May 04, 2008, at 01:21 PM by Alex Scott --
Changed lines 29-30 from:

The SlugOS/BE 4.8 doesn't use hotplug but triggering events on detection of the USB camera can be done via /etc/udev/rules.d/ rules files. This enables running of a simple gphoto2 --get-all-files script.

to:

The SlugOS/BE 4.8 doesn't use hotplug but triggering events on detection of the USB camera can be done via /etc/udev/rules.d/ rules files. This enables running of a simple gphoto2 --get-all-files script.

Changed line 32 from:

1. Find udev information for given camera.

to:

1. Find udev information for given camera.\\

Changed lines 56-57 from:

For an excellent explanation of udev rules see http://www.reactivated.net/writing_udev_rules.html by Daniel Drake

to:

For an excellent explanation of udev rules see writing_udev_rules by Daniel Drake

May 04, 2008, at 01:18 PM by Alex Scott --
Changed line 32 from:

1. Find udev information for given camera

to:

1. Find udev information for given camera.

May 04, 2008, at 01:17 PM by Alex Scott --
Changed lines 27-28 from:

SlugOS/BE 4.8 Beta (NSLU2) with PTP cameras

to:

SlugOS/BE 4.8 Beta (NSLU2) with PTP cameras

Changed lines 32-34 from:

1) Find udev information for given camera 2) Create new /etc/udev/rules.d/10-local.rules to run a script when your device is detected

to:

1. Find udev information for given camera 2. Create new /etc/udev/rules.d/10-local.rules to run a script when your device is detected

Added line 96:
May 04, 2008, at 01:13 PM by Alex Scott --
Changed lines 27-28 from:

SlugOS/BE 4.8 Beta (NSLU2) with PTP cameras

to:

SlugOS/BE 4.8 Beta (NSLU2) with PTP cameras

Added line 37:

[@

Changed lines 39-40 from:
to:

@]

Added line 42:

[@

Changed lines 44-45 from:
to:

@]

Changed line 49 from:
to:

[@

Changed line 51 from:
to:

@]

Added line 65:

[@

Changed lines 67-68 from:
to:

@]

Changed line 73 from:
to:

[@

Changed line 78 from:
to:

@]

Changed line 86 from:
to:

[@

Changed line 95 from:
to:

@]

May 04, 2008, at 01:09 PM by Alex Scott --
Changed lines 25-26 from:
to:

Added line 28:
Changed line 92 from:

Alex Scott
to:

--- Alex Scott

May 04, 2008, at 01:07 PM by Alex Scott -- SlugOS/BE 4.8 Beta (NSLU2) with PTP cameras - Canon 40D
Changed lines 23-90 from:

--- Pablo Duboue

to:

--- Pablo Duboue

SlugOS/BE 4.8 Beta (NSLU2) with PTP cameras The SlugOS/BE 4.8 doesn't use hotplug but triggering events on detection of the USB camera can be done via /etc/udev/rules.d/ rules files. This enables running of a simple gphoto2 --get-all-files script.

A summary of the steps is as follows 1) Find udev information for given camera 2) Create new /etc/udev/rules.d/10-local.rules to run a script when your device is detected

Find udev information for your camera Firstly install the udev-utils package

  1. ipkg install udev-utils

Now plug in the USB and turn on the camera and make sure it has been identified by the USB system

  1. dmesg | tail -n 10

This should show that a high speed device USB device is using ehci_hcd and address X

Where X will be a number (1,2,3, etc) that we use to find udev information about the device

  1. udevinfo -a -p /sys/class/usb_devices/usbdev1.X

(note: I believe /usbdev1.X maybe /usbdev2.X depending on the USB port the camera is plugged into)

Now some of the device details from udevinfo output are used to create a udev rule that uniquely identifies the camera

For an excellent explanation of udev rules see http://www.reactivated.net/writing_udev_rules.html by Daniel Drake

For my Canon 40D, using some of the outputs from udevinfo I created the following udev rule and added it to a new file /etc/udev/rules.d/10-local.rules

SUBSYSTEM=="usb_device", SUBSYSTEMS=="usb", ATTRS{idProduct}=="3146", ATTRS{idVendor}=="04a9", MODE="0666", SYMLINK+="cannon_40d", RUN+="/usr/scripts/canon_40d.sh"

This rule uniquely identifies the camera using the idProduct and idVendor numbers, it then sets the access mode to 0666 (read and write access for everyone), it also creates a symbolic link /dev/canon_40d (note, this dev can not be used for much as the device uses PTP). Finally the rule runs my script located at /usr/scripts/canon_40d.sh

To reload the rules run

  1. udevcontrol reload_rules

Now turn of and then turn back on the camera for it to be picked up by the new udev rule (or run #udevtrigger)

My very simple canon_40d.sh script is the following

  1. !/bin/sh
  2. Called from /ect/udev/rules.d/10-local.rules

/bin/beep -f 392.0 -n -f 493.9 /usr/scripts/get_photos.sh &

(note 'beep' just beeps the on-board buzzer to let you know the camera has been detected, if you want to make the buzzer accessible by normal users edit the /etc/udev/rules.d/permissions.rule and add the following rule KERNEL=="event[0-9]*", ATTRS{name}=="ixp4xx beeper", MODE="0666" This sets the access mode of the beeper to 0666)

The actual getting of the photos from the camera is not done here, but rather I call another of my simple scripts get_photos.sh. This is because udev is blocked until returned from the canon_40d.sh script.

This script simply copies all the photos into a 'pre_sort' folder, I then use another script to sort the photos based on the exif data (using a native compile of exif).

  1. !/bin/sh
  2. Downloads all photos from attached camera
  3. then beeps...

cd /home/nas/photos/pre_sort gphoto2 --quiet -P chmod -R 0755 /home/nas/photos/pre_sort beep -r 3 /usr/scripts/sort_photos.sh &

And that it!


Alex Scott
October 08, 2007, at 03:44 PM by PabloDu --
Changed lines 21-22 from:

What would be interesting is to use http://www.imagemagick.org/][libmagick to create a fake photo inside the camera acknowledging the pictures have downloaded correctly, so you can erase them by hand without fear.

to:

What would be interesting is to use libmagick to create a fake photo inside the camera acknowledging the pictures have downloaded correctly, so you can erase them by hand without fear.

October 08, 2007, at 03:43 PM by PabloDu --
Changed line 23 from:
to:

--- Pablo Duboue

October 08, 2007, at 03:43 PM by PabloDu -- libmagick
Changed lines 19-23 from:

--- Sam Holden

to:

--- Sam Holden

What would be interesting is to use http://www.imagemagick.org/][libmagick to create a fake photo inside the camera acknowledging the pictures have downloaded correctly, so you can erase them by hand without fear.

--- PabloDu?

July 28, 2006, at 03:11 PM by Steffen --
Changed lines 1-2 from:

There are two ways digital cameras interface with PCs?.

to:

There are two ways digital cameras interface with PCs.

April 04, 2006, at 12:10 PM by eFfeM -- differentiate between MSC and PTP
Added lines 1-8:

There are two ways digital cameras interface with PCs?.

The first case is that the camera represents itself as a USB mass storage class device. Getting content off those cameras is similar to getting content from a memory stick. Just mount them as a fat filesystem and copy the content.

The other breed of cameras (e.g. Canon) uses PTP (picture transfer protocol). In order to use this a program like gphoto2 needs to be used. This page only covers PTP cameras.


January 07, 2006, at 04:48 PM by tman --
Added line 11:

--- Sam Holden

January 07, 2006, at 04:42 PM by tman --
Changed lines 1-5 from:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive

Some users report that in the current 5.x release of Unslung, you can't connect anything to the second USB port once you've booted off an unslung drive in the first port: http://slugbug.nslu2-linux.org/bug.php?op=show&bugid=288, but no-one on the core development team has been able to reproduce that bug.

to:

Use gphoto to read images off a supported USB-connected digital camera, and back them up to a USB hard drive. A list of supported cameras is on the gphoto site.

Changed lines 9-10 from:

So all you do it plug the camera into the free usb port and turn it on in view mode (and wait a while if you took lots of photos). You then have to delete the images from the camera manually, since I'm too paranoid to do that in the script.

to:

So all you do it plug the camera into the free USB port and turn it on in view mode (and wait a while if you took lots of photos). You then have to delete the images from the camera manually, since I'm too paranoid to do that in the script.

January 05, 2006, at 09:28 PM by Sam Holden --
Added lines 4-13:

I do this with my OpenDebianSlug device.

It was as simple as installing the hotplug and gphoto2 packages and then writing a shell script which does a gphoto2 --get-all-files and then moves the files based upon the date stored in the exif data to the appropriate directory. I just added a call to run that script to the end of /etc/hotplug/usb/libgphoto2.

So all you do it plug the camera into the free usb port and turn it on in view mode (and wait a while if you took lots of photos). You then have to delete the images from the camera manually, since I'm too paranoid to do that in the script.

December 31, 2005, at 05:17 AM by rwhitby --
Changed lines 1-6 from:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive. One small problem, though, in the current 5.x release of Unslung, you can't connect anything to the second USB port once you've booted off an unslung drive in the first port:

http://slugbug.nslu2-linux.org/bug.php?op=show&bugid=288

TMAN: stop editting out my stuff. You must not be running the same version of 5.x.

to:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive

Some users report that in the current 5.x release of Unslung, you can't connect anything to the second USB port once you've booted off an unslung drive in the first port: http://slugbug.nslu2-linux.org/bug.php?op=show&bugid=288, but no-one on the core development team has been able to reproduce that bug.

December 13, 2005, at 12:35 PM by kc -- restored
Changed lines 1-6 from:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive.

to:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive. One small problem, though, in the current 5.x release of Unslung, you can't connect anything to the second USB port once you've booted off an unslung drive in the first port:

http://slugbug.nslu2-linux.org/bug.php?op=show&bugid=288

TMAN: stop editting out my stuff. You must not be running the same version of 5.x.

December 01, 2005, at 03:58 PM by tman -- No such problem in Unslung
Changed lines 1-3 from:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive. One small problem, though, in the current 5.x release of Unslung, you can't connect anything to the second USB port once you've booted off an unslung drive in the first port:

http://slugbug.nslu2-linux.org/bug.php?op=show&bugid=288

to:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive.

November 14, 2005, at 03:25 AM by kc --
Added lines 1-3:

Use gphoto to read images off any USB-connected digital camera, and back them up to a usb-hard drive. One small problem, though, in the current 5.x release of Unslung, you can't connect anything to the second USB port once you've booted off an unslung drive in the first port:

http://slugbug.nslu2-linux.org/bug.php?op=show&bugid=288

view · edit · print · history · Last edited by Alex Scott.
Based on work by de, Alex Scott, PabloDu, Steffen, eFfeM, tman, Sam Holden, rwhitby, and kc.
Originally by kc.
Page last modified on May 13, 2008, at 10:00 AM