Digital camera notes
Timelapse notes
Images from webcam
If your (laptop-internal or attached) webcam is decent enough quality, it's potentially simplest.
For windows, I find that most timelapse software is somewhere between Utter Crap and Quirky-but-Workable - or paid-for and somewhat better (not necessarily much).
On linux you're likely using v4l/v4l2 (how exactly varies), but at least the tools are there.
Examples:
- xawtv's streamer (may be packaged separately, as it is on ubuntu)
# -r 1 for 1fps, -j 100 for little jpeg compression, 99999 basically meaning 'until you stop it' streamer -o 00000.jpeg -s 640x480 -j 100 -t 99999 -r 1
- fswebcam[1]
# doesn't do sequences, but we can fix that ourselves let i=0 while [ $i -lt 99999 ]; do outfn=$(printf '%05d.jpg' $i) # or perhaps #outfn=`date +%Y-%m-%d_%H%M%S`.jpg fswebcam -r 640x480 --jpeg 100 -D 1 --no-banner $outfn let i=$i+1 done
- motion[2]
TODO
You can also use ffmpeg/avconv, mencoder, and vlc, though that tends to be a little more typing.
Images from PTP camera
Non-PTP solutions
Captured images to video
Since I'm a *nix person about these things, I use something along the lines of:
- In mencoder, and just throwing bitrate at it instead:
ls *.JPG | sort > filelist
mencoder -nosound -mf fps=24 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=8000 mf://@filelist
- note: command is avconv in some recent ubuntu
ffmpeg -f image2 -pattern_type glob -i "*.jpg" -vcodec libx264 -r 24 -crf 23 -vf "crop=640:400:0:0,unsharp=5:5:2" output.avi
- if it complains about pattern_type, it's probably an old ffmpeg/avconv
Capture straight to video
PTP notes
(...technical notes. And probably quite outdated)
PTP as in Picture Transfer Protocol, used by various digital cameras to communicate.
If your camera shows up as a drive but not quite, a driver is probably talking PTP to it, and presenting your OS with something filesystem-like.
Aside from fetching files from the device, PTP also allows things like readout and setting of various camera properties.
The exact interaction it allows may vary per camera series and model.
General PTP protocol notes
Some PTP concepts:
- Initiator, Responder - roughly, the client and server (respectively) in a connection
- Operation - instructions that can be sent
- Different devices support different commands. You can ask it for what it supports
- Property - type/values that can be fetched.
- Different devices support different sets of properties. You can ask it for what it supports
- Events - often used to signal state changes (change in objects, stores, device parameter)
- Different devices have different events. You can ask it for what it supports
- Events are typically generated by the Responder
- cameras should deal with synchronous and asynchronous events
- can be in-band (same channel as operations and responses) or out of band (separate, and often requiring polling)
- StorageID - 32-bit uint referring to something that can store objects. Two parts:
- physical - highest 16 bits, referring to a distinct physical storage area in a device
- logical - lowest 16 bits, possible subdivisions within a physical storage area
- ObjectHandle - 32-bit uints referring to data objects and the structure between them
- mostly files, directories, and tacking files onto each other
- (see ObjectFormat(Code), in particular Association (0x3001), and see operations that take parent ObjectHandles)
- You can create a (somewhat simplified) view a PTP device as a filesystem, and a various drivers for specific cameras do this to some degree to allow image download (and possibly more)
- ObjectFormat - there are about three dozen of these codes, referring to various image and a few sound storage formats, and a range for vendor defined values.
- Datacodes enumerate many of the concepts above. They are 16-bit uints, where the highest four bits declare the type of value.
- Bit 15 is 0 for standard codes, 1 for vendor-defined codes
- Bits 14..12 are:
- 001: operation (...so 0x1000 range for standard, 0x9000 for vendor)
- 010: response (...so 0x2000 range for standard, 0xA000 for vendor)
- 011: object format (...so 0x3000 range for standard, 0xB000 for vendor)
- 100: event (...so 0x4000 range for standard, 0xC000 for vendor)
- 101: device property (...so 0x5000 range for standard, 0xD000 for vendor)
- The other combinations are undefined or reserved
Packets
This is lower-level, so mostly matters when you'll be looking at USB logs.
Containers all share the first 12 bytes:
byte byte offset size 0 4 overall container length 4 2 container type (1=command, 2=data, 3=response, 4=event, 0=undefined) 6 2 datacode (what operation/response/event) 8 4 transaction ID
This is followed by payload - up to the given container length. The payload's length is implied by the container's mentioned length, the payload's treatment by the type and code.
Command blocks:
- payload consists of 32-bit parameters
- No length mentioned in payload, but implied by container's mentioned length: the number of parameters is always exactly (container_length - 12)/4
Response blocks:
- Same structure as command blocks.
Data blocks:
- Payload structure not defined - depends entirely on the operation.
For example (big-endian byte log, and we're ignoring the transactionIDs):
0c 00 00 00 03 00 01 20 11 00 00 00 → Length 12, response, code 2001 (OK), no parameters 10 00 00 00 01 00 05 10 12 00 00 00 01 00 01 00 → Length 16, command, code 1005 (GetStorageInfo), 1 parameter (with value 0x10001)
See also:
Canon PTP notes
Canon relies a lot on its own extensions.
There seems to be more than one extension set/behaviour to deal with, between different series of cameras, and sometimes within them (e.g. the longer-lived EOS series).
The below is meant as reference, not as description of any one camera.
It is a union of notes from various sources, some specific to EOS series, some apparently from point-and-shoots with a completely different interface.
Properties
I've seen libraries contain the following, which I'm guessing is for point and shoots:
(I've seen conflicting property names - not sure whether that was a single mistake in observation or overlaps between different series, so don't trust the following yet)
D001 Beep mode D002 Battery type (Enumeration: 0,1,2,3,4,5, where 2 is Li?) D003 Battery Mode (Enumeration: 0,1,2,3) D006 Image quality D008 Image size D00A Flash mode D00C Tv Av setting D010 Metering mode D011 Macro mode D012 Focusing point D013 White balance D01C ISO D01D Aperture D01E Shutter speed D01F Exposure Compensation D02A Zoom D02C Size Quality Mode D02D Supported Thumb Size (?) D02E 'Size of Output Data from Camera' (?) D02F 'Size of Input Data to Camera' (?) D030 Remote API version D031 Flash memory (size?) D032 Camera Model D033 Camera Owner D034 Unix Time D036 Viewfinder mode D039 Real image width D040 Photo effect D041 Assist light D045 Event Emulate Mode (?) D046 DPOF Version (?) D047 Type of Slideshow (?) D048 Average Filesizes (?) D049 Model ID (?) D04a (enumeration with values 0,1,2,3) D04b
EOS
EOSes does not seem to use/support standard 0x5000-series parameters. Your everyday camera parameters are reported via EOS's own event stream, which is fetched via operation 0x9661.
Depending on camera, there may be very few reported properties - standard or vendor.
My EOS 400D (vendorID 0x04A9, prodID 0x3110) reports the following properties:
values I saw D045 (Event Emulate Mode?) 2 D402 Device_Friendly_Name "Canon EOS 400D DIGITAL" D407 Perceived_Device_Type 1 D406 Session_Initiator_Version_Info "Unknown Initiator" D049 (Model ID?) 0x80000236 (2147484214) D04A 0
EOSes still use datacodes that sit in the right sort of range (>=0xD100), but you use them in vendor-specific operations way, not as PTP properties.
Known values include:
D101 Aperture D102 ShutterSpeed D103 ISO D104 ExposureCompensation D105 ShootingMode D106 DriveMode D107 ExpMeterringMode D108 AFMode D109 WhiteBalance D110 PictureStyle D111 TransferOption D113 UnixTime D120 ImageQuality D1B0 LiveView D11B AvailableShots D11C CaptureDestination D11D BracketMode
Operations
It seems you always get a good set of the standard 0x1001..0x101C range, to handle basic object, thumbnail, storage functions, so you can always fetch images from the device.
EOSes tend to support most of the common basic storage and object related operations:
1001 GetDeviceInfo 1002 OpenSession 1003 CloseSession 1004 GetStorageIDs 1005 GetStorageInfo 1006 GetNumObjects 1007 GetObjectHandles 1008 GetObjectInfo 1009 GetObject 100A GetThumb 100B DeleteObject 100C SendObjectInfo 100D SendObject 100F FormatStore 1014 GetDevicePropDesc 1015 GetDevicePropValue 1016 SetDevicePropValue 101B GetPartialObject
Notes:
- Missing from the full set: (this is for an EOS 400D)
- 100E, InitiateCapture. You can use vendor code 910F instead
- 1010, Reset
- 1011, SelfTest
- 1012, SetObjectProtection
- 1013, PowerDown
- 1017, ResetDevicePropValue
- 1018, TerminateOpenCapture
- 1019, MoveObject
- 101A, CopyObject
- 101C, InitiateOpenCapture
- Point and shoots may also omit formatting, uploading, and possibly the setting of properties
Added operations (note: names are descriptions copy-pasted from libraries, which probably chose them):
9001..9021 doesn't seem to apply to EOS (except some of the earliest?), seems to be for point and shoots 9001 GetObjectSize 9008 StartShootingMode 9009 StopShootingMode 900B ViewfinderOn 900C ViewfinderOff 900D ReflectChanges 9013 CheckEvent (also on EOS, the only <9100 there?) 9014 FocusLock 9015 FocusUnlock 901A InitiateCaptureInMemory 901B GetPartialObject 901D GetViewfinderImage 901F 9020 GetChanges 9021 GetFolderEntries
EOS operations seems to use codes >=0x9100 9101 EOS_GetStorageIDs 9102 EOS_GetStorageInfo 9103 9104 9107 EOS_GetObject 9105 9106 9108 EOS_GetDeviceInfo 9109 EOS_GetObjectIDs 910A 910B 910C 910E 910F EOS_Capture 9110 EOS_SetDevicePropValue 9113 9114 EOS_SetPCConnectMode 1 request parameter, seen taking value 0x00000001 9115 EOS_SetExtendedEventInfo SetEventMode 9116 EOS_GetEvent 9117 EOS_TransferComplete 9118 EOS_CancelTransfer 9119 EOS_ResetTransfer 911A 3 request parameters 911B 911C 0 request parameters 911D KeepDeviceOn 911F 911E 9120 9121 9126 0 request parameters 9127 EOS_GetDevicePropValue 9128 RemoteReleaseOn 9129 RemoteReleaseOff 9153 GetViewFinderData GetLiveViewPicture (where supported) 9155 MoveFocus 91FE 91FF 9801 GetObjectPropsSupported 9802 GetObjectPropDesc 9803 GetObjectPropValue 9804 SetObjectPropValue 9805 GetObjectPropList
Operation notes - non-EOS
Operation notes - EOS
Events
Non-EOS:
Added event codes:
C008 DEVICE INFO CHANGED C009 REQUEST OBJECT TRANSFER C00c CAMERA MODE CHANGED
EOS:
Standard events:
4004 StoreAdded 4005 StoreRemoved 4006 DevicePropChanged 4009 RequestObjectTransfer
Added event codes, EOS:
C101 C189 DevPropChanged C181 ObjectCreated C18A DevPropValuesAccepted C18B Capture C18E HalfPushReleaseButton
Slightly more practical stuff
Downloading images mostly consists of listing the handles for present images, then fetching them by handle.
EOS:
Apparently these cameras have a FIFO for events that you can poll - which (on EOSes) is what operation 9116 (EventCheck) is for.
Current shooting parameters are part of that - which is also why the Remote Shooting utility calls 9116 twice per second. If you want to understand (and send) camera parameters, you'll need to be able to parse event records. Example from here:
2C 00 00 00 02 00 16 91 0D 00 00 00 08 00 00 00 8E C1 00 00 10 00 00 00 89 C1 00 00 02 D1 00 00 5B 00 00 00 08 00 00 00 00 00 00 00
In parts:
2C 00 00 00 Length: 44 02 00 type 2: data packet 16 91 operation code 0x9116 0D 00 00 00 transaction id (probably handled by your PTP library) The payload: 08 00 00 00 - Event record of length 8 8E C1 00 00 event code for HalfPushReleaseButton 10 00 00 00 - Event record of length 16 89 C1 00 00 event code for DevPropChanged (the most important one) 02 D1 00 00 Property code for Exposure time 5B 00 00 00 Value indicating 1/20 sec 08 00 00 00 - Event record of length 8 00 00 00 00 (a null record as terminator)
Since event record describe their own size, you can easily choose to ignore any event for which you don't recognize or want to handle.
Basic operation response codes that matter when you're playing around yourself:
0x2001 OK 0x2005 OperationNotSupported 0x2019 DeviceBusy and perhaps 0x200C StoreFull