-
Notifications
You must be signed in to change notification settings - Fork 0
A collection of utilities to build a photo booth
License
rfuxx/photoboothtools
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Photo Booth Tools ================= A collection of utilities to build a photo booth. Photo booth is the idea that on a wedding, party or other event you set up a photo camera and printer where guests can take photos of themselves and have them directly printed. In order to "compete" with the mobile phone selfies which the guests will surely also take, you likely want to use a decent DSLR or EVIL camera for the photo booth and build a nice scene/background with a well metered (flash) light setup. (To learn about light setting&metering check out books and practical workshops about studio photography.) For the logic between capturing a photo from the camera and sending it to a printer, there will need to be some computer software running somewhere. This tool collection is based on the idea that using a "Pi"-like computer (Raspberry Pi / Banana Pi) to wire the photo booth components together, would be unobtrusive and keep the hardware out of sight. As cool and as versatile as these minicomputers are, they are unfortunately also considerably slower than most desktop computers when it comes to handling photos in full resolution. Even with the optimisations that these tools are providing, you will probably still find the first Raspberry models (the original A and B) too slow. I found a "Banana Pi" to give a somewhat acceptable performance, and I have not yet tried with the Raspberry 2 model. continuousCameraCapture ----------------------- Automatically download the new files from the camera as photos are taken. Usage: continuousCameraCapture <receivepath> This tool does a similar job like gphoto2 --wait-event-and-download with the following additional functionaities: - queues downloads so that jpg files are downloaded first (in case you shoot raw+jpg this will give you the viewable files faster, and the raw file is reordered for later download) - renames downloads according to exif date - rotates jpegs automatically (and handles exif similar as with exiftran) The idea to use this tool for photo booth purposes is that you set up the camera with a standard remote wire trigger or wireless trigger. Photos are taken without computer action but they are automatically downloaded to the <receivepath> on the computer. You should then have a tool monitoring the receive directory for new files and handle them (either directly print or show them on a display for the user to decide or add to a slideshow, whatever you may think of...) When downloading mixed jpg and raw(other) files, note that - the jpg files will be created with the correctly exifdate-based filename right away, even the auto-rotated ones. This is perfect so that the tool which is going to pick up the jpg files from the <receivepath> can make use of inotify monitoring very easily. - the raw and other files are first created with the camera-based filename and then renamed to the correct rawdate-based file name only if any date information can be found in them. This is not so good for picking them up with inotify monitoring. Known issues: - ERROR: You need to specify a folder starting with /store_xxxxxxxxx/ => I sometimes see this error on the reordered .cr2 file downloads when shooting burst series on my Canon EOS camera. It seems as if the gphoto2 library sometimes gets confused when this tool tries to receive the files in different order than they were created on the camera. I doubt that this problem is due to a bug in my code for continuousCameraCapture, because actually /store_xxxxxxxxx/ seems to be an internal name which is used between the camera and the libgphoto2, but never appearing between the libgphoto2 and application software like continuousCameraCapture. As an interesting observation, I thought these errors had been gone after I had updated libgphoto2 from Bananian "wheezy" with a custom-compiled version of libgphotos 2.5.5.1, but the errors were back after the Bananian "jessie" upgrade, even with recompiled custom versions of libgphoto2 2.5.5.1 and 2.5.8. (More analysis welcome. Fixes welcome.) quickJpegGutenPrint ------------------- Optimized print tool for JPEG pictures via Gutenprint printer drivers. Usage: quickJpegGutenPrint [-P|--cups-printer PRINTER] [-D|--gutenprint-driver DRIVER] [-C|--cups-option OPTION=VALUE] [-G|--gutenprint-parameter PARAMETER=VALUE] [--show-cups-options] [--show-gutenprint-parameters] [-q|-v|-vv] filename.jpg [...] Parameters: -P|--cups-printer PRINTER Select the printer on which you want to have the picture printed. If not specified, the default is according to cups/lpr rules (which may involve the $PRINTER environment variable and the lpoptions command). -D|--gutenprint-driver DRIVER Select which gutenprint driver to use for this printer. If not specified, will attempt to autodetect the gutenprint driver based on looking up details of the cups printer definition for the selected printer. -C|--cups-option OPTION=VALUE Specify additional cups settings (options) for the print job. You can put -C|--cups-option multiple times in order to set multiple options for the cups print job. -G|--gutenprint-parameter PARAMETER=VALUE Specify additional gutenprint settings (parameters) in order to optimize your print output. Note that many of these parameter names can be specific to your printer and to your gutenprint version. You can put -G|--gutenprint-parameter multiple times in order to set multiple parameters for the gutenprint driver. Limitation: A parameter which appears in the --show-gutenprint-parameters listing with one of the types (Curve)/(File)/(Raw)/(Array) cannot be specified. Actually this would not be generally impossible, but there is simply no implementation to parse such parameter types from the commandline. If you really, really need it, please grab the source code, write an implementation for it and share it back. --show-cups-options Query the specified (or auto-selected) cups printer and show its options. Actually most of these "options" are just descriptive stuff for the printer. The output --show-cups-options is not related (and surely not suggestive) with what you can specify for -C|--cups-option --show-gutenprint-parameters Query the specified (or auto-selected) gutenprint driver what parameters are available for it and list all available parameters in the form of Category: ParameterName (Type) DefaultValue AllowedRange where you can then use the ParameterName and a valid value with the -G|--gutenprint-parameter option. -q Quiet. Do not show the printer/driver auto-select messages. -v Verbose. Show each filename when it is processed. -vv Very Verbose. Show detailed additional information. Example: quickJpegGutenPrint -P Canon_CP900 --gutenprint-parameter ImageType=Photo --gutenprint-parameter Borderless=true *.jpg The idea to use this tool was originally to speed up the part of the print process from starting the print job until the printer makes its first move. This was because printing via lpr / via the normal Linux/Unix/CUPS print process has been very slow in the past. Oh, do not get me wrong: This is not to criticize the standard printing as such - it is great that it is designed for really generic purposes so that every kind out output can be printed to any printer device. Older implementations of Linux/Unix printing seem to have been really slow because every file to be printed must be converted twice (first to a generic intermediate format and then to the printer specific raw output), and this has apparently happened on disk and with complex formats and using complex conversion engines. Modern versions of CUPS seem to have much improved implementations - on some installations I could hardly notice a difference anymore between printing via lpr versus printing via quickJpegGutenPrint. This is surely because the modern print system implementations are using the same kind of optimisations as quickJpegGutenPrint does. So finally, quickJpegGutenPrint's optimisations are in three areas: - Optimized print data conversion by streaming the image rasterlines directly from the jpeg loader to the printer driver (no extra copy of the picture is held im memory neither on disk). - Matching picture orientation with the print paper orientation by using optimized JPEG rotation (the rotation happens during the loading of the JPEG and not on the fully-blown image pixels). - IDCT-Scaling the JPEG image during decoding so that it will be decoded only to (slightly larger than) the print size (avoids to waste memory and time resources to unnecessariliy manage the full image size). There will still be the raw printer data file in the cups spool directory, but of course you cannot avoid that for having proper print queue management. Dependencies ------------ - libjpeg - libexif - libgphoto2 - libraw - libcups - libgutenprint Credits ------- - had started with sample-tether.c from libgphoto2 in order to extend it to all the functionality for continuousCameraCapture.c - using libjpeg's "transupp" for the basic JPEG rotation code - heavy inspiration from fbida's "exiftran" for EXIF data/thumbnail handling on roatation
About
A collection of utilities to build a photo booth
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published