Version 2.1 contains two new features.
New in 2.1
The first is a light trigger through webcam. Read about that one and how to use it here (with pretty screen shots).
The second feature is the ability to overwrite the guessed aperture with your own preset f/stop. Read about my struggles with that one here.
Adds scaling possibility through a value in the ini-file, enabling M9Tether to be shown smaller or larger than the default. For a short explanation on how to change scaling see here.
Bug fixes
Fixes a problem when shooting tethered manually: the results would not open in the set (or default) application.
And not really a bug: changed the EXIF temperature reading to more reliable code.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Saturday, June 25, 2011
Friday, June 17, 2011
Yet another quirk
Working on a new feature of M9Tether, I noticed yet another quirk of the M9 (they're really stacking up).
I'm trying to overwrite the makernote field of the photos produced by the M9, specifically a field called 'approximateFNumber'.
The name is an invention of ExifTool, since I don't think Leica published this information.
Lightroom however reports on this field, showing what the f/stop more or less was when the photo was taken, but it's usually off. And that's because the field is a guessed value (hence the 'approximate'), based on light reading of the sensor and of an extra thingie on the M9, near the red dot. There's no electronic connection between lens and body, so the M9 never knows for sure what the aperture of the lens was.
A user suggested an option in M9Tether to overwrite this 'guessed' field with the actual value, which I thought was a great idea. You set the aperture in M9Tether, and it's written into the field automatically on the transferred photos.
After some research I managed to decypher the makernote field.
The value is not an f/stop at all, but a number, representing the f/stop.
Then it took me a while to figure out how to get from the number to the f/stop. That involved some math (at first I thought it was a simple table representing the whole and half f/stops, but not so...)
Then, with the new feature finished - quite cool, I tell M9Tether 'fill in f/5.6' and Lightroom reports a nice f/5.6, even when the M9 thought it was f/16 - I noticed that the M9 doesn't update the approximateFNumber field internally when shooting tethered through the 'Shoot' button.
Manually everything works ok, but if you change the aperture of the lens and take a shot through the button, the approximateFNumber isn't updated, no matter how big the aperture change: it just stays the same.
Until you take another photo, then it's updated.
For some mysterious reason it's lagging one photo behind.
And for a geek like me that's infuriating, since I also want to present the original 'guessed' value, which now turns into a super-guessed-totally-wrong value on some photos.
I've tried everything. Resetting, clearing the cache, releasing certain objects in between... to no avail. And it's not just the transferred photos. Also the photo on the SD card. Exactly the same problem. So it's not a matter of the transfer starting too early or going wonky with old data.
The annoying part is that the makernote field for guessed f/stop isn't written directly, but calculated from the earlier mentioned other values, obtained by measuring light. And those values dó change, also when using the 'Shoot' button. These values are also stored in the makernote, so they're quite easy to trace.
This makes me believe it's not something I can fix directly.
If the base values dó change, the approximateFNumber should also change, but it doesn't. It's like the camera skips over the calculation or takes the values from the previous measurement, in hindsight.
So now I'm investigating formulas to get to the aperture indirectly through the measured light values, since those are adapted immediately. But the documentation I could find on this (for the M8) doesn't make sense. The formulas work sometimes, but not all the time, so I'm slightly stuck...
Now, you'd think this isn't a huge problem, because for the overwrite feature MTether overwrites the field anyway, who cares what it was originally?
Well, not totally true.
I'd like to present the guessed value next to the proposed value, so the user can decide last minute. And worse, at least the first photo taken with M9Tether through the 'Shoot' button after an aperture change, will have a wrong 'guessed' value.
I'm not sure at the moment how to deal with this one...
The M9, you've gotta love it, but I think the PTP implementation deserves more attention from someone at Leica.
I'd be happy to do some consulting for them, cause by now I can dream PTP...
[Edit: then finally, after some more experimenting, I realised it: the 'Shoot' button doesn't engage the metering system like the shutter button... it's like 'soft' release, and most likely that's why the values come too late to be written into the photo... I know this still sounds a bit off, but it must be something along those lines, because I was wrong with the light reading values: they also stay the same... the PTP release simply skips over some stuff necessary for this to go right, because it can't lock exposure... it probably fills the right registers when the photo is already being taken as opposed to regular release through the shutter button, where the metering is done on the second stop when pressing down... A little experiment confirmed this: shooting two photos through the Shoot button and changing the aperture in between, but engaging the meter between the two shots by pressing the shutter button half way and releasing it (without taking a photo)... Then the second photo reports the right value... Seems there's no way around this one until Leica releases a two stage trigger through PTP (if ever) in stead of this instant shoot, which apparently relies on the previous shot for the makernote values...]
I'm trying to overwrite the makernote field of the photos produced by the M9, specifically a field called 'approximateFNumber'.
The name is an invention of ExifTool, since I don't think Leica published this information.
Lightroom however reports on this field, showing what the f/stop more or less was when the photo was taken, but it's usually off. And that's because the field is a guessed value (hence the 'approximate'), based on light reading of the sensor and of an extra thingie on the M9, near the red dot. There's no electronic connection between lens and body, so the M9 never knows for sure what the aperture of the lens was.
A user suggested an option in M9Tether to overwrite this 'guessed' field with the actual value, which I thought was a great idea. You set the aperture in M9Tether, and it's written into the field automatically on the transferred photos.
After some research I managed to decypher the makernote field.
The value is not an f/stop at all, but a number, representing the f/stop.
Then it took me a while to figure out how to get from the number to the f/stop. That involved some math (at first I thought it was a simple table representing the whole and half f/stops, but not so...)
Then, with the new feature finished - quite cool, I tell M9Tether 'fill in f/5.6' and Lightroom reports a nice f/5.6, even when the M9 thought it was f/16 - I noticed that the M9 doesn't update the approximateFNumber field internally when shooting tethered through the 'Shoot' button.
Manually everything works ok, but if you change the aperture of the lens and take a shot through the button, the approximateFNumber isn't updated, no matter how big the aperture change: it just stays the same.
Until you take another photo, then it's updated.
For some mysterious reason it's lagging one photo behind.
And for a geek like me that's infuriating, since I also want to present the original 'guessed' value, which now turns into a super-guessed-totally-wrong value on some photos.
I've tried everything. Resetting, clearing the cache, releasing certain objects in between... to no avail. And it's not just the transferred photos. Also the photo on the SD card. Exactly the same problem. So it's not a matter of the transfer starting too early or going wonky with old data.
The annoying part is that the makernote field for guessed f/stop isn't written directly, but calculated from the earlier mentioned other values, obtained by measuring light. And those values dó change, also when using the 'Shoot' button. These values are also stored in the makernote, so they're quite easy to trace.
This makes me believe it's not something I can fix directly.
If the base values dó change, the approximateFNumber should also change, but it doesn't. It's like the camera skips over the calculation or takes the values from the previous measurement, in hindsight.
So now I'm investigating formulas to get to the aperture indirectly through the measured light values, since those are adapted immediately. But the documentation I could find on this (for the M8) doesn't make sense. The formulas work sometimes, but not all the time, so I'm slightly stuck...
Now, you'd think this isn't a huge problem, because for the overwrite feature MTether overwrites the field anyway, who cares what it was originally?
Well, not totally true.
I'd like to present the guessed value next to the proposed value, so the user can decide last minute. And worse, at least the first photo taken with M9Tether through the 'Shoot' button after an aperture change, will have a wrong 'guessed' value.
I'm not sure at the moment how to deal with this one...
The M9, you've gotta love it, but I think the PTP implementation deserves more attention from someone at Leica.
I'd be happy to do some consulting for them, cause by now I can dream PTP...
[Edit: then finally, after some more experimenting, I realised it: the 'Shoot' button doesn't engage the metering system like the shutter button... it's like 'soft' release, and most likely that's why the values come too late to be written into the photo... I know this still sounds a bit off, but it must be something along those lines, because I was wrong with the light reading values: they also stay the same... the PTP release simply skips over some stuff necessary for this to go right, because it can't lock exposure... it probably fills the right registers when the photo is already being taken as opposed to regular release through the shutter button, where the metering is done on the second stop when pressing down... A little experiment confirmed this: shooting two photos through the Shoot button and changing the aperture in between, but engaging the meter between the two shots by pressing the shutter button half way and releasing it (without taking a photo)... Then the second photo reports the right value... Seems there's no way around this one until Leica releases a two stage trigger through PTP (if ever) in stead of this instant shoot, which apparently relies on the previous shot for the makernote values...]
Thursday, June 16, 2011
M9Tether version 2.0b released
Version 2.0b doesn't contain new stuff, but it's adapted to deal with the new camera firmware (1.162).
Version 2.0a only operates fully on firmware 1.138, with some functionality blocked if the software detects different firmware. It was a bit of security, so I could test new firmware myself first. It seems firmware 1.162 doesn't change PTP in any way, and everything seems to work without problems, so I unlocked it in version 2.0b.
If you want to use RAMDisk mode, see camera temperature and shutter count, and you have firmware 1.162 loaded, download and install this new version.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Version 2.0a only operates fully on firmware 1.138, with some functionality blocked if the software detects different firmware. It was a bit of security, so I could test new firmware myself first. It seems firmware 1.162 doesn't change PTP in any way, and everything seems to work without problems, so I unlocked it in version 2.0b.
If you want to use RAMDisk mode, see camera temperature and shutter count, and you have firmware 1.162 loaded, download and install this new version.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Wednesday, June 8, 2011
M9Tether version 2.0a released
Well, sad to say, that didn't go very smooth.
A last minute change before releasing 2.0, without retesting all the new options, led to problems.
If you removed the SD card, started up the camera and the software, and answered 'yes' to the RAMDisk question, you would be presented with an access violation.
It's fixed in release 2.0a and should now work as promised.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
A last minute change before releasing 2.0, without retesting all the new options, led to problems.
If you removed the SD card, started up the camera and the software, and answered 'yes' to the RAMDisk question, you would be presented with an access violation.
It's fixed in release 2.0a and should now work as promised.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Monday, June 6, 2011
M9Tether version 2.0 released
Version 2.0 contains some bug fixes and two new features.
RAMDisk mode
Adds 'RAMDisk mode'. RAMDisk mode allows for shooting tethered without SD card and it speeds up the transfer (especially shooting DNG benefits). Read about this new feature here. There are some considerations, so please read the whole page.
Remote control through iPod
Adds remote control through iPod via iTunes (most likely also through iPhone/iPad). Read about this feature (and how to install) here.
Bug fixes
Adds check on the transfer folder. M9Tether will now warn if it doesn't have permission to write into the folder. In previous versions this could lead to an error in the middle of a transfer, freezing up the camera.
Fixes bug on Vista and possibly on some Windows7 systems: closing the application with the restore option on, could cause M9Tether to freeze, because the restore commands were sent to the camera too rapidly, invalidating the WPD software representation of the camera. This led to a freeze of the software. This seemed to be mainly a problem on Windows Vista.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Version 2.1?
Yes, that one is already in the making and will have the ability to trigger the camera through your webcam, reacting to sudden changes in brightness.
RAMDisk mode
Adds 'RAMDisk mode'. RAMDisk mode allows for shooting tethered without SD card and it speeds up the transfer (especially shooting DNG benefits). Read about this new feature here. There are some considerations, so please read the whole page.
Remote control through iPod
Adds remote control through iPod via iTunes (most likely also through iPhone/iPad). Read about this feature (and how to install) here.
Bug fixes
Adds check on the transfer folder. M9Tether will now warn if it doesn't have permission to write into the folder. In previous versions this could lead to an error in the middle of a transfer, freezing up the camera.
Fixes bug on Vista and possibly on some Windows7 systems: closing the application with the restore option on, could cause M9Tether to freeze, because the restore commands were sent to the camera too rapidly, invalidating the WPD software representation of the camera. This led to a freeze of the software. This seemed to be mainly a problem on Windows Vista.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Version 2.1?
Yes, that one is already in the making and will have the ability to trigger the camera through your webcam, reacting to sudden changes in brightness.
Subscribe to:
Posts (Atom)