Found the lens decoder table in 1.09 firmware

[cbretteville]

Advertisement (gone after registration)

There are more than 63 different optical formulaes that makes up the current and past set of Leica lenses. They had to draw the line somewhere. Why they chose 'only' 6 bits of encoding I can't say, but it isn't some random number picked out of a hatt. Someone decided 63 was enough. Leave some for future lens designs, subtract X for the current lens cataloge and you're left with y for the back cataloge. Select the most commenly used lenses. Seven dots would have increased it to 127 and 8 to 254 optical formulae.

 

The answer to 'why' can only be answered by Solms.

[Advertisement]

The Leica Q3 is available for pre-order at B&H Photo Video and Adorama

[mjh]

one entry is 72 bytes long.

But not every entry – most are longer than 72 bytes.

[cbretteville]

Michael,

I think you're mistaken here. I read this as a table of 64 elements each being 72 bytes long. The reason why some lens names appear further appart in the table is simply that there are empty slots. See the first post in this thread from Dec 19, just after 1.09 was released: http://www.leica-camera-user.com/digital-forum/11891-m8-v1-09-firmware-supported-lenses.html

[mjh]

I read this as a table of 64 elements each being 72 bytes long. The reason why some lens names appear further appart in the table is simply that there are empty slots.

Ah, I see. Yes, you are right.

 

Okay, so by now we know where the lens name and part number, the focal length, and the lens code is stored. What about the other values (as far as they are different from zero)?

[cbretteville]

There are very few values at all. One unknown is the number increasing by four for each entry. That smells to me like an index into a second table. Unless the max aperture for each lens is retreived from the lens name - this is perfectly feasible, but seems like an overcomplicated way of doing it, it must me stored somwhere. The data must be coded as a rational data type and it makes more sence to store this as data ready to use and just stuff it in the exif block when the file is written. The data is a fixed value for each lens and as such it dosen't make sence to calculate it for each file written.

[scott kirkpatrick]

There are very few values at all. One unknown is the number increasing by four for each entry. That smells to me like an index into a second table. Unless the max aperture for each lens is retreived from the lens name - this is perfectly feasible, but seems like an overcomplicated way of doing it, it must me stored somwhere. The data must be coded as a rational data type and it makes more sence to store this as data ready to use and just stuff it in the exif block when the file is written. The data is a fixed value for each lens and as such it dosen't make sence to calculate it for each file written.

 

What is rational data? It makes sense that both writing into the EXIF and writing on the LCD in the INFO screen settings are supported with information that can be copied and doesn't have to be calculated. The INFO screen can be supplied with ascii characters copied from the lens title. But in the case of the 28/2.8 bug, its max aperture doesn't appear in either INFO or EXIF. So I'm not sure where the two pieces of information are drawn from.

 

scott

[mjh]

Advertisement (gone after registration)

There are very few values at all. One unknown is the number increasing by four for each entry. That smells to me like an index into a second table.

Isn’t that just the lens code x 4? Of course, the lens code is implicit in the entry’s index into the table, so it may not be necessary to store it explicitly, but that’s what it looks like.

 

There is another non-zero value five bytes from the start of the string; it’s mostly 1 but sometimes 2, 3, or 4 (I haven’t checked all the entries).

 

BTW: entry #40 should be the Macro-Adaptor-M (14409), but the table lists it as “4.0/90; 14409”. I suppose it’s an error and “4.0/90” was copied from entry #39. Incidentally, entry #40 appears to be the only one with a non-zero byte (6) preceding the string.

[cbretteville]

What is rational data?

 

'Rational' is a data type where a fraction is stored as two integers (signed or unsigned) one element is the numerator and the other is a denominator. This type is extensively used in EXIF and TIFF tags.

 

- Carl

[cbretteville]

BTW: entry #40 should be the Macro-Adaptor-M (14409), but the table lists it as “4.0/90; 14409”. I suppose it’s an error and “4.0/90” was copied from entry #39. Incidentally, entry #40 appears to be the only one with a non-zero byte (6) preceding the string.

 

Could be that they thought you can't really use the macro adapter without the 90/4. There is room enough so they could have quaified it better.

[scott kirkpatrick]

'Rational' is a data type where a fraction is stored as two integers (signed or unsigned) one element is the numerator and the other is a denominator. This type is extensively used in EXIF and TIFF tags.

 

- Carl

 

I've seen that in very literal-minded decodings of EXIF, say for shutter speed, sometimes accompanied by its decimal equivalent to two digits precision. What is its advantage? While it avoids zeros it would seem less accurate.

 

scott

[scott kirkpatrick]

 

There is another non-zero value five bytes from the start of the string; it’s mostly 1 but sometimes 2, 3, or 4 (I haven’t checked all the entries).

 

 

Is that the value that seems to be showing the desired frame line selector position? The little unicode symbols looked rather like left, center and right, and they corresponded exactly with the choice of 28/90, 50 or 24/35 for the lens in that row.

 

scott

[mjh]

What is its advantage? While it avoids zeros it would seem less accurate.

Some shutter speeds can be represented exactly using a rational data type, but not as a floating point number.

[mjh]

Is that the value that seems to be showing the desired frame line selector position?

Let’s see – we’ve got:

 

1: 21 mm, 28 mm, 90 mm, 135 mm, WATE

 

2: 24 mm, 35 mm

 

3: 50 mm, 75 mm

 

4: TE

[scott kirkpatrick]

Confirmed. I'm intrigued that the TE is in a class by itself.

 

scott

[scott kirkpatrick]

If we can figure out where the vignetting corrections are done -- is there a different curve for every lens, or do the lenses map into a smaller set of generic correction curves, for example, one for each focal length (and who knows what for the TE's)? Sean Reid thinks there are differences between the handling of the two 28's currently in production that he tested, for example, but the experimental variations make it hard to really prove this. There are some confusing aspects to the results, such as a stronger correction to the more telecentric lens. It would be nice to have some insight into how this is done.

 

scott

[cbretteville]

Great work on the other values guys!

 

I've seen that in very literal-minded decodings of EXIF, say for shutter speed, sometimes accompanied by its decimal equivalent to two digits precision. What is its advantage? While it avoids zeros it would seem less accurate.

The decoding you see will depend on two separate programmers. The first is the person who wrote the firmware that reads the shutter speed from the camara's electronics, encodes it as a rational value and stuffs it in the appropriate exif/tiff tags. Then on the decoding end you're left to the discression of the programmer that writes the decoder.

 

Adding to the confusion and this may explain why you see different values is that fact that for shutter speed information there are two tags and guess what they're different: One is called "Shutter speed" the other one is "Exposure time". Both are stored as rational but coded differently. Why we can only guess, but these tags are the result of an evoultionary process and someone thought the first one wasn't what they needed and decided to come up with another way of doing it.

 

"Shutter speed" is the most complex and ursually the more acurate. This fraction calculated as 'float' numeratior/denominator, the resulting value is X. Then calculate 2 to the power of X and get Y. Then you display the final value as "1/Y". The programmer has to chose the number of Y's digits to display.

 

"Exposure time" is simply a fraction. to display do the divison and get X. Display as 1/X, again chosing the digits to display.

 

An example from a DNG shot with an M8:

Exposure time was stored as 100000/2777 = 360.101 - display as "1/360 sec"

 

Shutter speed was stored as 557056/65536 = 8.500. 2 to the power of 8.500 = 362.03867196751236 - display as "1/362 sec" or "1/362.039 sec" if you're really anal.

 

Exif tags are a mess! But it is what we have, so we have to live with them. Luckily most people dosen't want the pain of diving into all this but, if they care at all, are content with seing their photograph was shot at "1/360 sec".

 

- Carl

[scott kirkpatrick]

Aha -- a horse designed by a comittee, or something for everyone! That explains why the multiple statements about exposure time that I see in EXIF can disagree by so much. I think I would tend to believe the one coded by the camera guy over the one decoded by the RAW file developer. Or is that too simplistic?

 

I notice in your example, it took 11 bytes to encode 1/360 as a rational, and it could have been stored quite accurately in 2. So there must be some other reason besides saving bytes. In the example, perhaps there is a 100 KHz counter running that completed 2777 cycles, and the output simply copies the counter. But I've seen much smaller numbers encoded, which would involve some computation.

 

scott

[mjh]

If we can figure out where the vignetting corrections are done -- is there a different curve for every lens, or do the lenses map into a smaller set of generic correction curves, for example, one for each focal length (and who knows what for the TE's)?

There may be a jump table stored somewhere else, with an entry for each lens, pointing to a subroutine. To handle each lens, the firmware would just call the subroutine associated with the lens – which may or may not be the same as the subroutine for another lens – which will perform the necessary corrections. In this case, the corrections could be highly individual and arbitrarily complex – as complex as they need to be.

[Advertisement]

Hallo,

Look here: Interesting Leica gear

[mjh]

I notice in your example, it took 11 bytes to encode 1/360 as a rational, and it could have been stored quite accurately in 2. So there must be some other reason besides saving bytes.

The EXIF standard seems to prefer logarithmic over linear scales. Logarithmic APEX units are also used for specifying aperture and brightness values. But sometimes there are linear alternatives, so we’ve got ApertureValue and ShutterSpeedValue (logarithmic) versus FNumber and ExposureTime (linear). All these numbers are stored as fractions.

[cbretteville]

Aha -- a horse designed by a comittee, or something for everyone! That explains why the multiple statements about exposure time that I see in EXIF can disagree by so much. I think I would tend to believe the one coded by the camera guy over the one decoded by the RAW file developer. Or is that too simplistic?

Love that term 'horse designed by comitee' seems very acurate indeed, because with the fab. marker notes these number can be found even further times depending on the camera. Its probably a bit simplistic as both sets of numbers were stuffed in the file by the camara guy. And he may have to do that to be complient with the design of the 'horse'.

 

I notice in your example, it took 11 bytes to encode 1/360 as a rational, and it could have been stored quite accurately in 2. So there must be some other reason besides saving bytes. In the example, perhaps there is a 100 KHz counter running that completed 2777 cycles, and the output simply copies the counter. But I've seen much smaller numbers encoded, which would involve some computation.

The data part of one rational number occupy 8 bytes - four bytes (a long) each for the numerator and denominator. Incidently of the two used in my example one is a signed and one is an unsigned rational. Exactly what the camera guy decides to store is up to his/her discression. I've also got an M8 dng somwhere that was shot with the shutter speed set to a value (say 1/250) and the Exosure time tag reflects this, it comes out as a perfect 1/250. The Shutter speed tag gives a value of 1/256 which is probably the actual time the shutter was open. On the other hand the camera guy could have written the same base data into both tags, just encoded differently.