Not so great timing, but I can't help it that Leica doesn't follow my schedule. :-)
So after releasing 2.2c, just a few days ago, there's now 2.2d.
The only difference being that 2.2d fully functions with the new Leica firmware (1.196) they brought out today (of course this version also still operates fully with 1.138, 1.162, 1.174 and 1.176).
I designed M9Tether under the assumption the PTP implementation might change with firmware updates, blocking some functionality for use with newer firmware, as a safeguard.
So far (after now four new firmware versions) that assumption turned out to be wrong.
Also in this firmware (1.196) nothing was fixed, changed or added where PTP is concerned and RAMDisk mode operates as it did under the previous firmware. I wasn't able to detect any changes (somehow a bit disappointing, seeing that the PTP implementation really could use some attention - I still notice at least two bugs and the options to change settings on the camera are still as limited as they always were).
You can download 2.2d here.
Showing posts with label m9tether. Show all posts
Showing posts with label m9tether. Show all posts
Monday, July 23, 2012
Saturday, July 21, 2012
M9Tether 2.2c released
A very minor release with two small memory bugfixes.
The program still suffered from freezes on my Windows 7 64-bit, and after extensive attempts to find the cause, or to even confirm this was just a problem on 64-bit, I had hardly made any progress with this problem.
Technically it isn't a freeze by the way. What happens is that the PTP event system fails. It's unclear if that originates in the camera or in the middle layer on the PC. The signal 'photo ready' isn't sent anymore (or at least not received).
But then, if you change say the ISO setting on the camera (which also causes an event to fire), all the previous events come in one go.
It's not so much a freeze, more of a pile up, like they're quite literally stuck, waiting to be released.
Then after running some additional debugging tools, I did find two lines of code that might have been responsible. I say 'might', because the bug didn't show up always before the fix. It's one of those things... You could snap away ten times and then the eleventh time events would get stuck. And those numbers differed constantly. So testing if the bug is really gone is almost impossible. You can only confirm it's still there (when it happens again), but not really confirm it isn't there anymore (it might happen on your next shot). This is one of the most annoying type of bugs a programmer can run into. And seeing how I'm dealing here with an unstable PTP implementation on the camera, USB drivers, Windows PTP drivers, and then my own code, all working together in an asynchronous event driven system, it's almost impossible to find out what's causing this, without first spending hours on sniffing out the low level communication between camera and PC (which then is only helpful if you can actually quickly reproduce the bug).
But after this fix, and snapping away for a long time, I wasn't able to reproduce the freezes, so I have good hope.
You can download this release here.
The program still suffered from freezes on my Windows 7 64-bit, and after extensive attempts to find the cause, or to even confirm this was just a problem on 64-bit, I had hardly made any progress with this problem.
Technically it isn't a freeze by the way. What happens is that the PTP event system fails. It's unclear if that originates in the camera or in the middle layer on the PC. The signal 'photo ready' isn't sent anymore (or at least not received).
But then, if you change say the ISO setting on the camera (which also causes an event to fire), all the previous events come in one go.
It's not so much a freeze, more of a pile up, like they're quite literally stuck, waiting to be released.
Then after running some additional debugging tools, I did find two lines of code that might have been responsible. I say 'might', because the bug didn't show up always before the fix. It's one of those things... You could snap away ten times and then the eleventh time events would get stuck. And those numbers differed constantly. So testing if the bug is really gone is almost impossible. You can only confirm it's still there (when it happens again), but not really confirm it isn't there anymore (it might happen on your next shot). This is one of the most annoying type of bugs a programmer can run into. And seeing how I'm dealing here with an unstable PTP implementation on the camera, USB drivers, Windows PTP drivers, and then my own code, all working together in an asynchronous event driven system, it's almost impossible to find out what's causing this, without first spending hours on sniffing out the low level communication between camera and PC (which then is only helpful if you can actually quickly reproduce the bug).
But after this fix, and snapping away for a long time, I wasn't able to reproduce the freezes, so I have good hope.
You can download this release here.
Labels:
m9tether
Saturday, November 19, 2011
M9Tether 2.2 released
New in 2.2
I added a second remote option to the program.
You can now use your wireless (or wired) mouse to control the camera. It's less cumbersome to set up than the remote option through iTunes. Select the remote option in the new drop down (choices are iTunes or Mouse) and then click the 'Remote...' button on the right...
With the mouse you can shoot with the left button, or change some of the camera's settings (selecting the setting by clicking the right mouse button and changing the setting by using the scroll wheel of the mouse).
The iTunes option is extended and now also includes the ability to change the Format setting remotely.
Note that you will have to add the format tracks from 'The Album' to your iTunes library for this to work. 'The Album' can be located in the M9Tether installation folder (default would be C:\Program Files\M9Tether) and it contains the silent MP3 files that need to be added to your iTunes library.
For a full description follow the links on the download page.
Enabled for the new firmware
Version 2.2 also enables firmware sensitive functionality (Temperature reading / ImageUniqueID reading / Ramdisk mode) to work with the newest firmware (1.174).
M9Tether was updated in the meantime to version 2.2b... no changes other than making it also work with firmware 1.176
Bug fixes
Fixes a problem with the repeat timer button, which sometimes didn't show (the button behind the option 'Timed shoot').
Fixes a problem where the confirmation for 'Aperture overwrite' wouldn't show.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
I added a second remote option to the program.
You can now use your wireless (or wired) mouse to control the camera. It's less cumbersome to set up than the remote option through iTunes. Select the remote option in the new drop down (choices are iTunes or Mouse) and then click the 'Remote...' button on the right...
With the mouse you can shoot with the left button, or change some of the camera's settings (selecting the setting by clicking the right mouse button and changing the setting by using the scroll wheel of the mouse).
The iTunes option is extended and now also includes the ability to change the Format setting remotely.
Note that you will have to add the format tracks from 'The Album' to your iTunes library for this to work. 'The Album' can be located in the M9Tether installation folder (default would be C:\Program Files\M9Tether) and it contains the silent MP3 files that need to be added to your iTunes library.
For a full description follow the links on the download page.
Enabled for the new firmware
Version 2.2 also enables firmware sensitive functionality (Temperature reading / ImageUniqueID reading / Ramdisk mode) to work with the newest firmware (1.174).
M9Tether was updated in the meantime to version 2.2b... no changes other than making it also work with firmware 1.176
Bug fixes
Fixes a problem with the repeat timer button, which sometimes didn't show (the button behind the option 'Timed shoot').
Fixes a problem where the confirmation for 'Aperture overwrite' wouldn't show.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Labels:
leica M9,
leica talk,
m9tether
Saturday, June 25, 2011
M9Tether 2.1 released
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.
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.
Labels:
leica M9,
leica talk,
m9tether
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...]
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.
Monday, May 23, 2011
Another crazy idea?
I have been looking into methods of making M9Tether more remote. To be able to control it (on the PC) through Wifi. It's for a specific need: those lightning shots.
I want to place the camera and laptop outside, but control the whole setup from inside.
You have no idea what mosquitoes can do (or perhaps you have...) if you don't move around. And these photos take extended periods of time trying to stand still, waiting for the moment... in the meantime I'm being sucked dry by these pesky creatures.
The first thing you think of obviously is the iPod (or a really long USB cable, but that's rather impractical).
But there's two problems with the iPod: I don't like Apple's App Store policy (in fact I don't like Apple at all... they surpassed Microsoft with their control issues). You actually have to pay them to develop for iPod... and you need an Apple computer (perhaps not anymore, but it's kinda handy).
So I thought: how to utilize the iPod without actually writing an application for it?
Now, Apple wrote quite a neat remote for iTunes, so that got me thinking.
What if I supply an M9Tether album, with the tracks having command names? So you'd have in the album for instance 'M9TetherShoot.mp3'. Than if you play it, through the remote, the camera would shoot...
Yes I know, it sounds kinda out there, and rather improvised, but I think it would work... You could actually control the whole camera that way.
I already got M9Tether to play tracks from iTunes, not that practical... now what I need is the reversed. If iTunes plays a track, M9Tether's got to act...
[Edit1: well, this actually works! It's not very sophisticated yet, but whenever I start playing a song in iTunes - also through the remote - the camera snaps a photo...]
[Edit2: It's a little bit more sophisticated now. Whenever I play a track with the name 'M9T_Shoot' it snaps a photo, then it rewinds the track after the camera is done... it's indeed a crazy idea, but it works beyond expectation and it's now possibile to not just shoot, but also adapt the settings, e.g. with a trackname like 'M9T_SetISO400'... I think I might be able to drag this even further into bizarro land, because it should also be possible for the endresult (the photo if it's JPG) to show on the iPod, if I can immediately set the album artwork...]
[Edit3: Well, setting the album artwork actually works, but it's not refreshed properly on the iPod (you have to click around a bit before it shows) and it makes the whole setup unstable, so I'm going to leave that one for now. In the meantime I can shoot remote and set ISO remote. It works like a charm, although through my Wifi router there is some lag. That's gone when I connect the iPod directly to my laptop, the intended setup anyway. Now just a matter of extending the album and this feature is finished...]
I want to place the camera and laptop outside, but control the whole setup from inside.
You have no idea what mosquitoes can do (or perhaps you have...) if you don't move around. And these photos take extended periods of time trying to stand still, waiting for the moment... in the meantime I'm being sucked dry by these pesky creatures.
The first thing you think of obviously is the iPod (or a really long USB cable, but that's rather impractical).
But there's two problems with the iPod: I don't like Apple's App Store policy (in fact I don't like Apple at all... they surpassed Microsoft with their control issues). You actually have to pay them to develop for iPod... and you need an Apple computer (perhaps not anymore, but it's kinda handy).
So I thought: how to utilize the iPod without actually writing an application for it?
Now, Apple wrote quite a neat remote for iTunes, so that got me thinking.
What if I supply an M9Tether album, with the tracks having command names? So you'd have in the album for instance 'M9TetherShoot.mp3'. Than if you play it, through the remote, the camera would shoot...
Yes I know, it sounds kinda out there, and rather improvised, but I think it would work... You could actually control the whole camera that way.
I already got M9Tether to play tracks from iTunes, not that practical... now what I need is the reversed. If iTunes plays a track, M9Tether's got to act...
[Edit1: well, this actually works! It's not very sophisticated yet, but whenever I start playing a song in iTunes - also through the remote - the camera snaps a photo...]
[Edit2: It's a little bit more sophisticated now. Whenever I play a track with the name 'M9T_Shoot' it snaps a photo, then it rewinds the track after the camera is done... it's indeed a crazy idea, but it works beyond expectation and it's now possibile to not just shoot, but also adapt the settings, e.g. with a trackname like 'M9T_SetISO400'... I think I might be able to drag this even further into bizarro land, because it should also be possible for the endresult (the photo if it's JPG) to show on the iPod, if I can immediately set the album artwork...]
[Edit3: Well, setting the album artwork actually works, but it's not refreshed properly on the iPod (you have to click around a bit before it shows) and it makes the whole setup unstable, so I'm going to leave that one for now. In the meantime I can shoot remote and set ISO remote. It works like a charm, although through my Wifi router there is some lag. That's gone when I connect the iPod directly to my laptop, the intended setup anyway. Now just a matter of extending the album and this feature is finished...]
Labels:
m9tether
M9Tether 1.9 released
Version 1.9 contains some bug fixes and a few new options.
Showing camera temperature
(yes yes, also in Fahrenheit... but not in Delisle, Kelvin, Newton, Rankine, Réaumure or Rømer... sorry for that... and apologies also to any other scientist out there who invented a temperature scale not mentioned here... And might I add: points for effort to Delisle! He's clearly The Man! He seems particularly nutty, swimming against the tide and all that, I like him already... I might add him after all in version 2.0...)

Adds temperature reading from the EXIF data (it's not read directly from the camera but from the photos that are shot).
This only works if JPGs are viewed in the internal viewer of M9Tether, or files are stored on the PC. If both options are turned off, there's no photos passing through to read the EXIF data from.
The temperature field is read from the makernote data. I'm not 100% sure I have all the offsets right. Please shoot me an email if you see unrealistic temperatures pop up and if possible include the photo that caused the wrong reading (only JPGs directly from the camera please, no DNG or JPG later exported from the DNG - contact under 'Contact' on the download page).
In anticipation of new firmware I've locked this function to only operate on firmware 1.138. Any new firmware will first be tested by me and I'll then release a new version to reinstate it. Rather no temperature, than scare you with a possible wrong one - help, my camera is on fire - since new firmware might deal differently with the makernote field.
ImageUniqueID or shutter count
Adds ImageUniqueID reading (the shutter count - or so it's commonly believed) from the EXIF data.
This only works if JPGs are viewed in the internal viewer of M9Tether, or if files are stored on the PC. If both options are turned off, there's no photos passing through to read the EXIF data from.
The ImageUniqueID is presented in the Info window, with a timestamp. It will show you the last number M9Tether encountered.
Be aware that this number is not necessarily the latest one. If you shoot tethered without transferring to the PC and without viewing the JPGs, no photos pass through to read the value from, so you'll be looking at an outdated value. That's why the date/time stamp was added.
If you see '[to be determined]' it means no photos have passed through yet.
In anticipation of new firmware I've locked this function to only operate on firmware 1.138. Any new firmware will first be tested by me and I'll then release a new version to reinstate this option.
OMG My Camera Has Been Used Before I Bought It, It Wasn't As New As I Thought It Was, Have I Been Cheated?!
Don't be shocked if the shutter count differs from the filename count. It's quite normal to have 200 - 300 shots difference. Those are the shots taken at the Leica factory when they test the camera. If the difference is a lot bigger (or mymymyohmy, the shutter count is actually smaller than the file name count!) consider that M9Tether might contain bugs or that your photo numbering got reset (e.g. by switching memory cards or loading new firmware)...
Save option in JPG viewer
Adds option to save the JPG in the viewer. This option seems redundant, since the JPG is stored on the SD card, but a new future option where the RAM disk of the Leica will be used, makes this a useful addition. If you had 'transfer to PC' switched off you still can save the photo this way.
Two buttons ('Save' and 'Save As...') were added to the button row that pops up when you move your mouse towards the bottom of the viewer. The save options are also added to the right click popup menu.
Use 'Save' to save it under the set folder in the main window, with the current file name (it will warn if a file with the same name already exists). If the set folder in the main window doesn't exist, the Save button will be disabled.
Use 'Save As...' for a new location and/or new file name.
Bug fixes
Fixes some memory bugs where PROPVARIANT structures were not initialized. I don't think these bugs were a big problem to the functionality of the program, but nevertheless...
Fixes a crash on the Cancel button in the window that appears when starting up M9Tether with multiple PTP devices connected to the PC. The application would attempt to close a device that hadn't been opened yet.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Version 2.0?
Yes, that one is already in the making and will contain the RAM disk addition, enabling you to shoot tethered with faster transfer times and without SD card. It's working quite well, but I have some details to work out before I can release it.
Showing camera temperature
(yes yes, also in Fahrenheit... but not in Delisle, Kelvin, Newton, Rankine, Réaumure or Rømer... sorry for that... and apologies also to any other scientist out there who invented a temperature scale not mentioned here... And might I add: points for effort to Delisle! He's clearly The Man! He seems particularly nutty, swimming against the tide and all that, I like him already... I might add him after all in version 2.0...)

Adds temperature reading from the EXIF data (it's not read directly from the camera but from the photos that are shot).
This only works if JPGs are viewed in the internal viewer of M9Tether, or files are stored on the PC. If both options are turned off, there's no photos passing through to read the EXIF data from.
The temperature field is read from the makernote data. I'm not 100% sure I have all the offsets right. Please shoot me an email if you see unrealistic temperatures pop up and if possible include the photo that caused the wrong reading (only JPGs directly from the camera please, no DNG or JPG later exported from the DNG - contact under 'Contact' on the download page).
In anticipation of new firmware I've locked this function to only operate on firmware 1.138. Any new firmware will first be tested by me and I'll then release a new version to reinstate it. Rather no temperature, than scare you with a possible wrong one - help, my camera is on fire - since new firmware might deal differently with the makernote field.
ImageUniqueID or shutter count
Adds ImageUniqueID reading (the shutter count - or so it's commonly believed) from the EXIF data.
This only works if JPGs are viewed in the internal viewer of M9Tether, or if files are stored on the PC. If both options are turned off, there's no photos passing through to read the EXIF data from.
The ImageUniqueID is presented in the Info window, with a timestamp. It will show you the last number M9Tether encountered.
Be aware that this number is not necessarily the latest one. If you shoot tethered without transferring to the PC and without viewing the JPGs, no photos pass through to read the value from, so you'll be looking at an outdated value. That's why the date/time stamp was added.
If you see '[to be determined]' it means no photos have passed through yet.
In anticipation of new firmware I've locked this function to only operate on firmware 1.138. Any new firmware will first be tested by me and I'll then release a new version to reinstate this option.
OMG My Camera Has Been Used Before I Bought It, It Wasn't As New As I Thought It Was, Have I Been Cheated?!
Don't be shocked if the shutter count differs from the filename count. It's quite normal to have 200 - 300 shots difference. Those are the shots taken at the Leica factory when they test the camera. If the difference is a lot bigger (or mymymyohmy, the shutter count is actually smaller than the file name count!) consider that M9Tether might contain bugs or that your photo numbering got reset (e.g. by switching memory cards or loading new firmware)...
Save option in JPG viewer
Adds option to save the JPG in the viewer. This option seems redundant, since the JPG is stored on the SD card, but a new future option where the RAM disk of the Leica will be used, makes this a useful addition. If you had 'transfer to PC' switched off you still can save the photo this way.
Two buttons ('Save' and 'Save As...') were added to the button row that pops up when you move your mouse towards the bottom of the viewer. The save options are also added to the right click popup menu.
Use 'Save' to save it under the set folder in the main window, with the current file name (it will warn if a file with the same name already exists). If the set folder in the main window doesn't exist, the Save button will be disabled.
Use 'Save As...' for a new location and/or new file name.
Bug fixes
Fixes some memory bugs where PROPVARIANT structures were not initialized. I don't think these bugs were a big problem to the functionality of the program, but nevertheless...
Fixes a crash on the Cancel button in the window that appears when starting up M9Tether with multiple PTP devices connected to the PC. The application would attempt to close a device that hadn't been opened yet.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Version 2.0?
Yes, that one is already in the making and will contain the RAM disk addition, enabling you to shoot tethered with faster transfer times and without SD card. It's working quite well, but I have some details to work out before I can release it.
Labels:
leica talk,
m9tether
Friday, May 20, 2011
Secret II
The 'secret' RAM disk of the Leica M9 proves to be rather useful.
It didn't give me the big speedup I was hoping for though, but the transfer does go faster.
On my PC transferring a JPG (fine / max resolution) takes about 6 seconds before it shows up in the viewer. With the RAM disk enabled it takes about 4 seconds. That's still a respectable 30% speed gain.
Another big advantage: you can shoot tethered without the SD card in the camera. The camera happily takes a shot and stores the photo on the RAM disk, without complaining about a lacking card.
I have to fine tune this a bit. The object on the RAM disk needs to be deleted before the next shot is taken, and I haven't accomplished that yet. Makes testing a bit awkward, because after one shot I need to switch the camera off to empty the RAM disk, else the camera freezes up. Also the DNG + JPG setting doesn't work, because the RAM disk can only hold one object (even when the RAM disk is not filled up fully).
So my first step will now be some functionality to automatically wipe it clean after transfer.
Another headache with this: the filename on the RAM disk is always the same: M9_0001.dng. I haven't checked the EXIF yet to see if the unique numbering simply continues or what the next shot on the SD card is, but when using this I obviously have to implement some solution to give the transferred file a unique name on the PC.
I'm still unclear as to what the RAM disk is exactly or why Leica put it in there. I've been asking around, but so far no answers. There's not many options though. It's either for internal testing at Leica, or for tethered shooting, with the specifics about it perhaps released to some software vendors when they ask for it.
Leica does not mention this in their technical specifications (under 'storage' they only mention the need for a card), so thus far I am inclined to believe I discovered something undocumented.
It didn't give me the big speedup I was hoping for though, but the transfer does go faster.
On my PC transferring a JPG (fine / max resolution) takes about 6 seconds before it shows up in the viewer. With the RAM disk enabled it takes about 4 seconds. That's still a respectable 30% speed gain.
Another big advantage: you can shoot tethered without the SD card in the camera. The camera happily takes a shot and stores the photo on the RAM disk, without complaining about a lacking card.
I have to fine tune this a bit. The object on the RAM disk needs to be deleted before the next shot is taken, and I haven't accomplished that yet. Makes testing a bit awkward, because after one shot I need to switch the camera off to empty the RAM disk, else the camera freezes up. Also the DNG + JPG setting doesn't work, because the RAM disk can only hold one object (even when the RAM disk is not filled up fully).
So my first step will now be some functionality to automatically wipe it clean after transfer.
Another headache with this: the filename on the RAM disk is always the same: M9_0001.dng. I haven't checked the EXIF yet to see if the unique numbering simply continues or what the next shot on the SD card is, but when using this I obviously have to implement some solution to give the transferred file a unique name on the PC.
I'm still unclear as to what the RAM disk is exactly or why Leica put it in there. I've been asking around, but so far no answers. There's not many options though. It's either for internal testing at Leica, or for tethered shooting, with the specifics about it perhaps released to some software vendors when they ask for it.
Leica does not mention this in their technical specifications (under 'storage' they only mention the need for a card), so thus far I am inclined to believe I discovered something undocumented.
Labels:
leica M9,
leica talk,
m9tether
Wednesday, May 18, 2011
M9Tether development - secret discovered?
Got some feedback from a M9Tether user in the UK, who likes to photograph in Canada on snowy mountains (I'm a stickler for privacy, so I won't mention his name without his permission).
He seemed quite happy with it, but had some remarks. One of them was the idea to overwrite the aperture field in the EXIF data, since it's a guessed value. The camera doesn't know the F-stop of the lens because there's no electronic connection between lens and camera body. The camera just guesses a bit through a secondary light reader (a small dot near the red label).
I liked the idea.
Set a value in M9Tether and the field is filled in properly, since you know what the F-stop is. Obviously there's a lot of room for error if you change the aperture but not the setting in M9Tether, but hey, then it's your own fault. And I won't touch the DNGs on the SD card. This would only be done on the transferred files, so the original is always there as a backup 'guess'.
So I dove into the EXIF of the DNG and JPGs produced by the M9.
Turns out the setting is in the Makernote field and overwriting it isn't too difficult, but it requires some more research on my part, plus some safety features, like anticipating firmware changes.
If the targeted field starts to shift after new firmware it could seriously corrupt files.
Then I discovered something else: the temperature of the camera is also stored in the Makernote.
And since reading is somewhat easier than writing, I decided to start with that one.
Secret?
Then I got interested again in some mysterious fields I haven't been able to figure out. And low and behold, I think I discovered a Leica secret!
I've successfully enabled the RAM disk in the Leica (yes there is a RAM disk in there, I just don't know what I'm looking at: the buffer or something additional - if you read this and you know what it is, let me know) and I am now able to actually record a DNG on it. It has exactly enough space for one DNG.
So far that RAM always stayed empty, I've looked at it before.
I presume Leica put that RAM disk in there for either testing the M9 internally in their factories, or for tethered shooting. The option to turn on the RAM disk isn't documented (not that I know of anyway), but it's a very pleasant discovery if it does what I think it does.
Haven't tried to get the image out yet - which seems to be mandatory, because a second shot freezes the camera: the ram disk is full.
So at this point I'm not sure if this is going to lead to something. Also have to figure out if the necessary events for picking the DNG from the RAM disk are available, and if that succeeds, if the pick up can be done before the write to the SD card (if that's still going on, also something I have to test). I might then be able to start skipping the SD card reading (that would be a big bonus). If this succeeds it will speed up the transfer quite a bit.
Will keep you updated and I think I will release 1.9 soon with at least the temperature reading...
He seemed quite happy with it, but had some remarks. One of them was the idea to overwrite the aperture field in the EXIF data, since it's a guessed value. The camera doesn't know the F-stop of the lens because there's no electronic connection between lens and camera body. The camera just guesses a bit through a secondary light reader (a small dot near the red label).
I liked the idea.
Set a value in M9Tether and the field is filled in properly, since you know what the F-stop is. Obviously there's a lot of room for error if you change the aperture but not the setting in M9Tether, but hey, then it's your own fault. And I won't touch the DNGs on the SD card. This would only be done on the transferred files, so the original is always there as a backup 'guess'.
So I dove into the EXIF of the DNG and JPGs produced by the M9.
Turns out the setting is in the Makernote field and overwriting it isn't too difficult, but it requires some more research on my part, plus some safety features, like anticipating firmware changes.
If the targeted field starts to shift after new firmware it could seriously corrupt files.
Then I discovered something else: the temperature of the camera is also stored in the Makernote.
And since reading is somewhat easier than writing, I decided to start with that one.
Secret?
Then I got interested again in some mysterious fields I haven't been able to figure out. And low and behold, I think I discovered a Leica secret!
I've successfully enabled the RAM disk in the Leica (yes there is a RAM disk in there, I just don't know what I'm looking at: the buffer or something additional - if you read this and you know what it is, let me know) and I am now able to actually record a DNG on it. It has exactly enough space for one DNG.
So far that RAM always stayed empty, I've looked at it before.
I presume Leica put that RAM disk in there for either testing the M9 internally in their factories, or for tethered shooting. The option to turn on the RAM disk isn't documented (not that I know of anyway), but it's a very pleasant discovery if it does what I think it does.
Haven't tried to get the image out yet - which seems to be mandatory, because a second shot freezes the camera: the ram disk is full.
So at this point I'm not sure if this is going to lead to something. Also have to figure out if the necessary events for picking the DNG from the RAM disk are available, and if that succeeds, if the pick up can be done before the write to the SD card (if that's still going on, also something I have to test). I might then be able to start skipping the SD card reading (that would be a big bonus). If this succeeds it will speed up the transfer quite a bit.
Will keep you updated and I think I will release 1.9 soon with at least the temperature reading...
Labels:
leica M9,
leica talk,
m9tether
Sunday, March 6, 2011
M9Tether 1.8 released
Version 1.8 contains mainly bug fixes and some minor new options.
Preview window
This version adds a button behind the option 'Preview JPG...' to open the JPG viewer. In previous versions, if the viewer contained pictures and you closed it, there was no way of opening the window again. Only by taking the next shot the viewer would show.
Restore set
Adds option to view the restore set when clicking the 'Camera info...' button in the main window. The line above the restore set will indicate if the set is actually written to the camera. This depends on the selection in the main window (on or off).
Bugfixes
Fixes bug where the application would not start up properly. This happened with multiple PTP devices connected to the PC after double clicking on the camera entry in the devices list shown at startup.
Fixes bug where the checkmark 'Use JPG only as preview (do not store on PC)' was still of influence even when grayed out. This could lead to JPGs not being transferred to the PC.
The resource problem of the JPG viewer returned, but now after some 35 shots. I solved this by better detection when out of resources. It means the number of photos being held in one session is dependent on your system. If a resource problem is detected at some point in the session, the first photo of the session will be erased to free up space. If all goes well (apart from not all photos showing when you navigate back) you won't notice anything of this, and every new shot will be shown.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Done?
Apart from more bugs showing up I think I'm done now for a while, unless someone has a request or a good suggestion to extend the program. I can't think up anything new to add at this moment.
Nerd alert...
I've been trying to implement the Profile setting of the camera, but besides the fact that it's a pretty useless setting to implement, it seems (like with a few other settings) the WPD/PTP implementation on the camera side contains bugs.
The profile setting can handle 4 values according to the camera (the numbers 0, 1, 2 and 3) when you interrogate it through PTP.
However, the total number of values it needs to hold is 6 (0 for the dash, 1 for Snapshot profile, 2 to 5 for profile 1 to profile 4).
It means that the camera can hold 6 values but tells the outside world it can only hold 4, with a maximum actual value of 3. This leads to errors when trying to set it to profile 3 (value 4) and profile 4 (value 5) through PTP (those values are then beyond the faulty PTP specs for the setting).
But if you set the profile on the camera, the value set is actually correct (and can go higher than 3).
So, reading the value is ok and you get the right profile number, but setting the value through PTP leads to errors when PTP recognises you try to go beyond that faulty limit of 4 values.
It means that through PTP you can only set the dash, the snapshot profile and profile 1 or 2, but not profile 3 or 4.
Another quirk is that the value is actually implemented as a propvariant bVal - VT_UI1 - which would suggest a boolean 'yes/no' only. Turns out the bVal can hold more than just a 0 or 1 (it's an unsigned byte), so that's not really the issue, but it seems a bit weird.
I'm not fully sure if these errors are firmware related or driver related, but they do make it impossible to implement certain settings correctly. This particular 'profile' bug doesn't seem to be driver related, since it's the camera's software actually claiming the wrong (too low) maximum value.
Then again, I can't rule out the driver messing it up.
Another faulty one is the battery power level.
It's implemented by Leica, but the only value you get out of it is 'ERROR' and 'invalid function called' when it should give back a simple 0 to 100: A percentage of battery power left. But somewhere low level this goes wrong. It would be nice to be able to actually show the battery level during tethered shooting, so it's too bad this isn't working.
I have no clue where this one goes wrong, but it's either the driver or the firmware.
Leica never produced their own driver, so the Microsoft ones will have to do, but testing on Vista does suggest that at least some of the issues are driver related (like the format bug on Vista).
I've looked into producing my own driver for the M9 by the way, but that's such a messy process that I gave up on it. Maybe in future, for now it's not worth the trouble, cause it wouldn't expose new settings, only perhaps - big perhaps - fix a few of these faulty ones.
This all means there's no more settings that can be handled by M9Tether, until Leica brings out new firmware to tackle these bugs (assuming some of them are firmware issues and Leica is aware of them, this stuff is after all pretty nerdy...).
Preview window
This version adds a button behind the option 'Preview JPG...' to open the JPG viewer. In previous versions, if the viewer contained pictures and you closed it, there was no way of opening the window again. Only by taking the next shot the viewer would show.
Restore set
Adds option to view the restore set when clicking the 'Camera info...' button in the main window. The line above the restore set will indicate if the set is actually written to the camera. This depends on the selection in the main window (on or off).
Bugfixes
Fixes bug where the application would not start up properly. This happened with multiple PTP devices connected to the PC after double clicking on the camera entry in the devices list shown at startup.
Fixes bug where the checkmark 'Use JPG only as preview (do not store on PC)' was still of influence even when grayed out. This could lead to JPGs not being transferred to the PC.
The resource problem of the JPG viewer returned, but now after some 35 shots. I solved this by better detection when out of resources. It means the number of photos being held in one session is dependent on your system. If a resource problem is detected at some point in the session, the first photo of the session will be erased to free up space. If all goes well (apart from not all photos showing when you navigate back) you won't notice anything of this, and every new shot will be shown.
Download
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Done?
Apart from more bugs showing up I think I'm done now for a while, unless someone has a request or a good suggestion to extend the program. I can't think up anything new to add at this moment.
Nerd alert...
I've been trying to implement the Profile setting of the camera, but besides the fact that it's a pretty useless setting to implement, it seems (like with a few other settings) the WPD/PTP implementation on the camera side contains bugs.
The profile setting can handle 4 values according to the camera (the numbers 0, 1, 2 and 3) when you interrogate it through PTP.
However, the total number of values it needs to hold is 6 (0 for the dash, 1 for Snapshot profile, 2 to 5 for profile 1 to profile 4).
It means that the camera can hold 6 values but tells the outside world it can only hold 4, with a maximum actual value of 3. This leads to errors when trying to set it to profile 3 (value 4) and profile 4 (value 5) through PTP (those values are then beyond the faulty PTP specs for the setting).
But if you set the profile on the camera, the value set is actually correct (and can go higher than 3).
So, reading the value is ok and you get the right profile number, but setting the value through PTP leads to errors when PTP recognises you try to go beyond that faulty limit of 4 values.
It means that through PTP you can only set the dash, the snapshot profile and profile 1 or 2, but not profile 3 or 4.
Another quirk is that the value is actually implemented as a propvariant bVal - VT_UI1 - which would suggest a boolean 'yes/no' only. Turns out the bVal can hold more than just a 0 or 1 (it's an unsigned byte), so that's not really the issue, but it seems a bit weird.
I'm not fully sure if these errors are firmware related or driver related, but they do make it impossible to implement certain settings correctly. This particular 'profile' bug doesn't seem to be driver related, since it's the camera's software actually claiming the wrong (too low) maximum value.
Then again, I can't rule out the driver messing it up.
Another faulty one is the battery power level.
It's implemented by Leica, but the only value you get out of it is 'ERROR' and 'invalid function called' when it should give back a simple 0 to 100: A percentage of battery power left. But somewhere low level this goes wrong. It would be nice to be able to actually show the battery level during tethered shooting, so it's too bad this isn't working.
I have no clue where this one goes wrong, but it's either the driver or the firmware.
Leica never produced their own driver, so the Microsoft ones will have to do, but testing on Vista does suggest that at least some of the issues are driver related (like the format bug on Vista).
I've looked into producing my own driver for the M9 by the way, but that's such a messy process that I gave up on it. Maybe in future, for now it's not worth the trouble, cause it wouldn't expose new settings, only perhaps - big perhaps - fix a few of these faulty ones.
This all means there's no more settings that can be handled by M9Tether, until Leica brings out new firmware to tackle these bugs (assuming some of them are firmware issues and Leica is aware of them, this stuff is after all pretty nerdy...).
Labels:
leica M9,
leica talk,
m9tether
Monday, February 28, 2011
M9Tether 1.7 released
Version 1.7 contains some new options.
Opening transferred photos
There's now the option to open the transferred JPG or DNG - or both - through the default application. The default application is maintained by Windows (on file extension).
You can also select your own application.
You get to this option by clicking the button on the right of the option 'Store captures on PC' in the main window. Note that the button will only show if you have this option selected.
In the window that appears you can select either the default application or select your own. Set your own application by clicking the button on the left of the window.
Be careful though with selecting your own application, since M9Tether doesn't check the validity of the application nor does it know if the application you select can actually handle DNG or JPG. If it can't, errors might pop up after transfer.
Photos will only be opened by the set application if 'Store captures on PC' is turned 'on'.
If you want to use M9Tether with Lightroom, don't use this option, but set up an auto-import folder in Lightroom, and point the store path of M9Tether (in the main window) to that folder.
Timed shoot repeat
Due to a change in event handling in 1.6, it is now possible to repeat timed shooting at all intervals. The software will wait till the camera is ready to take the next shot.
Note though that if the interval is set lower than the actual transfer time, the proper interval can not be maintained. If timing is important, make sure that the exposure, noise reduction and transfer doesn't take longer than the set interval.
Miscellaneous
Adds a 'Stop' button to break the software exposure bracketing and timed shooting.
New known bug
If you have multiple WPD/PTP enabled devices connected to the computer, double clicking on the camera in the list that pops up will lead to an error and M9Tether won't show.
The workaround is to select the camera (by single click) and then click on the button 'Connect to selection'.
This bug will be fixed in version 1.8.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Opening transferred photos
There's now the option to open the transferred JPG or DNG - or both - through the default application. The default application is maintained by Windows (on file extension).
You can also select your own application.
You get to this option by clicking the button on the right of the option 'Store captures on PC' in the main window. Note that the button will only show if you have this option selected.
In the window that appears you can select either the default application or select your own. Set your own application by clicking the button on the left of the window.
Be careful though with selecting your own application, since M9Tether doesn't check the validity of the application nor does it know if the application you select can actually handle DNG or JPG. If it can't, errors might pop up after transfer.
Photos will only be opened by the set application if 'Store captures on PC' is turned 'on'.
If you want to use M9Tether with Lightroom, don't use this option, but set up an auto-import folder in Lightroom, and point the store path of M9Tether (in the main window) to that folder.
Timed shoot repeat
Due to a change in event handling in 1.6, it is now possible to repeat timed shooting at all intervals. The software will wait till the camera is ready to take the next shot.
Note though that if the interval is set lower than the actual transfer time, the proper interval can not be maintained. If timing is important, make sure that the exposure, noise reduction and transfer doesn't take longer than the set interval.
Miscellaneous
Adds a 'Stop' button to break the software exposure bracketing and timed shooting.
New known bug
If you have multiple WPD/PTP enabled devices connected to the computer, double clicking on the camera in the list that pops up will lead to an error and M9Tether won't show.
The workaround is to select the camera (by single click) and then click on the button 'Connect to selection'.
This bug will be fixed in version 1.8.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Labels:
leica M9,
leica talk,
m9tether
Sunday, February 20, 2011
M9Tether 1.6a released
Sad to say, but version 1.6 contained a nasty resource problem.
After taking 10 to 15 shots, the JPG viewer would stay empty.
Keeping all those photos stored in memory (new in version 1.6) turned out to be the culprit.
The problem is solved, but I might add some extra safeguards in the next release or perhaps cap to a maximum.
This bug didn't affect the writing of the actual JPG or DNG to PC, if that option was turned on.
1.6a is available for download at: http://www.mymymyohmy.com/software/m9tether.html
After taking 10 to 15 shots, the JPG viewer would stay empty.
Keeping all those photos stored in memory (new in version 1.6) turned out to be the culprit.
The problem is solved, but I might add some extra safeguards in the next release or perhaps cap to a maximum.
This bug didn't affect the writing of the actual JPG or DNG to PC, if that option was turned on.
1.6a is available for download at: http://www.mymymyohmy.com/software/m9tether.html
Labels:
leica M9,
leica talk,
m9tether
Sunday, February 13, 2011
M9Tether 1.6 released
[Edit: Leica responded to my initial inquiry about the problem on Windows Vista, where the camera refuses to change the Format setting (JPG / DNG + JPG etc.) through WPD/PTP. The promise was to try to get me in touch with one of their engineers or firmware developers, so now I'm waiting patiently, hoping to hear back from them...]
Version 1.6 contains some new options and a few improvements.
Restore option
There's now the option to restore the camera's startup settings when you close the program, provided the camera is still connected. It prevents mishaps when you take your camera out and didn't check the settings after use of M9Tether.
If you do want to change settings on the camera more permanently, without turning off the restore option, click the small button next to the 'About...' button. It becomes available as soon as settings do not match the initial startup settings of the camera anymore. By clicking on it, you create a new restore set, based on the current settings.
If you turn off the camera or disconnect it before you close the software, nothing will be restored.
Exposure bracketing
Since the option to turn 'Exposure bracketing' on or off on the camera can't be implemented, I decided that a software version would also do. It's called 'Software exposure bracketing'. It allows for more photos than just three. After switching on the option, use the button that appears to the right (behind the option) to change the settings.
Don't use the software option when the camera's exposure bracketing is set to 'on'. You might end up with 3 times as many photos. The software bracketing is quite slow, since every photo has to be written to the SD card first, and it doesn't work together with 'Timed shooting'.
Miscellaneous
Positions of the main window and the JPG viewer are now remembered after closing, including the size of the JPG viewer.
And also new: the JPG viewer will now 'keep' all the photos within one session. You can navigate through them with the buttons that appear when you move your mouse to the bottom of the viewer.
The problem with those buttons in the JPG viewer, I thought I had solved in 1.5a, returned, so I spent some quality time figuring out what went wrong. It's fixed more permanently in this new release.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Version 1.6 contains some new options and a few improvements.
Restore option
There's now the option to restore the camera's startup settings when you close the program, provided the camera is still connected. It prevents mishaps when you take your camera out and didn't check the settings after use of M9Tether.
If you do want to change settings on the camera more permanently, without turning off the restore option, click the small button next to the 'About...' button. It becomes available as soon as settings do not match the initial startup settings of the camera anymore. By clicking on it, you create a new restore set, based on the current settings.
If you turn off the camera or disconnect it before you close the software, nothing will be restored.
Exposure bracketing
Since the option to turn 'Exposure bracketing' on or off on the camera can't be implemented, I decided that a software version would also do. It's called 'Software exposure bracketing'. It allows for more photos than just three. After switching on the option, use the button that appears to the right (behind the option) to change the settings.
Don't use the software option when the camera's exposure bracketing is set to 'on'. You might end up with 3 times as many photos. The software bracketing is quite slow, since every photo has to be written to the SD card first, and it doesn't work together with 'Timed shooting'.
Miscellaneous
Positions of the main window and the JPG viewer are now remembered after closing, including the size of the JPG viewer.
And also new: the JPG viewer will now 'keep' all the photos within one session. You can navigate through them with the buttons that appear when you move your mouse to the bottom of the viewer.
The problem with those buttons in the JPG viewer, I thought I had solved in 1.5a, returned, so I spent some quality time figuring out what went wrong. It's fixed more permanently in this new release.
See http://www.mymymyohmy.com/software/m9tether.html for the details and download.
Labels:
leica M9,
leica talk,
m9tether
Saturday, February 5, 2011
M9Tether 1.5a released
Turned out the button problems in the redesigned JPG viewer of version 1.5 extended to all the buttons (the ones that appear in the viewer when you move the mouse down in the window).
This problem is fixed in version 1.5a, available for download at: http://www.mymymyohmy.com/software/m9tether.html
This problem is fixed in version 1.5a, available for download at: http://www.mymymyohmy.com/software/m9tether.html
Labels:
leica M9,
leica talk,
m9tether
Thursday, February 3, 2011
M9Tether 1.5 released
Version 1.5 contains a redesigned JPG viewer, which tackles the somewhat slow zooming of 1.4 and fixes some bugs. The viewer also wasn't working properly under the Windows 7 Basic and Classic themes with Aero disabled. It can now differentiate between themes.
See http://www.mymymyohmy.com/software/m9tether.html for the details
I did notice some problems with the 'zoom in' and 'zoom out' buttons after releasing 1.5, but I haven't figured out yet what the exact problem is. I guess an update on 1.5 is in order soon.
I'm also trying to implement a rotation algorithm.
The camera doesn't rotate photos taken in portrait. I'm sure the EXIF data holds the info on it, because Lightroom does rotate them automatically. I do not intend to include EXIF reading, that's beyond the purpose of the application and you can already combine M9Tether with Lightroom if you really want the correct result immediately, but it would be nice to have two extra buttons to rotate the JPG in the viewer. This proves to be however a bit more complicated than I imagined. Perhaps in version 1.6.
See http://www.mymymyohmy.com/software/m9tether.html for the details
I did notice some problems with the 'zoom in' and 'zoom out' buttons after releasing 1.5, but I haven't figured out yet what the exact problem is. I guess an update on 1.5 is in order soon.
I'm also trying to implement a rotation algorithm.
The camera doesn't rotate photos taken in portrait. I'm sure the EXIF data holds the info on it, because Lightroom does rotate them automatically. I do not intend to include EXIF reading, that's beyond the purpose of the application and you can already combine M9Tether with Lightroom if you really want the correct result immediately, but it would be nice to have two extra buttons to rotate the JPG in the viewer. This proves to be however a bit more complicated than I imagined. Perhaps in version 1.6.
Labels:
leica M9,
leica talk,
m9tether
Friday, January 28, 2011
M9Tether
So yes, the observant reader will have noticed I am using a Leica M9 now.
I will get back to writing about that, because it has been quite an experience so far. It's difficult to stay objective about this camera seeing the expense, but I do have my thoughts about it.
Leica didn't provide any software for shooting the M9 tethered (tethered shooting is when you connect the camera to a computer, whereby software enables you to operate the camera remotely and adds the option to also operate the camera manually - still connected to the computer - and show the photos you shoot immediately on the computer screen).
So I decided to write my own software.
It's been online for a while, it's tested a bit, and it seems to work quite well.
It's written for Windows 7, but also works on Vista (note the exception on Vista - I'm currently trying to get in touch with Leica about that one) and it does work in conjunction with Lightroom if you set up an auto import folder.
So if you stumble onto this blog and own or use an M9 and you want tethered shooting, have a look here:
http://www.mymymyohmy.com/software/m9tether.html
I will get back to writing about that, because it has been quite an experience so far. It's difficult to stay objective about this camera seeing the expense, but I do have my thoughts about it.
Leica didn't provide any software for shooting the M9 tethered (tethered shooting is when you connect the camera to a computer, whereby software enables you to operate the camera remotely and adds the option to also operate the camera manually - still connected to the computer - and show the photos you shoot immediately on the computer screen).
So I decided to write my own software.
It's been online for a while, it's tested a bit, and it seems to work quite well.
It's written for Windows 7, but also works on Vista (note the exception on Vista - I'm currently trying to get in touch with Leica about that one) and it does work in conjunction with Lightroom if you set up an auto import folder.
So if you stumble onto this blog and own or use an M9 and you want tethered shooting, have a look here:
http://www.mymymyohmy.com/software/m9tether.html
Labels:
leica M9,
leica talk,
m9tether
Subscribe to:
Posts (Atom)