Hi Phil,
[EDIT] Arrrgggh ITS Byte #9 on K7 ... and #8 on older Cams I believe.
This Byte is always set to 255 0xFF on photographing with a manual lens.
With an A-Lens there is a value looking like an unsigned integer.
It increases by small amounts on stopping down aperture of 'A'-Lenses.
It's the amount of pushing the aperture-lever.
Meant is the lever on Pentax-Lenses which opens the aperture. You push it sideways with your finger if you want to see through the lens with your eyes to check the lens.
'n==0' means this lever is pushed completely to 'wide open'
'0<n<225' means the lever is pushed 'n' steps less than wide-open-position.
But 'n' is no digital value like an FNo or AvValue ... it's analog pulses of an stepping-motor.
In Pentax-patents there is only a definition as a 'pre-calculated level', a preset maximum of 225 (NOT255!) and a ErrorValue 255.
So this is an analog stepping-value and NO valid FNo.
... BUT :
For example on a K7 with Sigma Super-Wide 24mm 2.8-22 it states '48' when stopped down to F22.
The lens ranges from F2.8 to F22 == six F-Stops.
This value divided by 8 => Six
It doesn't matter if you stop down by aperture-ring or in A-position initiated from Cam-body.
Sensitivy 1/8step F-Stops from wide-open-setting as '0'
For reference search in patents with key-word 'PNo' and 'EE pulse'
Greetings from Germany
Klaus
Hi Phil,
In CAM-Settings 0x205 there was a Byte#10 'WhiteBalanceSet'.
It was often set on my old K10D but never set on my newer K7.
This information has moved from Cam-Settings to AE-Setting #13 [of 0..23]
Mask &0x0F is identical with your 'WhiteBalanceSet' in Tag 0x205.
from WhitebalanceSet...:
0x00 = Standard
0x10 = Daylight
0x20 = Shade
0x30 = Cloudy
0x40 = Daylight Fluorescent
0x50 = Day White Fluorescent
0x60 = White Fluorescent
0x70 = Tungsten
But I wouldn't call it WhitebalanceSet.
it is obviously a metered Lightsource ... metered before capture from AE-process and independent of any manual or fixed setting of Whitebalance-Setup.
Indoor Tungsten light is metered and keeps indicated here. It doesn't matter if there is a manual Setup of a different Whitebalance.
And I would call '0' a default or 'Standard Lightsource' because _every_ setting here is a 'auto'-Setting.
That could be the reason for moving to AE-Setting because its AE-metered and not CAM-setted.
Mask &0xF0 is identical with your 'MeteringMode3' in Tag 0x205 from K10D.
Like this it overrides an incompatible MeteringSwitchSetting.
For example in case of using a M-Lens but setting CamSwitch to MatrixMetering. Matrix isn't possible with M-Lenses on Pentax.
This Value here gets corrected to 'Centerweighted' for a M-Lens while other Tags represent the SwitchSetting and keep 'MatrixMetering'.
Greetings from Germany
Klaus
Hi Phil ... again...
ok ... this one is :
Byte #22[of 0..23] in a AE-Setting of Len 24 (K7/Kx) ...
Thats the Level-Bar on Top-LCD and in Lifeview on TFT
This info may be a signed value.
But we are only interested in values -15 ... 0 ... +15
and because there can be bits 'out of range' that indicate errors ... I don't take it as a signed char ... it's confusing.
Check bit masked with &0x80 ... the sign ... as left or right direction.
And the bits masked with &0x0F (lower half byte) can be 0..15
this is the level of rotation.
but you have to correct it
if 'left' level = 16-(Byte&0x0F);
if 'right' level = Byte&0x0F;
I do this in this way because the three bits masked with &0x70 seem to be Error-Flags for me.
Ok ... in this way we have have a 4Bit integer and a left/right indicator.
My hands aren't sensitive enough to determine the exact center-position.
maybe it has a threshold .. -1.0.1+ ... and the off-center-positions ranging from 2..15
but it can be without threshold ... only exact '0' center and 15 is the state of blinking of the bar in TopDisplay when reaching maximum but not more.
important is: if one of the 3 bits masked with &0x70 is set, there is an error.
On K7 I get bits set masked with &0x50 ('bit-pattern 1o1') in the case of tilting the camera extreme ... top over to the floor or bottom up to the sky.
And I get the inverted bit-pattern 'o1o' in case of tilting & rolling the cam at the same time ... 45degrees in all directions x y z ...
That's the reason why I don' take this Byte as a signed char. Those error-bits would mess you up the signed Byte.
Pentax-Kx share the same size & structure of AE-Setting Directory ... but in this Cam there is always a int 90 for this Byte. So mayby this states a 'n/a'
Greetings from Germany
Klaus
Hi Klaus,
This is great, thanks! I don't have much time right now, but I'll post back tomorrow after I've had a chance to read your posts carefully.
- Phil
Hi Klaus,
AEInfo 0x0206 byte #8 or #9
This works well for my samples. Interestingly, there seem to be 18 steps per full stop for the 645D, instead of 6 as for other models. I'm thinking of calling this StopDownAperture. It is byte 8 only if the length of the AEInfo record is less than 20 bytes.
I'll post again when I have looked into your other discoveries.
- Phil
Edit: In AEInfo2 (K-01), this seems to be at byte 11. For AEInfo3 (K-3,K-30,K-50,K-500), bytes 34 and 36 are close to this, but the values don't quite fit (different factor again maybe?).
Hi Phil,
yes youre right.
It is a value 'pulses = distance in steps' .
And the distance the lever has to move on your 645D is two to three times longer than on PK mount. And 645 System has one full Stop more to stopping down to min-aperture.
And on my older lenses and my Tamrons with adaptall PK-A adapter ... ugh ... untight loose mount of the lens causes different values from shot to shot.
There is no fixed ratio 'Steps per F-Stops'
Greetings from Germany
Klaus
I see. Do you have a suggestion for the name of this tag?
- Phil
Hi Klaus,
AEInfo byte #13
I have added this for the K-7 and K-x (AEInfo length 24 bytes), with tags named AEWhiteBalance and AEMeteringMode2.
AEInfo byte #22
I would like to add this too, but some more testing would be nice. I would like to call this RollAngle, and have Exiftool convert to an angle in degrees, where positive is clockwise rotation of the camera (tilt to the right). This is what I do for the K-5 RollAngle.
What is the relationship between this number and the roll angle in degrees? You may need a tripod and a protractor to check this.
About the error bits: Is it always only 010 or 101? If so, what about this conversion?:
LevelFlags (mask 0x70):
000 = "OK"
010 = "Over Roll Limit"
101 = "Over Pitch Limit"
Thanks!
- Phil
Hi Phil,
it's more complicated.
my confusion was because you get a 'centered' indication in the top-LCD while you get a yellow 'little out of center' on the rearTFT.
the both have different maximum steps to to show
topLCD -6<0>6+
rearTFT -14<0>14+
now I get:
'0' for center.
'12' for the maximum position of the bar hard at the border to blink but without blinking left right +-
'13' for the maximum position of the bar hard at the border to blink _with_ blinking left right +-
last time shots were not blinking at +-14 but the center was on 0 1 or -1
So ... I believe there is the same problem as in the EE Pulse from the other Tag.
Here we have digitized analog voltages from a magnetic gyro-sensor ... that's not 100% precise ...
And those values have to be displayed on a topLCD with 1/13 Step or a TFT with 1/29 Step sensitivy
there is a double rounding you can not verify 100% precise the angle of 1/4 degree.
...
Every step on the TopLCD is documented in manuals as an angle of one single degree (+-6°).
Somewhere else they tell you a maximum of +-5°
So you have only ~10 degrees ... NOT 45!
But this is valid for each Orientation of the cam.
'0' can be in Exif-Orientation 0°, 90°CW, 90°CCW AND 180°
----------
the next info to the error-values.
they aren't errors ... exept '90'
There are 45° positions too!
On left to right direction there is a special state where no bar is displayed, but the indicators for center, leftmax and rightmax are blinking together.
on 45° 135° 225° & 315° you get values from 70<n<80 and 180<n<190
thats
around +-75 as signed char for diagonal positions.
around +-15 as signed char for horizontal and vertical positions.
each is relative to the ExifOrientation.
Then there is a '90' when pitch roll tilt ... whatever out of range.
This one is fixed entry in all Kx-PEF's I have. -> TagByte is present but data is invalid.
They were my error-values exept the '90' ... this one really is a 'out of range'
And my last shot test for the week ... at positions 45° left or right and 45° to the front ... there is a locking to a 'special' blinking too.
There you get values around +-60
too much for now. i have to check it next week.
Have a nice weekend.
Klaus
Hi Klaus,
Interesting, but I don't think this helps much. In all this testing, did you see any new values for the flags bits?
The electronic level is undoubtedly some sort of accelerometer. And yes, the outputs of the accelerometer must be digitized, so there are inherent inaccuracies. But I would expect a fixed relationship between the digital value and the indicators in both the top and rear LCD. The manual says that the top LCD is a single degree per step. I can use this for the rough calibration if I know the relationship between the top indicator and the digital value. If it is like the K-5, the digital value changes by 2 counts per degree. This would make sense for the K-7 too because then there could be a 1:1 relationship between the digital value and the rear LCD indicator (which appears to have twice the resolution of the top).
- PHil
Hi Phil,
Quote from: Phil Harvey on November 23, 2013, 06:40:44 AM
Interesting, but I don't think this helps much. In all this testing, did you see any new values for the flags bits?
... But I would expect a fixed relationship between the digital value and the indicators in both the top and rear LCD.
No it's all quite different than expected.
The value is a ordinary int8s without any Flags for pitch.
It is one single component taken out of a 'xyz' context from somewhere else.
Initially I expected the +-14 represent the LCDdisplays bar and every other value has to be an error or flag.
But now I have more info:
'0' is definitely the center position.
And from the absolute balanced center position without pitch ... I started a big series to the left and then to the right.
For the first steps represented by the LCD bar ... stepping and values seem to be proportional and more precise.
When the Display locks to blinking with a maximum left or right...
When you increase rotation ... the bar doesn't change anymor and keeps blinking at max ... but the value increases ... but gets disproportional.
New for me was the 45° position with the special state of blinking. Without any pitch this happens at value '+-74'.
At '+-75'-position the ExifOrientationTag changes correct. But this value remains unchanged relative to the old Orientation before.
This is valid for a range from +-75 up to +-79.
When increase the rotation one step more ... the value gets inverted and relative to the new ExifOrientation ... but it changes from -79 to +74 or +79 to -74.
I expected a change to 75 or a 79 of the opposite direction ... but no its always the 74 after change.
When you take back the rotation ... the value increases from 74 up to 79 while the ExifOrientation changes once more at exact 75.
But the value changes it's orientation later at a '79+1'-position ... and then once more to the 74 of the opposite Orientation.
There is an overlapping range!
-75..-79 have the identical positions as the +74..+75 of the opposite direction.
+75..+79 have the identical positions as the -74..-75 of the opposite direction.
And this is only half of the story.
When you increase the pitch of the cam to ~2° direction to the lens and down ...
Then repeat all the series to right and left rotation ... yoe get at 45° the fix '+-75' and a changing of the ExifOrientationTag as expexcted ... but the next step is the '74' of the opposite direction. Without any overlapping!
Then the next session all with a pitch of ~4° ... in this setup you are not able to reach the '75' anymore ... maximum at 45° is a +-66 and it changes together with the ExifOrientation with the next step of rotation... to a '64' of the opposite direction.
And in this setup you get no special indication for a 45°-position on the cam ... it changes from one maximum-bar to the opposite maximum-bar.
You can increase pitch up to +10° before all values get imprecise, nervous and not to reproduce a few times without changing any position.
The position of '45°'-changing decreases with each degree of increased pitch.
And you have NO information about the pitch here ... so you _can't_ say it's 45° except you have an '+-75'
My estimation of an pitch or roll flag was completely _wrong_!
Pitch isn't _represented by_ this Tagbyte ... pitch is _the problem of_ this Tagbyte!!!!
And my conclusion is:
You can only do in your Software what the cam is doing on displays.
#1 check the '90' ... this is Err-indicator (always set on Kx)
Actual ExifOrientation+value90 would be far way into the next ExifOrientation. This is why 90 is choosen as an Err.
#2 Test for a +-75 with a small threshold ... and you have for sure a ~45°-position at a pitch =<2.5°.
#3 If you have an value >15 or <-15 ... you are at a 'more than maximum-position' of one direction.
#4 In the range -15...0...15+ you can round nearly precise to a representation you like ... bar value or whatever.
## And do not anything with the range of 16...74 ... this range isn't to interpret in a reasonably correct way without an additional information of the pitch. And this isn't available here ... that's the reason why the cam uses this byte only in the limited way stated above.
There is no 1:1 relationship ... the increased angle of rotation for 1 step at value 30 is much more than at value 15 but gets smaller at 50 and again gets smaller at 60 ...
at +-75 the angle of rotation per step becomes identical to the angle per step at range 0..15.
And it isn't a computation of sinus or whatever I tried.
Greetings from Germany
Klaus
Hi Klaus,
Thanks for running these tests. I notice that the K-7 also stores the LevelInfo record, which I have decoded for the K-5, and from which these tags are extracted: LevelOrientation, RollAngle, PitchAngle and various CompositionAdjust tags. Do any of these make sense for the K-7?
- Phil
Hi Phil,
you mean the 0x0227 Directory?
That's present on K7 too.
And the second Byte is nearly identical. But sometimes with a threshold +-1.
I would say the Byte in AE-Settings is a rounded version of your LevelInfo.RollAngle.
Remarkable is: rounding takes place on AE-Values +-15 and maybe around 75. In this range it is LevelInfo.RollAngle +-1.
At any other level it is identical to LevelInfo.RollAngle.
And by the way ... my script dumped the ShotInfo.CameraOrientation side by side with this Byte on AE-Settings. And for Orientation I get always a 90°CW where a 270° is correct and 270° where 90°CW is correct.
And I never get your Upwards or Downwards where it would be correct.
Klaus
Quote from: Klaus_Homeister on November 27, 2013, 01:09:09 PM
you mean the 0x0227 Directory?
No. LevelInfo is 0x022b (https://exiftool.org/TagNames/Pentax.html).
QuoteAnd the second Byte is nearly identical. But sometimes with a threshold +-1.
But it sounds like we are talking about the same thing.
QuoteAnd by the way ... my script dumped the ShotInfo.CameraOrientation side by side with this Byte on AE-Settings. And for Orientation I get always a 90°CW where a 270° is correct and 270° where 90°CW is correct.
I have a number of K-7 samples, and ShotInfo.CameraOrientation agrees with Exif.Orientation for all of them.
- Phil
Edit: I found 2 samples where Exif.Orientation is Horizontal, but ShotInfo.CameraOrientation is 90 CW. I will have to look into this.
Hi Phil,
Ok it's 0x22B. There was a typing error in my Stringtable for dump only.
Examinations are correct.
This Byte is a rounded version of your LevelInfo.
And I interpreted ExifOrientation like PhotoME ... that's wrong and swaps CW and CCW.
Your's is correct.
Klaus