doc/camlib_devel.lyx

   1 #LyX 1.1 created this file. For more info see http://www.lyx.org/
   2 \lyxformat 2.15
   3 \textclass linuxdoc
   4 \language default
   5 \inputencoding latin1
   6 \fontscheme default
   7 \graphics default
   8 \paperfontsize default
   9 \spacing single
  10 \papersize Default
  11 \paperpackage a4
  12 \use_geometry 0
  13 \use_amsmath 0
  14 \paperorientation portrait
  15 \secnumdepth 3
  16 \tocdepth 3
  17 \paragraph_separation indent
  18 \defskip medskip
  19 \quotes_language english
  20 \quotes_times 2
  21 \papercolumns 1
  22 \papersides 1
  23 \paperpagestyle default
  24
  25 \layout Title
  26 \added_space_top vfill \added_space_bottom vfill
  27 gPhoto2 Camera Library Developer's Guide
  28 \layout Author
  29
  30 Scott Fritzinger
  31 \newline
  32 2000-07-26
  33 \newline
  34 Revision 1
  35 \layout Standard
  36
  37
  38 \begin_inset LatexCommand \tableofcontents{}
  39
  40 \end_inset
  41
  42
  43 \layout Section
  44
  45 Reverse Engineering the Camera Protocol
  46 \layout Standard
  47
  48 The most difficult part for most developers is obtaining the transfer protocol.
  49  If the OEM's are lucky enough, they will simply provide us with the protocol
  50  specifications for their cameras and the drivers will be written at no
  51  cost to them.
  52  Most OEM's refuse to do so though, citing trade secrets or company policy;
  53  this is truly unfortunate in that they have effectively told their own
  54  customers who use operating systems other than Windows and the Mac that
  55  they don't want their future business and that they aren't valued customer
  56  to begin with.
  57 \layout Standard
  58
  59 When OEM's do not cooperate, the developer is left to determine the protocol
  60  him/herself through reverse engineering.
  61
  62 \layout Subsection
  63
  64 Sniffing the Protocol
  65 \layout Standard
  66
  67 What follows are the most common setups for sniffing camera protocol traffic.
  68  In all setups, a host computer runs the native camera drivers.; typically,
  69  the Windows serial port drivers are used for reverse engineering.
  70  The drivers are run through a series of functions that include getting
  71  a picture index, downloading thumbnails, download full images, deleting
  72  images, camera configuration options, in addition to any other features
  73  a camera might have.
  74  During these operations, one or more of the following methods are used
  75  to capture the communication between the host computer and the camera.
  76 \layout Subsubsection
  77
  78 Serial Repeater
  79 \layout Standard
  80
  81 A serial repeater consists of the host computer, a computer used as a repeater,
  82  and the camera.
  83  The setup is shown in figure .
  84 \layout Standard
  85
  86 The repeater runs special software which reads data from one serial port,
  87  logs the communication, and then outputs the data to the other serial port.
  88  Data that is from the host computer to the camera and from the camera to
  89  the host computer is logged sequentially in a single log file.
  90  Information logged includes hexadecimal data values, direction of the communica
  91 tion, as well as time stamps for synchronization.
  92  An example sniffer to use for this configuration is
  93 \begin_inset Quotes eld
  94 \end_inset
  95
  96 sersniff
  97 \begin_inset Quotes erd
  98 \end_inset
  99
 100 .
 101 \layout Subsubsection
 102
 103
 104 \begin_inset Quotes eld
 105 \end_inset
 106
 107 Y
 108 \begin_inset Quotes erd
 109 \end_inset
 110
 111  Serial Cable
 112 \layout Standard
 113
 114 To avoid using two computers, a Y serial cable can be used.
 115  The
 116 \begin_inset Quotes eld
 117 \end_inset
 118
 119 trunk
 120 \begin_inset Quotes erd
 121 \end_inset
 122
 123  end of the serial cable attaches to the camera's serial transfer cable,
 124  while the two
 125 \begin_inset Quotes eld
 126 \end_inset
 127
 128 branches
 129 \begin_inset Quotes erd
 130 \end_inset
 131
 132  plug in to two serial ports on the host computer.
 133  Figure shows this setup.
 134 \layout Standard
 135
 136 The camera drivers use one of the serial ports on the host computer, while
 137  the other port is opened with a hexadecimal monitor application that dumps
 138  all communications on the port to a file.
 139  The downside to this approach is the developer would have to determine
 140  which sets of data was generated by the camera or the host computer.
 141  Also, a Y cable would have to be either built or purchased from an electronics
 142  supply store.
 143 \layout Subsubsection
 144
 145 Virtual Device Driver Hooks
 146 \layout Standard
 147
 148 The Windows platform allows virtual device drivers to
 149 \begin_inset Quotes eld
 150 \end_inset
 151
 152 hook
 153 \begin_inset Quotes erd
 154 \end_inset
 155
 156  into other drivers to provide additional functionality or feature enhancements.
 157  A combination GUI and device driver named PortMon by Systems Internals
 158  is a communications debugging utility that hooks into the existing Windows
 159  serial device driver (vcomm.vxd) and logs communications.
 160  Figure shows this equipment arrangement.
 161 \layout Standard
 162
 163 This setup allows the developer to not use any extra hardware by simply
 164  relying on software.
 165  This is perhaps the easiest method for capturing camera data.
 166 \layout Subsection
 167
 168 Making Sense Out of the Protocol
 169 \layout Standard
 170
 171 What follows are some pointers on decoding camera protocols.
 172  It uses a protocol that isn't really any camera protocol in particular,
 173  but should demonstrate some commonalities between most camera protocols.
 174 \layout Enumerate
 175
 176 Cameras like to ping.
 177  This is the in the form of an "ACK"" command that is different for different
 178  cameras.
 179  Basically, it is usually a short packet (probably 1 byte) that is sent
 180  both ways in order for the camera to know the computer is there or vice
 181  versa.
 182  It is also sometimes used to wake up a camera that has gone into power-save
 183  mode.
 184  It usually starts out the communications, as well as confirms each packet
 185  in any sort of "mass" transfer.
 186  The opposite, a "NAK", is sent to basically say the last packet was not
 187  received, or an error has occurred.
 188  Again, this is usually just a single byte as well.
 189 \newline
 190
 191 \newline
 192 Example:
 193 \newline
 194 Computer: 01
 195 \newline
 196 Camera : 01
 197 \newline
 198
 199 \newline
 200 The Camera sent an ACK ("01") and the Computer responded with an ACK as
 201  well.
 202 \layout Enumerate
 203
 204 Transfers are usually in "reverse network order", meaning least significant
 205  bytes come before most significant bytes.
 206  For example,
 207 \begin_inset Quotes eld
 208 \end_inset
 209
 210 00 08
 211 \begin_inset Quotes erd
 212 \end_inset
 213
 214  should actually be reassembled as
 215 \begin_inset Quotes eld
 216 \end_inset
 217
 218 08 00
 219 \begin_inset Quotes erd
 220 \end_inset
 221
 222 .
 223
 224 \layout Enumerate
 225
 226 Most protocols use starting and stopping bytes.
 227
 228 \newline
 229
 230 \newline
 231 Example:
 232 \newline
 233 Computer: 03 50 00 0f e0 04
 234 \newline
 235 Camera : 03 03 00 3f 03 04
 236 \newline
 237 Computer: 01
 238 \newline
 239
 240 \newline
 241 For this example, notice the packets begin with "03" and end with "04" (don't
 242  pay attention to what is between them).
 243  Also notice the Computer sent an "ACK" to confirm it got the packet.
 244 \layout Enumerate
 245
 246 Packets usually have a "command" byte, which tells either the computer or
 247  the camera what to do.
 248  Let's say you told the software to retrieve the number of pictures, which
 249  at the time happened to be "8", and you got the following:
 250 \newline
 251
 252 \newline
 253 Computer: 03 01 00 00 00 04
 254 \newline
 255 Camera : 03 01 00 00 08 04
 256 \newline
 257 Computer: 01
 258 \newline
 259
 260 \newline
 261 In this example, you notice the "03" and "04" specifying the start and stop
 262  of the packet.
 263  Also, you notice the second byte in the Computer packet is "01".
 264  The camera responds with the above packet, and low and behold, you see
 265  the number 8 in the same packet.
 266  It would appear, initially, that the second byte is used as a command byte,
 267  and that "01" specifies the camera to return the number of pictures.
 268  This may very well be right, but don't jump into it yet.
 269  Make sure you look at a bunch of similar situations to confirm this.
 270  (Again, notice the "ACK" sent by the computer).
 271 \layout Enumerate
 272
 273 Most protocols have a "data size" byte(s) in data packets.
 274  Let's say that you told the camera to retrieve thumbnail 8 and you get
 275  the following:
 276 \newline
 277
 278 \newline
 279 Computer: 03 02 00 00 08 04
 280 \newline
 281 Camera : 03 02 00 0F (15 bytes) 04
 282 \newline
 283 Computer: 01
 284 \newline
 285
 286 \newline
 287 OK, here's a brief breakdown of this transaction:
 288 \newline
 289
 290 \newline
 291 -Looks like the command to retrieve a thumbnail is "02" (2nd byte in the
 292  computer packet), and that the byte that is "08" specifies which thumbnail
 293  to return.
 294 \newline
 295 -The camera responds with a "02" in the command field, specifying it is
 296  returning a thumbnail, and then sends "0F", and 15 bytes of data.
 297
 298 \newline
 299 -It looks like the byte "0F" specifies how many bytes are after it in the
 300  same packet.
 301  This is a data size byte.
 302
 303 \newline
 304 (Note: this is a simplistic example.
 305  No thumbnail will only be 15 bytes :) this leads up to the next thing to
 306  consider)
 307 \layout Enumerate
 308
 309 Most protocols have an "order" or "counter" byte.
 310  This is used so that, in large data transfers where the picture may be
 311  split up into several different packets, the computer knows how to reassemble
 312  all the data.
 313  The entire thumbnail more than likely will not be contained in a single
 314  packet for logistical reasons, so they break up the data into many different
 315  packets and give each packet a unique number (or
 316 \begin_inset Quotes eld
 317 \end_inset
 318
 319 order
 320 \begin_inset Quotes erd
 321 \end_inset
 322
 323  byte).
 324  Let's say you told your camera to return thumbnail 8 (which is, as mentioned,
 325  pretty big), and you get the following:
 326 \newline
 327
 328 \newline
 329 Computer: 02 03 00 00 08 03
 330 \newline
 331 Camera : 02 03 00 0F (15 bytes) 03
 332 \newline
 333 Computer: 01
 334 \newline
 335 Camera : 02 03 01 0F (15 bytes) 03
 336 \newline
 337 Computer: 01
 338 \newline
 339 Camera : 02 03 02 0F (15 bytes) 03
 340 \newline
 341 Computer: 01
 342 \newline
 343 ...
 344  5 more packets and ACKs ...
 345 \newline
 346 Camera : 02 03 08 09 (9 bytes) 03
 347 \newline
 348 Computer: 01
 349 \newline
 350
 351 \newline
 352 You notice that the 3rd byte of each of the camera packets increments with
 353  each packet sent from the camera.
 354  This looks like it is an order (counter) byte.
 355  the computer can then reassemble the data from all the packets in order
 356  to reproduce the image.
 357 \layout Enumerate
 358
 359 Most protocols have some sort of error detection byte(s) at the end of the
 360  packet.
 361  This is usually a simple checksum (summation of bytes), or a CRC (a somewhat
 362  complex algorithm that reduces the probability of mis-diagnosing a packet
 363  with errors by magnitudes).
 364  These bytes can take into account only the data, or maybe the entire packet
 365  excluding those error detection bytes.
 366  If this isn't a known scheme, this winds up being the hardest part of reimpleme
 367 nting the protocol.
 368  Lets take the above example again, this time we'll add a couple bytes on
 369  the end for error detection:
 370 \newline
 371
 372 \newline
 373 Computer: 02 03 00 00 08 03
 374 \newline
 375 Camera : 02 03 00 0F (15 bytes) 0f 02 03
 376 \newline
 377 Computer: 01
 378 \newline
 379 Camera : 02 03 01 0F (15 bytes) 0e 00 03
 380 \newline
 381 Computer: 02
 382 \newline
 383 Camera : 02 03 01 0F (15 bytes) fa d0 03
 384 \newline
 385 Computer: 01
 386 \newline
 387 Camera : 02 03 02 0F (15 bytes) fa d0 03
 388 \newline
 389 Computer: 01
 390 \newline
 391 ...
 392  5 more packets and ACKs
 393 \newline
 394 Camera : 02 03 08 09 (9 bytes) d7 38 03
 395 \newline
 396 Computer: 01
 397 \newline
 398
 399 \newline
 400 Notice how the error detection bytes are usually different for each packet.
 401  These may be checksums, or CRC's, or something else.
 402  Only way to find out really is to try each one, on different combinations
 403  of packet parts (data, order byte, command byte, etc...) and see if you get
 404  the same thing.
 405  Try this on the shorter packets to make life easier.
 406 \newline
 407
 408 \newline
 409 Look at one more thing that sticks out in this transaction: for packet with
 410  order byte
 411 \begin_inset Quotes eld
 412 \end_inset
 413
 414 01
 415 \begin_inset Quotes erd
 416 \end_inset
 417
 418 , the Computer responded with a "02
 419 \begin_inset Quotes erd
 420 \end_inset
 421
 422 .
 423  and the Camera then resent the same packet it just did.
 424  This shows that the NAK byte is "02", and this could happen because maybe
 425  the error detection bytes didn't match with the data, or maybe something
 426  else happened.
 427  either way, the camera resent the last packet, and now you know how the
 428  camera can recover from transfer errors.
 429  If you didn't get the packet you were expecting, send the camera a NAK
 430  and it will resend the same packet again.
 431 \layout Section
 432
 433 Understanding the gPhoto2 Design
 434 \layout Standard
 435
 436 The gPhoto2 design is the same three-tiered structure that has worked extremely
 437  well in the past with other software packages.
 438  Here is a listing of the 3 tiers:
 439 \layout Itemize
 440
 441 the camera library
 442 \layout Itemize
 443
 444 the I/O library
 445 \layout Itemize
 446
 447 the front-end
 448 \layout Itemize
 449
 450 the
 451 \begin_inset Quotes eld
 452 \end_inset
 453
 454 core
 455 \begin_inset Quotes erd
 456 \end_inset
 457
 458
 459 \layout Subsection
 460
 461 Role of the Camera Library
 462 \layout Standard
 463
 464 The camera library is in charge of talking directly with the camera.
 465  The library uses the gPhoto2 Camera API in order to provide a common access-met
 466 hod for the library itself.
 467  Being dynamically linked, the libraries are loaded at run-time depending
 468  on the camera model the end-user would like to access.
 469
 470 \layout Standard
 471
 472 In order to provide flexilibity with variations in camera design, there
 473  are camera
 474 \begin_inset Quotes eld
 475 \end_inset
 476
 477 abilities
 478 \begin_inset Quotes erd
 479 \end_inset
 480
 481  which list, well, the abilities of each camera model.
 482  Some camera may support serial port connections only, while others may
 483  be able to use USB and a serial port.
 484  We've run into cameras that don't support thumbnailing on the camera so
 485  there is an
 486 \begin_inset Quotes eld
 487 \end_inset
 488
 489 abilities
 490 \begin_inset Quotes erd
 491 \end_inset
 492
 493  field to specify whether or not the camera supports thumbnailing.
 494  The
 495 \begin_inset Quotes eld
 496 \end_inset
 497
 498 abilities
 499 \begin_inset Quotes erd
 500 \end_inset
 501
 502  also list other things such as supported serial transfer speeds, file deletion,
 503  and other functionality.
 504 \layout Standard
 505
 506 The camera libraries only make functions calls to the I/O library and to
 507  the gPhoto2 core.
 508 \layout Standard
 509
 510 There is more information on the specifics of the camera library in section
 511  3 of this document.
 512 \layout Subsection
 513
 514 Role of the I/O Library
 515 \layout Standard
 516
 517 The gPhoto2 I/O library is a platform-independent communications library
 518  that support serial, parallel, USB, firewire, and network connections.
 519  It is a work-in-progress with a constantly expanding list of supported
 520  platforms.
 521  This library uses the gPhoto2 I/O library API for accessing communications
 522  devices.
 523  It enumerates the devices available on a system, and provides read/write
 524  access.
 525 \layout Standard
 526
 527 The camera libraries all use the I/O library for communications with the
 528  cameras.
 529  By doing having all communications go through a single library, the camera
 530  libraries become as portable as the I/O library.
 531  Porting gPhoto2 to other platforms become extremely easy.
 532 \layout Standard
 533
 534 There is more information on the specifics of the I/O library in section
 535  3 of this document.
 536 \layout Subsection
 537
 538 Role of the Front-end
 539 \layout Standard
 540
 541 The front-end is the application that the user interacts with.
 542  It is usually a command-line program, or a graphical point-and-click interface.
 543  The front-end talks only with the gPhoto2 core in order to retrieve pictures
 544  and perform other functions with the camera.
 545 \layout Subsection
 546
 547 Role of the gPhoto2 Core
 548 \layout Standard
 549
 550 The gPhoto2
 551 \begin_inset Quotes eld
 552 \end_inset
 553
 554 core
 555 \begin_inset Quotes erd
 556 \end_inset
 557
 558  is the heart of gPhoto2.
 559  It provides services to both the camera libraries and the front-ends.
 560  Most of the services deal with error-checking and enumeration of devices
 561  (cameras, I/O devices, etc...).
 562  The core performs validity checking on data passed to/from the front-end
 563  or the camera library.
 564 \layout Standard
 565
 566 You could consider the core a translator/interpreter/spell-checker/army-general
 567  in the
 568 \begin_inset Quotes eld
 569 \end_inset
 570
 571 big picture
 572 \begin_inset Quotes erd
 573 \end_inset
 574
 575  of gPhoto2.
 576  It does the grunt-work and performs the coordination of the other parts.
 577 \layout Section
 578
 579 Implementing the Library
 580 \layout Standard
 581
 582 gPhoto2 camera libraries use the gPhoto2 Camera API (CAPI) for implementation.
 583  Here is a listing of the CAPI functions:
 584 \layout Standard
 585
 586 camera_id
 587 \layout Standard
 588
 589 camera_abilities
 590 \layout Standard
 591
 592 camera_init
 593 \layout Standard
 594
 595 camera_exit
 596 \layout Standard
 597
 598 camera_folder_list
 599 \layout Standard
 600
 601 camera_file_list
 602 \protected_separator
 603
 604 \layout Standard
 605
 606 camera_file_get
 607 \layout Standard
 608
 609 camera_file_get_preview
 610 \layout Standard
 611
 612 camera_file_put
 613 \layout Standard
 614
 615 camera_file_delete
 616 \layout Standard
 617
 618 camera_config_get
 619 \layout Standard
 620
 621 camera_config_set
 622 \layout Standard
 623
 624 camera_capture
 625 \layout Standard
 626
 627 camera_summary
 628 \layout Standard
 629
 630 camera_manual
 631 \layout Standard
 632
 633 camera_about
 634 \newline
 635
 636 \layout Standard
 637
 638 Section 3.1 details the purpose of each of these functions, while Section
 639  3.2 discusses how to use the I/O library.
 640 \layout Subsection
 641
 642 Camera API
 643 \layout Standard
 644
 645 The CAPI provides the full set of functions for doing various tasks with
 646  the camera.
 647  All CAPI functions return either GP_OK for succesful execution , or GP_ERROR
 648  for a failure of execution
 649 \layout Standard
 650
 651 What follows is a listing of the functions, including prototypes and data
 652  exchange:
 653 \layout Subsubsection
 654
 655 camera_id
 656 \layout Standard
 657
 658
 659 \series bold
 660 Purpose:
 661 \series default
 662 Retrieve the unique id for the camera library.
 663 \layout Standard
 664
 665
 666 \series bold
 667 Prototype:
 668 \series default
 669 int camera_id (CameraText *id);
 670 \layout Standard
 671
 672
 673 \series bold
 674 Arguments:
 675 \layout Standard
 676
 677 CameraText *id : unique string to represent the camera library
 678 \newline
 679
 680 \layout Standard
 681
 682 In order to guarantee that only once instance of the camera library is loaded
 683  for each instance of the core, the camera library must copy a unique string
 684  into the
 685 \begin_inset Quotes eld
 686 \end_inset
 687
 688 id
 689 \begin_inset Quotes erd
 690 \end_inset
 691
 692 .
 693  Please consult the gPhoto developers to determine which string you should
 694  use.
 695 \newline
 696
 697 \layout Standard
 698
 699
 700 \series bold
 701 Example:
 702 \layout Standard
 703
 704 int camera_id(CameraText *id) {
 705 \layout Standard
 706
 707 strcpy(id->text,
 708 \begin_inset Quotes eld
 709 \end_inset
 710
 711 my-unique-string
 712 \begin_inset Quotes erd
 713 \end_inset
 714
 715 );
 716 \layout Standard
 717
 718 return (GP_OK);
 719 \layout Standard
 720
 721 }
 722 \layout Subsubsection
 723
 724 camera_abilities
 725 \layout Standard
 726
 727
 728 \series bold
 729 Purpose:
 730 \series default
 731 Retrieve the list of supported cameras and the abilities for each camera
 732 \layout Standard
 733
 734
 735 \series bold
 736 Prototype:
 737 \series default
 738 int camera_abilities (CameraAbilitiesList *list);
 739 \layout Standard
 740
 741
 742 \series bold
 743 Arguments:
 744 \series default
 745 d
 746 \layout Standard
 747
 748 CameraAbilities *abilities : the list of abilities for the supported cameras
 749 \layout Standard
 750
 751 int *count : the number of
 752 \layout Subsubsection
 753
 754 camera_init
 755 \layout Standard
 756
 757
 758 \series bold
 759 Purpose:
 760 \series default
 761 Initialize the camera
 762 \layout Standard
 763
 764
 765 \series bold
 766 Prototype:
 767 \series default
 768 int camera_init (Camera *camera, CameraInit *init);
 769 \layout Standard
 770
 771
 772 \series bold
 773 Arguments:
 774 \series default
 775 d
 776 \layout Subsubsection
 777
 778 camera_exit
 779 \layout Standard
 780
 781
 782 \series bold
 783 Purpose:
 784 \series default
 785 Close the camera
 786 \layout Standard
 787
 788
 789 \series bold
 790 Prototype:
 791 \series default
 792 int camera_exit (Camera *camera);
 793 \layout Standard
 794
 795
 796 \series bold
 797 Arguments:
 798 \series default
 799 d
 800 \layout Subsubsection
 801
 802 camera_file_list
 803 \layout Standard
 804
 805
 806 \series bold
 807 Purpose:
 808 \series default
 809 List the files in a particular folder on the camera
 810 \layout Standard
 811
 812
 813 \series bold
 814 Prototype:
 815 \series default
 816 int camera_file_list(Camera *camera, CameraList *list, char *folder);
 817 \layout Standard
 818
 819
 820 \series bold
 821 Arguments:
 822 \series default
 823 d
 824 \layout Subsubsection
 825
 826 camera_folder_list
 827 \layout Standard
 828
 829
 830 \series bold
 831 Purpose:
 832 \series default
 833 List the subfolders in a particular folder on the camera
 834 \layout Standard
 835
 836
 837 \series bold
 838 Prototype:
 839 \series default
 840 int camera_folder_list(Camera *camera, CameraList *list, char *folder);
 841
 842 \layout Standard
 843
 844
 845 \series bold
 846 Arguments:
 847 \series default
 848 d
 849 \layout Subsubsection
 850
 851 camera_file_get
 852 \layout Standard
 853
 854
 855 \series bold
 856 Purpose:
 857 \series default
 858 Retrieve a file from the camera
 859 \layout Standard
 860
 861
 862 \series bold
 863 Prototype:
 864 \series default
 865 int camera_file_get (Camera *camera, CameraFile *file, char *folder, char
 866  *filename);
 867 \layout Standard
 868
 869
 870 \series bold
 871 Arguments:
 872 \series default
 873 d
 874 \layout Subsubsection
 875
 876 camera_file_get_preview
 877 \layout Standard
 878
 879
 880 \series bold
 881 Purpose:
 882 \series default
 883 Retrieve a file's preview from the camera
 884 \layout Standard
 885
 886
 887 \series bold
 888 Prototype:
 889 \series default
 890 int camera_file_get_preview (Camera *camera, CameraFile *file, char *folder,
 891  char *filename);
 892 \layout Standard
 893
 894
 895 \series bold
 896 Arguments:
 897 \series default
 898 d
 899 \layout Subsubsection
 900
 901 camera_file_put
 902 \layout Standard
 903
 904
 905 \series bold
 906 Purpose:
 907 \series default
 908 Place (upload) a file to the camera
 909 \layout Standard
 910
 911
 912 \series bold
 913 Prototype:
 914 \series default
 915 int camera_file_put (Camera *camera, CameraFile *file, char *folder);
 916 \layout Standard
 917
 918
 919 \series bold
 920 Arguments:
 921 \series default
 922 d
 923 \layout Subsubsection
 924
 925 camera_file_delete
 926 \layout Standard
 927
 928
 929 \series bold
 930 Purpose:
 931 \series default
 932 Delete a file from the camera
 933 \layout Standard
 934
 935
 936 \series bold
 937 Prototype:
 938 \series default
 939 int camera_file_delete (Camera *camera, char *folder, char *filename);
 940 \layout Standard
 941
 942
 943 \series bold
 944 Arguments:
 945 \series default
 946 d
 947 \layout Subsubsection
 948
 949 camera_config_get
 950 \layout Standard
 951
 952
 953 \series bold
 954 Purpose:
 955 \series default
 956 Retrieve the configuration window.
 957 \layout Standard
 958
 959
 960 \series bold
 961 Prototype:
 962 \series default
 963 int camera_config_get (Camera *camera, CameraWidget *window);
 964 \layout Standard
 965
 966
 967 \series bold
 968 Arguments:
 969 \series default
 970 d
 971 \layout Subsubsection
 972
 973 camera_config_set
 974 \layout Standard
 975
 976
 977 \series bold
 978 Purpose:
 979 \series default
 980 Set camera configuration
 981 \layout Standard
 982
 983
 984 \series bold
 985 Prototype:
 986 \series default
 987 int camera_config_set (Camera *camera, CameraSetting *setting, int count);
 988
 989 \layout Standard
 990
 991
 992 \series bold
 993 Arguments:
 994 \series default
 995 d
 996 \layout Subsubsection
 997
 998 camera_capture
 999 \layout Standard
1000
1001
1002 \series bold
1003 Purpose:
1004 \series default
1005 Retrieve live data from the camera
1006 \layout Standard
1007
1008
1009 \series bold
1010 Prototype:
1011 \series default
1012 int camera_capture (Camera *camera, CameraFile *file, CameraCaptureInfo
1013  *info);
1014 \layout Standard
1015
1016
1017 \series bold
1018 Arguments:
1019 \series default
1020 d
1021 \layout Subsubsection
1022
1023 camera_summary
1024 \layout Standard
1025
1026
1027 \series bold
1028 Purpose:
1029 \series default
1030 Retrieve the camera summary information
1031 \layout Standard
1032
1033
1034 \series bold
1035 Prototype:
1036 \series default
1037 int camera_summary (Camera *camera, CameraText *summary);
1038 \layout Standard
1039
1040
1041 \series bold
1042 Arguments:
1043 \series default
1044 d
1045 \layout Subsubsection
1046
1047 camera_manual
1048 \layout Standard
1049
1050
1051 \series bold
1052 Purpose:
1053 \series default
1054 Retrieve the camera user's guide (manual)
1055 \layout Standard
1056
1057
1058 \series bold
1059 Prototype:
1060 \series default
1061 int camera_manual (Camera *camera, CameraText *manual);
1062 \layout Standard
1063
1064
1065 \series bold
1066 Arguments:
1067 \series default
1068 d
1069 \layout Subsubsection
1070
1071 camera_about
1072 \layout Standard
1073
1074
1075 \series bold
1076 Purpose:
1077 \series default
1078 Retrieve information about the camera library
1079 \layout Standard
1080
1081
1082 \series bold
1083 Prototype:
1084 \series default
1085 int camera_about (Camera *camera, CameraText *about);
1086 \layout Standard
1087
1088
1089 \series bold
1090 Arguments:
1091 \series default
1092 d
1093 \layout Subsection
1094
1095 The gPhoto2 I/O Library
1096 \the_end