Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - jplxpto

Pages: [1] 2
1
Reverse Engineering / Canon's CR2 Raw File Format Specification
« on: July 30, 2013, 12:59:31 AM »


http://wildtramper.com/sw/cr2/cr2.html

Code: [Select]
Although not publicly documented by Canon, their CR2 RAW file format specifiction is scattered in bits and pieces across the web. Compiled here is believed to be an accurate specification for the orignal CR2 compression. Because I own the original Canon 5D, this specification reflects its CR2 formatting. Newer 5D versions have other compression varieties such as sRAW (sRAW1, sRAW2, etc.), and these are not supported by this software.
Included here is the CR2 coder/decoder and a zip file of its C-code implementation. The companion Canon CRW Specification may also be of interest. Another good source of CR2 information can be found in a document titled Understanding What is stored in a Canon RAW .CR2 file, How and Why at http://lclevy.free.fr/cr2/.
The specifiction is listed below and is included in the cr2.zip (revised 11/10/08) file as comments of the primary code file Cr2Codec.cpp. The zip file contains the following:
    Cr2Codec.cpp - Primary C-code for CR2 coder/decoder
    Cr2Codec.exe - its sample excutable
    Cr2Codec.h   - its header file
    MakerNote.h  - A few definitions for Canon's TIFF maker-note
    Prop.h       - Properties type definitions
    RawUtl.cpp   - Various raw utilities
    RawUtl.h     - and its header file
    TiffTags.h   - TIFF tag definitions
    TiffUtl.cpp  - Various TIFF utilities
    TiffUtl.h    - and its header file
    getput.cpp   - Low level input/output
    getput.h     - and its header file
    jpeg.h       - Various JPEG definitions
The executable Cr2Codec.exe must be run in a Windows command shell. Executing the command without parameters yields its syntax as follows:
    Usage: Cr2Codec.exe [options] file.cr2 outfile
    Decompress raw image data of file.cr2
      -b: decode then save binary file (default)
      -c: decode then recode file
      -h: decode then create (text) histogram
      -j: extract JPG image 
      -t: decode then save as 8-bit TIFF file
      -T: decode then save as 16-bit TIFF file
    Version 1.0
    Wildtramper.com, Copyright (c), All rights reserved
Although the -t or -T options create a TIFF file from RAW, expect crude colorization. The -j option is useful to extract the embedded JPG file, and it has Canon's as-shot colorization. This JPG is believed to be optimized for the camera's on-board LCD display -- what to heck, it's a quick view.
/***************************************************************************
* The Canon CR2 file format is an encapsulated TIFF shell having 4 IFD sets.
* These IFDs are different versions of the same image.
*
*   +=====================================+ Start of TIFF/CR2 file
*   | TIFF Header |
*   | Size = 8 |
*   +=====================================+
*   | Various TIFF Tags describing File | IFD #1 Segment
*   |   EXIF (TIFF subdirectory) | Canon 5D image size 2496x1664
*   |- - - - - - - - - - - - - - - - - - -|
*   | JPEG data (baseline compression) |
*   +=====================================+
*   | JpegInterchangeFormat | IFD #2 Segment
*   | | unknown image size
*   |- - - - - - - - - - - - - - - - - - -|
*   | JPEG Compressed data |
*   +=====================================+
*   | Few TIFF Tags describing segment | IFD #3 Segment
*   | | Canon 5D image size 384x256
*   |- - - - - - - - - - - - - - - - - - -|
*   | JPEG data (unknown compression) |
*   +=====================================+
*   | Few TIFF Tags describing segment | IFD #4 Segment - RAW image
*   | | Canon 5D image size 4476x2954
*   |- - - - - - - - - - - - - - - - - - -|
*   | JPEG data (lossless compression) |
*   +=====================================+
*
* A sample parsing of these IFDs are:
* sample.cr2: FileID=II, Ver=2A, IFD #1 w/ 14 Tags
*  TagName(TagID,Len,DataOfst) =Value
*  ImageWidth(0100,1,001A)     =2496
*  ImageLength(0101,1,0026)    =1664
*  BitsPerSample(0102,3,00BE)  =8 8 8
*  Compression(0103,1,003E)    =6  {JpegCompression}
*  Make(010F,6,00C4)        ="Canon"
*  Model(0110,D,00CA)        ="Canon EOS 5D"
*  StripOffsets(0111,1,0062)   =82349
*  Orientation(0112,1,006E)    =1  {TopLeft, Normal}
*  StripByteCounts(0117,1,007A)=1030590
*  XResolution(011A,1,00EA)    =72/1 (=72)
*  YResolution(011B,1,00F2)    =72/1 (=72)
*  ResolutionUnit(0128,1,009E) =2  {InchUnits}
*  DateTime(0132,14,00FA)      ="2006:09:24 07:14:52"
*  Exif(8769,1,00B6)        =270
*   TagName(TagID,Len,DataOfst) =Value
*   ExposureTime(829A,1,0264) =1/80 (=0.0125)
*   FNumber(829D,1,026C) =4/1 (=4)
*   ExposureProgram(8822,1,0130) =3
*   ISOSpeedRatings(8827,1,013C) =100
*   ExifVersion(9000,4,0148) =48 50 50 49
*   DateTimeOriginal(9003,14,0274) ="2006:09:24 07:14:52"
*   DateTimeDigitized(9004,14,0288) ="2006:09:24 07:14:52"
*   ComponentsConfiguration(9101,4,016C) =1 2 3 0
*   ShutterSpeedValue(9201,1,029C) =417792/65536 (=6.375)
*   ApertureValue(9202,1,02A4) =262144/65536 (=4)
*   ExposureBiasValue(9204,1,02AC) =0/1 (=0)
*   MeteringMode(9207,1,019C) =5
*   Flash(9209,1,01A8) =16
*   FocalLength(920A,1,02B4) =24/1 (=24)
*   MakerNote(927C,12548,02BC) =29 0 1 0 3 0 46 0 0 0 30 4 0 0 2 ...
*   UserComment(9286,108,12804) =0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...
*   FlashpixVersion(A000,4,01D8) =48 49 48 48
*   ColorSpace(A001,1,01E4) =1
*   PixelXDimension(A002,1,01F0) =4368
*   PixelYDimension(A003,1,01FC) =2912
*   Interoperability(A005,1,0208) =76044
*   FocalPlaneXResolution(A20E,1,1292A)  =4368000/1415 (=3086.93)
*   FocalPlaneYResolution(A20F,1,12932)  =2912000/942 (=3091.3)
*   FocalPlaneResolutionUnit(A210,1,022C)=2  {InchUnits}
*   CustomRendered(A401,1,0238) =0
*   ExposureMode(A402,1,0244) =0
*   WhiteBalance(A403,1,0250) =0
*   SceneCaptureType(A406,1,025C) =0
* sample.cr2: FileID=II, Ver=2A, IFD #2 w/ 2 Tags
*  TagName(TagID,Len,DataOfst)       =Value
*  JPEGInterchangeFmt(0201,1,12944)   =76348
*  JPEGInterchangeFmtLen(0202,1,12950)=6001
* sample.cr2: FileID=II, Ver=2A, IFD #3 w/ 11 Tags
*  TagName(TagID,Len,DataOfst) =Value
*  ImageWidth(0100,1,12962) =384
*  ImageLength(0101,1,1296E) =256
*  BitsPerSample(0102,3,129E2) =8 8 8
*  Compression(0103,1,12986) =6  {JpegCompression}
*  Photometric(0106,1,12992) =2  {RGB}
*  StripOffsets(0111,1,1299E) =1112939
*  SamplesPerPixel(0115,1,129AA)=3
*  RowsPerStrip(0116,1,129B6) =256
*  StripByteCounts(0117,1,129C2)=294912
*  PlanarConfig(011C,1,129CE) =1  {ChunkyFormat}
*  UndefinedTag(C5D9,1,129DA) =2
* sample.cr2: FileID=II, Ver=2A, IFD #4 w/ 6 Tags
*  TagName(TagID,Len,DataOfst) =Value
*  Compression(0103,1,129F2) =6  {JpegCompression}
*  StripOffsets(0111,1,129FE) =1407851
*  StripByteCounts(0117,1,12A0A)=9920742
*  UndefinedTag(C5D8,1,12A16) =1
*  UndefinedTag(C5E0,1,12A22) =1
*  UndefinedTag(C640,3,12A36) =1 2238 2238
*
* The first IFD is a low pixel count JPEG image, and for the Canon 5D its image
* size is 2496x1664.  Also included as part of the first IFD are an assortment
* of image and shot data, such as Make, Model, and abundant EXIF information.
* The EXIF information is itself an IFD subdirectory, and within the EXIF
* directory is the Tag 'MakerNote' which contains more shot information such a
* lens type and serial numbers.  MakerNote is has a TIFF like IFD structure,
* but the "TagType" field follows different rules, see below.
*
* The second IFD is another JPEG rendered image, and it is described by two
* TIFF Tags.  It is not clear what the purpose of this image, but noting that
* the section size is very small (6001 bytes in the sample), then the image
* dimensions must also be small.  It is likely a thumbnail.  Peeking into this
* section one finds four JPEG markers: SOI (start of image), DHT (define
* Huffmann tables), DQT (define quantization tables), and SOS (start of scan).
* There is no SOFn marker to identify the image dimensions.
*
* The third IFD is another JPEG rendered image.  In this case there are several
* TIFF tags, and these give the size of the image as 384x256.  Certainly a
* small image. Although the compression is tagged as JPEG, it is believed this
* is not the case since (1) the image data contains no JPEG markers and (2) the
* size of the image data is exactly three times the rows times columns (294912
* = 3x384x256).  Thus, it is believed the image data is uncompressed RGB.
*
* The forth IFD is the sweet spot of the CR2 file.  It is a lossless JPEG
* compressed image of dimensions the size of the camera's photo sensor.  Canon
* adds three proprietary TIFF tags which are of unknown meaning, except the Tag
* 0xC640 with values for the sample file {1, 2238, 2238} are described by Dave
* Coffin's as being 'slice' information. Peeking into the JPEG code of this
* section one finds the following markers:  SOI (start of image), DHT (define 2
* Huffmann tables), SOF3 (start of frame for lossless, sequential, non-
* differential, Huffman coding), and SOS (start of scan).  There are no RSTm
* (reset modulo-8) markers.  The section is located at the end of the file, and
* it is this location which makes it easy to replace a 'valued added' version
* of the image with the original.
*
* Decoding lossless JPEG is similar (and simpler) to decoding CRW images.  Like
* CRW images, the compressed data is organized as a concatenation of a Huffmann
* code (i.e. HufCode or codeword) followed by a variable length difference code
* (i.e. Diff) bit stream as shown below.  Unlike CRW images the HufCode only
* conveys the number of bits required by Diff.
*
*   +----------------+-------------+
*     ... | HufCode[nBits] | Diff[nBits] | ...
*   +----------------+-------------+
*
* Like CRW images, the compressed data is row organized with interleaved BAYER
* grid array data for that row.  So with a BAYER grid of RG/GB, the even rows
* has interleaved HuffCode/Diff data for ...RGRGRG..., while the odd rows it is
* ...GBGBGB...
*
* Unlike CRW images, there are no 64 pixel blocks, rather it is the width of a
* row. The initial values at the beginning of each row is the RG/GB value of
* its nearest previous row beginning.  For the first row, the initial row
* values are 1/2 the bit range defined by the precision.  Thus for 12-bit
* precision:
*     Pix[Row, Col] = Val
*     Pix[0,0] = (1 << (Precision - 1)) + Diff
*     Pix[0,1] = (1 << (Precision - 1)) + Diff
* and for n >= 1
*     Pix[n,0] = Pix[n-2,0] + Diff
*     Pix[n,1] = Pix[n-2,1] + Diff
* while for any other Row/Column
*     Pix[R,C] = Pix[R,C-2] + Diff
*
* Also unlike CRW images the mapping of decoded rows into the image buffer is
* divided into four quadrants. It is unclear why Canon chose this method, but
* nonetheless it's there.  The RAW image is divided into 4 equal sized
* quandrants:
*     +------------------------+------------------------+ RAW Image
*     |        | |
*     |        Quad 0        | Quad 1 |
*     |        | |
*     +------------------------+------------------------+
*     |        | |
*     |        Quad 2        | Quad 3 |
*     |        | |
*     +------------------------+------------------------+
* The finished image inteleaves quadrants row segments 0/1 and interleaves
* quandrant rows segments 2/3 while combined quandrants 0/1 is located to the
* left and combined quadrants 2/3 are concatenated to the right:
*     +------------------------+------------------------+ Finished Image
*     |      Quad0.Row0        |      Quad2.Row0 |
*     |      Quad1.Row0        |      Quad3.Row0 |
*     |      Quad0.Row1        |      Quad2.Row1 |
*     |      Quad1.Row1        |      Quad3.Row1 |
*     | etc        |   etc |
*     |      Quad0.RowN        |      Quad2.RowN |
*     |      Quad1.RowN        |      Quad3.RowN |
*     +------------------------+------------------------+
* So it can be said that Quads 0 and 2 contain the same two BAYER grid colors
* and Quads 1 and 3 contain the other two BAYER grid colors.
*
* Like CRW images, the actual difference value contained in the Diff[nBits] is
* organized loosely as a signed magnitude number, but has its own specific
* rules.  First, it should be noted that the value of nBits determines the
* range of the number. As an example if nBits = 3, then the magnitude (of a
* DiffVal that can be +/- this magnitude) is 4 <= magnitude <= 7, or more
* specifically:
*
*      (1 << (nBits - 1)) <= DiffVal <=  ((1 << nBits) - 1)    // + DiffVal
*     -(1 << (nBits - 1)) >= DiffVal >= -((1 << nBits) - 1)    // - DiffVal
*
* If the most significant bit (MSB) of Diff[nBits] is one, then DiffVal is
* positive and has a magnitude directly represented by binary value of these
* bits.  If however, the MSB is zero, then DiffVal is negative and has a
* magnitude that is the compliment of these bits.  As an example if
* Diff[nBits=3] = 101, then DiffVal is 5, whereas if Diff[nBits=3] = 001, then
* DiffVal is -6.
*
* The size of the decompressed image is slightly larger than the final image
* size.   A few extra 'black' rows added on top and bottom and a few extra
* 'black' columns may be added to the left and right (but none have been
* observed).  These 'black' rows/columns along with a few additional RG/GB
* rows/columns make up a set of Trim rows/columns which are ultimately deleted
* to get the final 'as advertised' RAW image size.  Other than noting that some
* of the Trim is 'black,' it is beyond the scope of this description to
* determine the method to find the optimum Trim rows/columns.  As an
* observation, customized Trim may (or it may not) be encoded in the Firmware
* of camera so that that the final calibration of the image sensor reflects
* this Trim in a manner that places the center of the image sensor at the lens
* center.
*
* TIFF MakerNote:
*
* The TIFF Tag called MakerNote may be used by a manufacturer to embed any type
* of information.  Canon uses this segment.  Parsing of this proprietary
* segment follows the following data structures:
*
* typedef struct
* {
*     tU16  TagID;
*     tU16  TagType;
*     tU32  TagCnt;
*     tU32  DataOfst;
* } tREC;
*
* typedef struct
* {
*     tU16  numRecords;
*     tREC  RecordDir[numRecords];
*     tU8   Heap[];
* } tMAKERNOTE;
*
* The ordering of bytes is 'little endian' (Intel), but this is probably a
* function of the overall TIFF byte ordering.  The first two bytes identifies
* the number of records (numRecords), and this is followed by the record
* directory (RecordDir), and this if followed by the Heap of various data.
* Each record directory consists of 12 bytes with 4 fields.  The first field is
* the tag identification (TagID), followed by the tag type (TagType), followed
* by the tag count (TagCnt), and finally followed by data offset (DataOfst) or
* if the TagType is 4 then this field is immediate data.  This format closely,
* but not exactly, follows standard TIFF.
*
* The TagType fields may have the following meaning:
* Type = 2:  ASCII data
* Type = 3:  tU16 data
* Type = 4:  immediate data
* Type = 7:  unknown
*
* The TagID fields may have the following meaning:
* TagType = 0x01: Camera settings 1
* TagType = 0x04: Camera settings 2
* TagType = 0x06: Camera model (string)
* TagType = 0x07: Camera F/W version (string)
* TagType = 0x08: Image number ???
* TagType = 0x09: Owner name (string)
* TagType = 0x0C: Camera serial number (immediate data number)
* TagType = 0x0F: Custom functions
* TagType = 0x95: Lens model (string)
*
* The following is an sample extraction:
*
* 02BC: 1D 00  =NumRecord
* -ID-- -Type  ---Cnt--- --Ofst---    #
* 02BE: 01 00 03 00 2E 00 00 00 1E 04 00 00   1 - CameraSettings1
* 02CA: 02 00 03 00 04 00 00 00 7A 04 00 00   2
* 02D6: 03 00 03 00 04 00 00 00 82 04 00 00   3
* 02E2: 04 00 03 00 22 00 00 00 8A 04 00 00   4 - CameraSettings2
* 02EE: 06 00 02 00 0D 00 00 00 CE 04 00 00   5 - "Canon EOS 5D"
* 02FA: 07 00 02 00 18 00 00 00 EE 04 00 00   6 - "Firmware Version 1.1.0"
* 0306: 09 00 02 00 20 00 00 00 06 05 00 00   7 - OwnerName
* 0312: 0C 00 04 00 01 00 00 00 1F 15 CE 42   8 - CameraSerialNum = 0x42CE151F
* 031E: 0D 00 07 00 00 04 00 00 26 05 00 00   9
* 032A: 0F 00 03 00 17 00 00 00 76 09 00 00   a - CustomFunctions
* 0336: 10 00 04 00 01 00 00 00 13 02 00 80   b
* 0342: 12 00 03 00 28 00 00 00 26 09 00 00   c
* 034E: 13 00 03 00 04 00 00 00 A4 09 00 00   d
* 035A: 15 00 04 00 01 00 00 00 00 00 00 A0   e
* 0366: 19 00 03 00 01 00 00 00 01 00 00 00   f
* 0372: 83 00 04 00 01 00 00 00 00 00 00 00  10
* 037E: 93 00 03 00 10 00 00 00 AC 09 00 00  11
* 038A: 95 00 02 00 40 00 00 00 CC 09 00 00  12 = "EF24-105mm f/4L IS USM"
* 0396: 96 00 02 00 10 00 00 00 0C 0A 00 00  13
* 03A2: A0 00 03 00 0E 00 00 00 1C 0A 00 00  14
* 03AE: AA 00 03 00 05 00 00 00 38 0A 00 00  15
* 03BA: B4 00 03 00 01 00 00 00 01 00 00 00  16
* 03C6: E0 00 03 00 11 00 00 00 42 0A 00 00  17
* 03D2: D0 00 04 00 01 00 00 00 00 00 00 00  18
* 03DE: 01 40 03 00 1C 03 00 00 64 0A 00 00  19
* 03EA: 02 40 03 00 66 2B 00 00 9C 10 00 00  1a
* 03F6: 05 40 07 00 88 C0 00 00 68 67 00 00  1b
* 0402: 08 40 03 00 03 00 00 00 F0 27 01 00  1c
* 040E: 09 40 03 00 03 00 00 00 F6 27 01 00  1d
*
* Heap
* 0410:    00 00 00 00 00 5C 00    ....\.
* 0420: 02 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00  ................
* 0430: 07 00 00 00 01 00 00 00 00 00 00 00 FF 7F FF 7F  ................
* 0440: 03 00 02 00 00 00 03 00 FF FF 00 00 69 00 18 00  ............i...
* 0450: 01 00 80 00 20 01 00 00 00 00 00 00 00 00 FF FF  .... ...........
* 0460: FF FF FF FF 00 00 00 00 00 00 00 00 FF FF FF FF  ................
* 0470: 00 00 00 00 FF 7F FF FF FF FF 02 00 69 00 C9 05  ............i...
* 0480: D2 03 00 00 00 00 00 00 00 00 44 00 00 00 A0 00  ..........D.....
* 0490: E4 00 B4 00 D4 00 00 00 00 00 03 00 00 00 08 00  ................
* 04A0: 08 00 95 00 00 00 00 00 00 00 00 00 00 00 01 00  ................
* 04B0: 00 00 00 00 B4 00 D0 00 91 00 00 00 00 00 F8 00  ................
* 04C0: FF FF FF FF FF FF FF FF 00 00 00 00 00 00 43 61  ..............Ca
* 04D0: 6E 6F 6E 20 45 4F 53 20 35 44 00 00 00 00 00 00  non EOS 5D......
* 04E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 46 69  ..............Fi
* 04F0: 72 6D 77 61 72 65 20 56 65 72 73 69 6F 6E 20 31  rmware Version 1
* 0500: 2E 31 2E 30 00 00 00 00 00 00 00 00 00 00 00 00  .1.0............
* 0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
***************************************************************************/

5
General Help Q&A / "How To Ask Questions The Smart Way"
« on: January 12, 2013, 06:29:17 PM »

I found this document that seemed useful for many of us.

I recommend reading it. I've also started this task.

http://www.catb.org/~esr/faqs/smart-questions.html

6
General Chat / Merry Christmas and Happy New Year!!!
« on: December 23, 2012, 10:13:17 PM »
Merry Christmas and Happy New Year!!!

8
User Introduction / The Martians say Hello here!
« on: December 08, 2012, 07:23:33 PM »
Yes, I've heard say that there is life on Mars. I believe in scientists.

If there is life on Mars, they must already have knowledge of our forum and one of them must already use Magic Lantern.

If you are from Mars, put a record here of his passing.

Tell us what you think of us ... and do the same with the rest of the world even if they are from other planets.

I'm kidding, but life must be brought to play.

Yes, I am a little crazy but ... we all have a little.

9
Reverse Engineering / Canon EF lens mount - Communication protocol
« on: December 08, 2012, 02:42:44 AM »

"
The communication protocol between the camera is 8-data-bit, 1-stop-bit SPI (mode 3). The pins, from right to left on the lens, are:

Canon EF mount pins[2][17]
Name   Function   Notes
VBat   +6 volts to power internal lens focus motors   
Present on all EOS bodies and lenses

P-Gnd   Power ground
P-Gnd
VDD   +5.5 volts Digital logic power
DCL   Data from camera to the lens (MOSI)
DLC   Data from the lens to the camera (MISO)
LCLK   Camera body generated clock signal (SCLK, CPOL=1)
D-GND   Digital logic ground
COM1   Teleconverter common[18][19][20]   
Only on most L-series and some macro lenses

EXT0   Short to COM1 for 'Life Size Converter' and x1.4 teleconverter
EXT1   Short to COM1 for x2 and x1.4 teleconverter
"

http://en.wikipedia.org/wiki/Canon_EF_lens_mount#Stepping_motor

10
http://world.std.com/~qqi/labslave/rproxy.html

"
gdbproxy - a remote proxy program for the GNU debugger, GDB
===========================================================

gdbproxy is an open source remote proxy program for the GNU debugger, GDB.
Its licence is similar to the BSD licence, so it can be used to build
closed source interfaces between GDB and proprietary target debug
environments.

gdbproxy is based on the Open Source program rproxy, which can be found at:

http://world.std.com/~qqi/labslave/rproxy.html

What is gdbproxy actually for?
==============================

Here was our problem:

One of the nice features of the Texas Instruments MSP430 microcontrollers
are their on-chip emulation facilities. These are usually accessed through
a TI JTAG Flash Emulation Tool (FET) attached to a PC's parallel port. To
make the GNU debugger (GDB) work with this, an interface between GDB and
the FET was needed.

TI made their MSP430 debug interface code available to the developers of
the MSP430 port of the GNU toolchain. However, for commercial reasons, TI
would not allow the full version of their interface library to be released
as open source code. It would reveal things about the working of the MSP430,
which they consider commercially confidential. The licencing of the GNU tools
does not permit linking against a closed source library. This is where
gdbproxy fits in.....

GDB supports remote debugging through serial or TCP/IP connections.
gdbserver is a remote debug proxy program for these remote debug
environments, supplied as part of the GDB package. This is licenced
under the GPL, and cannot be mingled with closed source code. gdbproxy
provides similar functionality, but is licenced under a BSD style
licence. It does, therefore, permit linking with closed source
code. gdbproxy has, therefore, been adapted to provide a TCP/IP to
MSP430 FET interface for GDB. I think it is also better structured for
isolating the functionality associated with a specific target in one simple
module. It is, therefore, easier to adapt to new target environments.

The source for the generic version of gdbproxy continues to be open source,
released under the same licence as the original gdbproxy program. Only the
MSP430 specific code remains closed source. The skeleton target interface,
supplied as open source, is the same code on which the MSP430 support is
built. It should be easy to adapt this to provide support for many targets.

What can gdbproxy do for me?
============================

If you are trying to provide GDB support for a target which requires the
use of proprietary code, gdbproxy may be just right for you. I also think
gdbproxy is a better basis for building completely open GDB debug interfaces,
too. In gdbproxy, all target specific code is kept in one tidy module. A
skeleton for that module is provided, so it should be quite a quick task to
get support for a new environment up and running.  Look through the code for
"TODO" markers that highlight what needs changing for new target support.

If you are using the mspgcc port of the GNU tools for the Texas Instruments
MSP430 you definitely want the MSP430 version of gdbproxy.

How can I try it out?
=====================

gdbproxy builds OK on Linux and with MinGW32 or Cygwin on Windows. It uses
the GNU autoconf and automake tools, so to build it use:

by Steve Underwood <steveu@coppice.org>
"

11
General Development Discussion / FFmpeg a multimedia framework
« on: November 24, 2012, 07:29:40 PM »
To the knowledge of those who have not seen ...

http://ffmpeg.org

http://ffmpeg.org/about.html



"
About FFmpeg

FFmpeg is the leading multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything that humans and machines have created. It supports the most obscure ancient formats up to the cutting edge. No matter if they were designed by some standards committee, the community or a corporation. It contains libavcodec, libavutil, libavformat, libavdevice, libswscale and libswresample which can be used by applications. As well as ffmpeg, ffserver, ffplay and ffprobe which can be used by end users for transcoding, streaming and playing

The FFmpeg project tries to provide the best technically possible solution for developers of applications and end users alike. To achieve this we combine the best free software options available. We slightly favor our own code to keep the dependencies on other libs low and to maximize code sharing between parts of FFmpeg. Wherever the question of "best" cannot be answered we support both options so the end user can choose.

Security is a high priority and code review is always done with security in mind. Though due to the very large amounts of code touching untrusted data security issues are unavoidable and thus we provide as quick as possible updates to our last stable releases when new security issues are found.
"

12
General Development Discussion / SD Formatter 3.1 for SD/SDHC/SDXC
« on: November 21, 2012, 02:11:11 AM »

To the knowledge of all.

ever suspicious of a problem to format your SD / SDHC / SDXC, you can test this application.

https://www.sdcard.org/downloads/formatter_3/

13
Feature Requests / ML Memory Checker
« on: November 06, 2012, 11:08:22 PM »

I already have several years of professional experience. During these years I had often problems with various hardware equipment. In my experience, intermittent faults have always been the most difficult problems to diagnose. In most cases I found that the source of the problems were due to faults or defects in memories. These defects typically are due to some memory locations. The errors are fixed in position, but as dynamic memory managers do not always assign the same blocks, errors appear random. Typically errors occur in applications that consume more memory because it increases the probability that use a memory location damaged.

I believe that the ML does not have a memory tester.

I think we could allocate large blocks of memory, and apply some simple algorithms used by these tools (read, write, re-read what was written, and compare, etc.)

I remembered this when I saw the following post:

http://www.magiclantern.fm/forum/index.php?topic=3500.msg18044;topicseen#msg18044

14
Feature Requests / Virtual Keyboard for ML
« on: November 06, 2012, 12:49:16 AM »

I was seeing the manual of equipment WFT-E3, and I remembered again.

We should create a Virtual Keyboard for ML.

This virtual keyboard would be very useful to perform many kinds of operations in the GUI.
With a little work one day may be used with the touch screen of the new camera models.

15
Does anyone know this software or this guy?


http://www.reikan.co.uk/focalweb/

http://www.reikan.co.uk/photography/blog/?page_id=2

http://www.reikan.co.uk/focalweb/index.php/about-reikan/


This guy seems to have an interesting software.

I think he would be an excellent partnership for Magic Lantern.

They may be willing to exchange a few words with us.

Maybe we can add some functionality to facilitate and revolutionize the calibration of the cameras.

16
User Introduction / Portuguese language ML users, say Hello here!
« on: November 03, 2012, 06:02:36 PM »

Hi to all

I want to see how many users of Portuguese language's here.


Olá a todos

Eu quero ver quantos utilizadores de lingua portuguesa estão aqui.

17
General Chat / Crossover - Free
« on: October 31, 2012, 12:00:59 PM »

19
Camera-specific discussion / Canon 350D
« on: October 21, 2012, 02:08:54 PM »
Hello everybody

Besides from me, there must be someone else who has a 350D.

Maybe one day I can enjoy a little trying to port ML to 350D.

For now I am busy with the 40D. Maybe after I think about it ...

20
General Chat / Joel Santos : A Portuguese photographer
« on: October 15, 2012, 11:44:28 PM »

A Portuguese photographer. I love your work.

http://www.joelsantos.net/Joel_Santos_-_Photography/Home.html

22
General Development Discussion / Error compiling for 40D
« on: October 04, 2012, 12:25:23 AM »


../../src/bmp.c: In function 'bmp_draw_scaled_ex':
../../src/bmp.c:1220:27: warning: pointer targets in initialization differ in signedness [-Wpointer-sign]
../../src/bmp.c:1276:27: warning: pointer targets in initialization differ in signedness [-Wpointer-sign]
[ CC       ]   font-dyn.o
[ CC       ]   config.o
[ CC       ]   menu.o
../../src/menu.c: In function 'handle_ml_menu_keys':
../../src/menu.c:2204:5: error: duplicate case value
../../src/menu.c:2187:5: error: previously used here
make: *** [menu.o] Error 1


parent: 4885:073d5b5731eb

23
General Development Discussion / libyuv
« on: October 01, 2012, 11:10:58 PM »

Maybe you already know but, i had knowledge of the existence of this library and decided to share with you.

http://code.google.com/p/libyuv/

24
General Development Discussion / How to run Magic Lantern into QEMU?!...
« on: September 23, 2012, 08:29:02 PM »
How to run Magic Lantern into QEMU?!...

I would like to know if anyone has ever launched Magic Lantern on QEMU. I've used it a few times, and it seemed to me that however limited it may be useful to conduct some tests.

If anyone has knowledge about this subject, thank you give me some tips that may also be useful for other developers.

Thank you.



Short answer: check the README and the developer guide.

25
General Development Discussion / How to get Stubs for standard libraries?
« on: September 23, 2012, 08:03:43 PM »
How can I get the list of stubs of functions belonging to standard libraries and VxWorks?

Pages: [1] 2