Pentax makernotes Tag 0x0062

Beholder3 · February 23, 2013, 08:18:21 AM

Hi,

a forum user has decoded the Pentax makernotes Tag 0x0062:
http://www.dslr-forum.de/showthread.php?t=1228782
(best use google translate)

Maybe you add this.

Phil Harvey · February 23, 2013, 08:40:21 AM

Thanks for this post.

I figured this out some time ago, but hadn't added the tag yet, partly because I don't know what to call it. Here is my comment from Pentax.pm:

Code Select

# 0x0062 - int16u: 1 (K10D,K200D,K-m,K2000), 3 (K20D), 4 (K-7), 5 (K-x), 6 (645D), 7 (K-r), 8 (K-5)

I will think about this. Do you have any suggestions for a tag name? It is a bit like the Canon CameraType tag:

248 => 'EOS High-end',
250 => 'Compact',
252 => 'EOS Mid-range',
255 => 'DV Camera',

But not quite the same.

- Phil

Beholder3 · February 23, 2013, 09:40:43 AM

It seems to be Sensorr generation. Cameras with the same sensors get the same tag. And newer cameras get higher numbers.
The first generation simply didnnt have this tag.

Phil Harvey · February 23, 2013, 01:13:14 PM

Great, thanks. I'll call it SensorType then.

- Phil

Phil Harvey · February 23, 2013, 07:30:00 PM

Here is the tag definition:

0x0062 => {
Name => 'SensorType',
Writable => 'int16u',
PrintConv => {
1 => '1 (K10D,K200D,K2000,K-m)',
3 => '3 (K20D)',
4 => '4 (K-7)',
5 => '5 (K-x)',
6 => '6 (645D)',
7 => '7 (K-r)',
8 => '8 (K-5,K-5II,K-5IIs)',
9 => '9 (Q)',
10 => '10 (K-01,K-30)',
11 => '11 (Q10)',
12 => '12 (MX-1)',
},
},

The Q10 fills in the missing value of 11 from the link you gave.

- Phil

Klaus_Homeister · February 24, 2013, 10:18:22 AM

Hello,

I'm Klaus from DSLRforum.

It should _not_ be named SensorType!
K7 and K20 have different values 0x62 but share the same Samsung sensor.

But all Cams with the same value in 0x62 share one explicit set of basic development parameters!

In a software you can define dozens of development parameters as a fixed structure of preset-parameters.
You don't need to collect them one by one from dozens of places in Makernotes when you chose 0x62 as an index to a specific set of predefined parameters.

Then all you need for a standard development is whitepoint and blackpoint.
They are image depend.
All other standard parameters are always the same dependend on ID in 0x062.

I don't have any files from Pentax-Q10.
But I expect that it shares the same ID with Pentax-Q.

kind regards
klaus

Phil Harvey · February 24, 2013, 12:25:44 PM

Hi Klaus,

Thanks for joining this forum!

So "SensorType" is wrong, but what should this tag be called?

And the Q10 uses a value of 11 as I indicated, different from the Q.

- Phil

Klaus_Homeister · February 24, 2013, 02:24:41 PM

Hi Phil,

Ok to Q10.
I don't have any files of Q's
There must be something different in Q and Q10.

For me this Tag defines a Workflow with respect to different possibilities of whitebalances and where the WB-gains can be found.
You can speed up RAW-development a lot with respect to this Tag 0x62 and don't have to collect all parameters from parsing complete Metatdata.

maybe call it 'Workflow'

to all DSLR's :

ID 1: RAW 3936*2624, 12Bit, RGGB, Image 3872*2592, borders 26/26, Matrix, 1 of 8 WB-Levels in Tags:0x20D-0x214 or AsShotWhite
ID 2: n/a
ID 3: RAW 4864*3136, 12Bit, BGGR, Image 4672*3104, borders 28/28,Matrix, 1 of 8 WB-Levels in Tags:0x20D-0x214 or AsShotWhite
ID 4: RAW 4736*3136, 12Bit, BGGR, Image 4672*3104, borders 28/28,Matrix, 1 of 11 WB-Levels in SubDIR:0x22D or AsShotWhite
ID 5: RAW 4352*2868, 12Bit, BGGR, Image 4288*2848, borders 28/28,Matrix, 1 of 11 WB-Levels in SubDIR:0x22D or AsShotWhite
ID 6: RAW 7424*5552, 14Bit, BGGR, Image 7264*5440, borders 2/2,Matrix, 1 of 11 WB-Levels in SubDIR:0x22D or AsShotWhite
ID 7: RAW 4352*2868, 12Bit, BGGR, Image 4288*2848, borders 28/28,Matrix, 1 of 11 WB-Levels in SubDIR:0x22D or AsShotWhite
ID 8: RAW 4992*3284, 14Bit, BGGR, Image 4928*3264, borders 28/28,Matrix, 1 of 11 WB-Levels in SubDIR:0x22D or AsShotWhite
ID10: RAW 4936*3272, 12Bit, RGGB, Image 4936*3272, borders 28/28,Matrix, DNG only, 1 of 11 WB-Levels in SubDIR:0x22D or AsShotWhite
...
ID 9: sorry, look at Pentax-Q Data
ID 11: sorry, look at Pentax-Q10 Data
ID 12: sorry, look at Pentax-MX-1 Data

Workflow:
----------
//Always the same if Tag 0x62 is respected:
//otherwise you have to parse ALL Metadata
//...and have enough time to pray

Get Tag 0x62 and set preset-values above

//Image dependend and impossible to preset:
Get WB-Setup and configure WB-Gains to WB-preset or AsShotWhite
Get Blacklevel

->RUN DEVELOPMENT

Greetings
Klaus

Comment: edited to correct the WB SubDir and K30 wich has the same.

Phil Harvey · February 24, 2013, 03:40:11 PM

Hi Klaus,

Thanks for the detailed explanation. You have explained well how this tag may be used to select the appropriate raw development parameters (although I think the 645D is 16-bit).

I'll have to think about this. The problem is I don't think the name "Workflow" would be as meaningful for the average ExifTool user. Perhaps "RawDevelopmentProcess"?

You seem to understand the format of tag 0x21A. Do you have a reference for this? ExifTool isn't currently decoding this information.

- Phil

Klaus_Homeister · February 24, 2013, 08:11:44 PM

Hi Phil,

Don't call it 'Klaus'

Everything else is ok for me.

And NO! The Pentax 645D is 14Bit! and maximum saturation 16383.

And you're right! I looked in the wrong hexdumps.

I corrected the posting.
WB SubDir is 0x22D and K30 has it too!

But you don't know 0x22D either ...

It was born in Makernotes when tags 0x20D-0x214 disappeared.
And then look at a hexdump of 0x22D

0B 00 46 69 20 00 20 00 32 56 01 54 21 20 00 20
00 25 92 02 4B DD 20 00 20 00 2B 0B 03 2A 50 20
00 20 00 5D 62 04 56 F0 20 00 20 00 30 83 05 4A
8A 20 00 20 00 35 FC 06 43 C4 20 00 20 00 42 C1
07 4F D4 20 00 20 00 2E 53 08 38 B1 20 00 20 00
53 88 FE 46 69 20 00 20 00 32 56 FF 46 69 20 00
20 00 32 56

put some linebreaks in ...

0B
00 46 69 20 00 20 00 32 56
01 54 21 20 00 20 00 25 92
02 4B DD 20 00 20 00 2B 0B
03 2A 50 20 00 20 00 5D 62
04 56 F0 20 00 20 00 30 83
05 4A 8A 20 00 20 00 35 FC
06 43 C4 20 00 20 00 42 C1
07 4F D4 20 00 20 00 2E 53
08 38 B1 20 00 20 00 53 88
FE 46 69 20 00 20 00 32 56
FF 46 69 20 00 20 00 32 56

look at the 1st colum as an signed char! It's a counter!
combine the following pairs to DWORD's!

11 > overall entries
00 0x4669 0x2000 0x2000 0x3256
01 0x5421 0x2000 0x2000 0x2592
02 0x4BDD 0x2000 0x2000 0x2B0B
03 0x2A50 0x2000 0x2000 0x5D62
04 0x56F0 0x2000 0x2000 0x3083
05 0x4A8A 0x2000 0x2000 0x35FC
06 0x43C4 0x2000 0x2000 0x42C1
07 0x4FD4 0x2000 0x2000 0x2E53
08 0x38B1 0x2000 0x2000 0x5388
-2 0x4669 0x2000 0x2000 0x3256
-1 0x4669 0x2000 0x2000 0x3256

You see all the 0x2000 ?
And that looks like the values in tags 0x20D-0x214 wich were gone in Files when 0x22D appeared in K7

Divide the DWORD's by float 8192.0f
and you get the special Pentax Datatype of a float value (0.0 > ... <8.0)

0 -> 2.200317 1.000000 1.000000 1.572998
1 -> 2.629028 1.000000 1.000000 1.174072
2 -> 2.370728 1.000000 1.000000 1.345093
3 -> 1.322266 1.000000 1.000000 2.918213
4 -> 2.716797 1.000000 1.000000 1.515991
5 -> 2.329346 1.000000 1.000000 1.687012
6 -> 2.117676 1.000000 1.000000 2.086060
7 -> 2.494629 1.000000 1.000000 1.447632
8 -> 1.771606 1.000000 1.000000 2.610352
-1 ->2.200317 1.000000 1.000000 1.572998
-2 -> 2.200317 1.000000 1.000000 1.572998

et voilá ... the missing Whitebalance-Gains
Hmmmh 11 instead of 8!?

You don't like the -1 and -2 !???
Then have a look at your own software!
Pentax.pm Tag 0x0019 && 0x001A:

0xfffe => 'Unknown', #13
0xffff => 'User-Selected', #13

interpret this Values as signed and you have -1 and -2

When you got your workflow-parameter 'actual set WB' from Tag 0x19 or 0x1A you can get -1 or -2.
And in 0x22D you will end up in Standard-Daylight Multipliers!
Index 0 & -1 & -2 are always the same values here!

But wich set of multipliers belongs to wich whitebalance?

You know this?
Pentax tags 0x0053 up to 0x005A

ehmmm ...

"# 0x0053-0x005a - not in JPEG images - PH"

Sorry! look at PhotoME.
Pentax special KelvinCoding ...
Fix Value 53190 minus first DWORD of Tags 0x0053-0x005a == Colortemperature in Kelvin.
Addition from me:
it ist always followed by 0x00 and another Byte.
This Byte is to interpret like 'two signed HalfBytes' in the range of -7 to +7
and you get an WB-Finetune Value
GM/BA like in ColorInfo 0x0222

look at the Handbook of Pentax-Cams

0 WB-Kelvin Daylight : 5205°K -4 +2
1 WB-Kelvin Shade : 8000°K -5 +1
2 WB-Kelvin Cloudy : 6000°K +5 +2
3 WB-Kelvin Tungsten : 2857°K +2 +3
4 WB-Kelvin fDaylight : 5816°K -5 +7
5 WB-Kelvin fNeutral : 4790°K +3 +4
6 WB-Kelvin fWhite : 4142°K +5 +5
7 WB-Kelvin Flash : 5420°K 0 0

Here you have the indices of Whitebalance-Gains in 0x022D.
top down 0 to 7.

Hmmmh ...

But we have an 8 in 0x22D!?
Yes and this Tag came with Pentax-K7.
And this Cam added the 'Fluorescent-L'

this is in index 8 of 0X22D

Thats it for 0x22D

Reference ... sorry ... ask Pentax

For me it works with thousand of K7-Photos with my own converter.

Greetings
Klaus

PH Edit: Removed blank lines

Phil Harvey · February 25, 2013, 07:13:38 AM

Klaus,

THANK YOU VERY MUCH!

I'll add this to ExifTool.

- Phil

Edit: I checked, and neither PhotoMe 0.8 nor 0.79 decode the Pentax tags 0x0053-0x005a. But you have given me everything I need to add these... thanks!

Klaus_Homeister · February 25, 2013, 06:06:55 PM

Hi Phil,

And Tag 0x21A you asked for.

I don't know the exact meaning of the table, but it is obviously a table.

In 0x22D you have a table too.
You get first the counter, and then always an index and the Data of the row.

It is the same way of doing in 0x21A.
It is signed short Datatype.
1st there is the counter. call it 'c'
But this isnt't for rows!

It is folowed by c*shorts.
starting with 0x0001 ... increasing by 1 ... and always ending with two shorts 0x0080 & 0x0081
NOW there is the row counter as a 16Bit ... call it 'r'
And then the table-data is following in the same way like 0x22D ...

Dump of K10D. It has the shortest tag 0x21A

00 05 00 01 00 02 00 03 00 80 00 81 00 02 00 00
00 01 00 01 00 01 00 00 00 00 00 01 00 01 00 01
00 01 00 01 00 01

rearrange it...

0005 > c
0001 0002 0003 0080 0081
0002 > r
0000 0001 0001 0001 0000 0000
0001 0001 0001 0001 0001 0001

But now it's not enough to understand the meaning of the table.
The _older_ K100D Super had a BIGGER one of 0x21A !

0005 > colums
0001 0002 0003 0080 0081
0007 > rows
0000 0001 0001 0001 0000 0000
0001 0001 0001 0002 0001 0001
0002 0001 0001 0004 0002 0000
0003 0001 0004 0002 0003 0001
0004 0003 0001 0004 0004 0000
0005 0001 0001 0002 0005 0001
0006 0003 0004 0004 0006 0000

Look at the header ... it has 5 members ... but each row has 6 values.
I think the header defines something for the values but not for the first index in each row.

it is obvious that the 1st and 5th colum of each row is an index

And the big context of 0x21A iiiiiissss ... Saturation-Matrices!!!

Where are Saturation Matrices!?
directly in the _next_ Tag 0x21B !!

AND
What is in K10D only two times present but in older K100D 7 times

YES
Saturation matrices!

Let's check!

K200D has 15 Matrices in 0x21B. Look at 0x21A

0008 -> 8 colums in table header
0001 0002 0003 0004 0005 0006 0080 €0081
0014 -> in 20 rows!

0000 0001 0001 0003 0001 FFFF FFFF 0000 0000
0001 0001 0004 0004 0001 FFFF FFFF 0001 0000
0010 0001 0001 0001 0001 FFFF FFFF 0002 0000
0011 0001 0002 0004 0001 FFFF FFFF 0003 0000
0012 0001 0001 0001 0001 FFFF FFFF 0004 0000
0013 FFFF 0001 0003 FFFF 0000 0004 0005 0000 > this line looks strange
0002 0001 0001 0001 0001 FFFF FFFF 0002 0000
0003 0001 0002 0004 0001 FFFF FFFF 0003 0000
0004 0001 0001 0001 0001 FFFF FFFF 0000 0000
0005 0001 0001 0004 0001 FFFF FFFF 0001 0000
0006 0001 0001 0001 0001 FFFF FFFF 0002 0000
0007 0001 0001 0004 0001 FFFF FFFF 0001 0000
0008 0001 0004 0004 0001 FFFF FFFF 0001 0000
0009 0001 0004 0004 0001 FFFF FFFF 0001 0000
000A 0001 0004 0004 0001 FFFF FFFF 0001 0000
000B 0001 0004 0004 0001 FFFF FFFF 0002 0000
000C 0001 0004 0004 0001 FFFF FFFF 0001 0000
000D 0001 0004 0004 0001 FFFF FFFF 0001 0000
000E 0001 0004 0004 0001 FFFF FFFF 0000 0000
000F 0001 0004 0004 0001 FFFF FFFF 0001 0000

table ends ... tag is filled up with 0xFFFF

once more ... 1st value in each row is and index. but now it isn't sorted.
Very special is the row with index 0x0013 !
All other lines have a 0xFFFF,0xFFFF at position 5 & 6

Hmmmh ... YES

The maximumvalue in index in 8th colum is 5 !
The maximumvalue in index in 1st colum is 0x13 = int 19 !
Rearrange the table with reference to index in 1st colum ...
The special line is the last one in the new sorted table.

YESSSS!

MAPPING!

In K100D the table is very harmonic
1st and 2nd index are always the same.
It maps 7 'somethings' to 7 'somethings' one by one.
those 'somethings' have both the identical order and this is resulting in a identical idex on both sides of the mapping.
Maby it maps a Whitebalance to a saturation matrice.

In K10D it is different.
It maps 2 'somethings' to 2 'somethings' .

What is 2 and 2 in K10D !???
TONEMODES and saturation matrices!
Here the table maps a specific tonmode to a saturation matrice.

Things getting more complex in K200D
we have now 15 matrices and 5 Tonemodes

When you look to the hexdump above...
line 0x13 1st index xFFFF .... this isn't a valid row!
Its a definition of splitting the tables!

Above this line are 5 valid lines!

index as integer now and

00 0001 0001 0003 0001 FFFF FFFF 0 0000
01 0001 0004 0004 0001 FFFF FFFF 1 0000
10 0001 0001 0001 0001 FFFF FFFF 2 0000
11 0001 0002 0004 0001 FFFF FFFF 3 0000
12 0001 0001 0001 0001 FFFF FFFF 4 0000

the next line is our splitter

0013 after splitting the remaining rowcount is 0x13!

0001 0003 -> I don't know ... within 1st row of the table there is a 0001 0003 !???

0000 0004 0005 0000 ... 5 rows above the splitter ... maximum index value 4 ?

in the rest of table data FFFF FFFF seems to be an splitter too ... in a horizontal way

Now the table without the vertical splitterline looks like this.

<Headerline>

col1 col2 col3 col4 col5 col6 (0080 €0081)

<TableA sorted by #index stop at splitter>

@00 0001 0001 0003 0001 #0 0000
@01 0001 0004 0004 0001 #1 0000
@16 0001 0001 0001 0001 #2 0000
@17 0001 0002 0004 0001 #3 0000
@18 0001 0001 0001 0001 #4 0000

we have a rowcount similar to the number of available tonemodes of this cam.
and a clear #index 0-4

<restart after splitter for TableB>
@02 0001 0001 0001 0001 #2 0000
@03 0001 0002 0004 0001 #3 0000
@04 0001 0001 0001 0001 #0 0000
@05 0001 0001 0004 0001 #1 0000
@06 0001 0001 0001 0001 #2 0000
@07 0001 0001 0004 0001 #1 0000
@08 0001 0004 0004 0001 #1 0000
@09 0001 0004 0004 0001 #1 0000
@10 0001 0004 0004 0001 #1 0000
@11 0001 0004 0004 0001 #2 0000
@12 0001 0004 0004 0001 #1 0000
@13 0001 0004 0004 0001 #1 0000
@14 0001 0004 0004 0001 #0 0000
@15 0001 0004 0004 0001 #1 0000

here we have an rowcount of available saturation matrices but no clear indices

maybe a complete TableC of all data sorted by @index

<complete TableC>
@00 0001 0001 0003 0001 #0 0000
@01 0001 0004 0004 0001 #1 0000
@02 0001 0001 0001 0001 #2 0000
@03 0001 0002 0004 0001 #3 0000
@04 0001 0001 0001 0001 #0 0000
@05 0001 0001 0004 0001 #1 0000
@06 0001 0001 0001 0001 #2 0000
@07 0001 0001 0004 0001 #1 0000
@08 0001 0004 0004 0001 #1 0000
@09 0001 0004 0004 0001 #1 0000
@10 0001 0004 0004 0001 #1 0000
@11 0001 0004 0004 0001 #2 0000
@12 0001 0004 0004 0001 #1 0000
@13 0001 0004 0004 0001 #1 0000
@14 0001 0004 0004 0001 #0 0000
@15 0001 0004 0004 0001 #1 0000
@16 0001 0001 0001 0001 #2 0000
@17 0001 0002 0004 0001 #3 0000
@18 0001 0001 0001 0001 #4 0000

this table has a clear @index 0-18

here I'm finished.

It is a simple table in K100D and K10D.
Entries for every tonemode or matrice.

but the meaning of the data ...

possibly a vector [1 2 4 1]
No ... we have 3x3 matrices and a 1x4 vector ... doesn't work.

Hmmmh in this stage of RAW-development ... interpolating is done and we have to do the matrix-processing next.

we still have RGGB imagedata ... as an input for a 3x3-matrix ...
That doesn't work until we have mixed the two Green-Channels.

Look at the table data colum 2 3 4 5
The first and the last is _always_ 1 in ALL Cams!

2 3 4 5 ... could be R G G B

and always 1 for R and B corresponds to mixing of RGGB to RGB ... R & B always untouched.
The values in colum 3 & 4 ... perhaps the weightening of both greenchannels
in dependance on a tonemode in #index
and passed as a mixed RGB as input to a matrix referenced in @index

This make sense ... but is speculation.

I'm finished

Greetings from Germany
Klaus

Klaus_Homeister · February 25, 2013, 07:04:07 PM

Quote from: Phil Harvey on February 25, 2013, 07:13:38 AM
Edit: I checked, and neither PhotoMe 0.8 nor 0.79 decode the Pentax tags 0x0053-0x005a. But you have given me everything I need to add these... thanks!

Hi Phil,

you're right.
PhotoME is dead for a long time now.
I have an installed Beta for years now.

In the xml-definitions for pentax there is this part:

- <tag name="ColorTemperature" id="0x0050" type="SHORT[1]" class="number">
<name lang="en">Color Temperature</name>

<snip>

@SUB(53190;@GET()) K)</format>
</tag>

My old version shows in 0x0050 the selected ColorTemperature.
And in following tags 0x0053 - 0x005A a colortemperature but not the finetune.
A fresh downloaded newer version doesn't show it! why ever...

My reference for Kelvin-decode is PhotoME made by 'Jens Duttke' in Tag 0x50
That wasn't my examination.

WB-Finetune in the last byte of 0x0053 - 0x005A was my examination.
And the reference is simple ...
load a PEF into lightroom that was shot at fixed whitebalance and corresponding color temperature.
shift the Blue/Yellow and Green/Magenta similar to this HalfByte value in the corresponding Tag0x0053-5A.

The typical colorcast gets less visible. But it isn't gone.

I'm convinced that the so called 'typical Pentax colorcast' ... isn't a failure of Pentax ...
The typical RAW-converter does incomplete color processing on Pentax-RAWs. Thats my opinion.

Greetings
Klaus

Phil Harvey · February 25, 2013, 08:26:49 PM

Hi Klaus,

Wow, this is very interesting, but I will need to sit down and study this for a while to understand what you have told me.

Thanks for this insight!

- Phil

Klaus_Homeister · March 07, 2013, 02:10:13 PM

Hi Phil,

To the topic of this thread ... Tag 0x0062

Maybe same ID ensures that a cam can develop this file with it's inCam-Processing (RAW->JPG; RAW->TIFF)
... even when it comes via SD-Card from another Cam.

a K20D file can _not_ be processed in my K7's inCam TIF- or JPG-Processing (->different ID).
But I get a preview on TFT with complete information including histogramm ... but developing fails with 'not possible'.

If someone has two different models of K-5 Series ... he could check it by developing a RAW-File from the other cam with the inCam-TIF-processing. When it works -> same ID works ... different ID not!

Greetings
Klaus

News:

Pentax makernotes Tag 0x0062