Hello together!
I'm planing to use the gPhoto2 library for a special time lapse project in junction with the Sony A7S. I got quite ahead and the library is doing a good job. Though there are some odds with some returned widgets that appear to be partly wrong, but I can deal with that.
What is bothering me somewhat is the rather slow speed of how the adjustments are done (for instance the shutter speed). Apparently the library cannot simply set the widgets from one value to another, but has to step through all valid values until the target-value has been reached (so just like in case of the real widget resp. dial on the camera). Essentially this procedure is ok. However it takes quite some time to switch from one value to the next one (I did not measure the time precisely, but I'd say that it takes almost one second per value). When there have to be made several adjustments and lots of steps have to be made, it takes easily a considerable amount of time and might block the system for one minute or so until the desired settings are ready.
I'm planning to dig into the gPhoto2 library, understand it's basic operation in that aspect and see whether this can be improved, perhaps. But at a first step I thought that it might be better to ask here whether there is room for optimization at all. For instance when it is the camera itself that is introducing the delays, there is certainly no way to go. On the other hand I can draw preview images at a rate of around 10Hz out of the camera, which seems rather quick in contrast.
So to conclude with my actual question: Is it worth to dig into the library in order to improve that situation somewhat, or is this a well-known issue that can't be solved in theory anyway?
Thanks a lot in advance for any comments!
Mario
which libgphoto2 version is in use?
older sony alpha have this stepping method, and we tried to improve it.
very new sony alpha can set some values directly.
Thanks for your response, Marcus.
Indeed, I checked that and I'm running version 2.5.25, which is the latest standard version installed on Ubuntu 20.04LTS which I'm running. The recent version is 2.5.27, and the release notes of 2.5.26 mention some changes in that direction.
I did grab the source code of 2.5.27 and did install it more or less as usual with ./configure --prefix=/usr/local; make; make install. However, it does not find the camera any more now. I did also test this with gphoto2 (version 2.5.23 as installed by default in Ubuntu 20.04) and did also test with version 2.5.27 that I just did compile from source. As soon as I draw the new libgphoto2 libs from /usr/local/bin I get the error message "Could not detect any camera". When I draw the old version 2.5.25 libraries from /usr/bin it's working fine. So this is no issue with the camera.
gPhoto2 is telling me to run it again in some log reporting mode. I did that and attached the log file. Maybe there is something visible from....
Btw., the problem is the same with a Sony a6300. It is not detected as well any more.
As for the actual issue with the long delays: The stepping through the single values is not that big issue, since for autoexposure adjustments you would only go one up or one down anyway. But it's the time it takes for a single step, which is finally limiting the maximal image rate and is also making the system a bit unresponsive.
Regards,
Mario
As a follow-up: I also tried to build version 2.5.26 and even 2.5.25 from the source. Both are failing equally. Since version 2.5.25 that is coming with Ubuntu 20.04 is working, there seems to be an issue with the compilation. Although configure is reporting some warning that some camlibs are not build, I think that this is not the reason, since this seems to be dedicated to a Lumix library that appears to be excluded by default. For reference I'm attaching the configure output I got for 2.5.25.
Yet another follow-up: The compilation issue has been solved. It was the libusb-dev packet that was missing. I'll report more later on regarding the actual topic.....
Ok, there we go....
Version 2.5.27 does improve the situation, indeed. But apparently only for the shutter speed. On the A7S it is still somewhat slow, but around three times faster than before. That's better than nothing.... On the newer Sony a6300 the settings are changed almost instantly now - this is almost perfect there.
Might it be that the same improvement that has been done for the shutter speed setting could also be applied for the aperture and ISO settings?
for iso this should also work, the 7c supports the fast ISO setting.
can you try setting d226 property from the other tree to see if that works?
for aperture I currently do not know the "fast " property, nothing stands out.
You are referring to the A7S with "7C"???
I tried to check that with the d226 property. But there is no such property for both the A7S and the a6300 here. When I run
/usr/local/bin/gphoto2 --list-all-config
(gphoto2 verison 2.5.27 and libgphoto2 version 2.5.27) I'm also getting an entry
/main/other/d21e
which seems to resemble the ISO settings. However, cannot change it. When I execute for instance
/usr/local/bin/gphoto2 --set-config-index=/main/other/d21e=5
then nothing is happening. When I do the same with the normal ISO property, i.e.
/usr/local/bin/gphoto2 --set-config-index=/main/imgsettings/iso=5
it is working as expected.
You mention a "fast property". When I change the shutter speed, I'm still using the property "shutterspeed" resp. " /main/capturesettings/shutterspeed" and it is ultra-fast for the a6300 and somewhat faster for the A7S (when comparing 2.5.27 against 2.5.25). So at least there I'm not using anything like a "fast property". It is just faster when the newer libgphoto2 is being in use.
Just for reference I'm attaching the --list-all-config output of gphoto2 for both the A7S and the a6300.
ok, i confused with another reporter on github, sortry.
i checked, a7s and a6300 do not have the "direct set" methods, but still the stepping modes.
What we do different for shutterspeed in 2.5.27 is that we now do multi-steps to go to the target quicker.
Not all Sonys seem to support that (my old A58 does not), and only allow single stepping between values.
We can try to do that for iso and aperture modes too.
Ok, I see. So it might be that the improvement I see here is not there when I'm making just single steps. Right now I did check this only by doing 10 steps or so and then measure the time. Since there is usually just a single step adjustment needed for time lapse applications, this multi-stepping would not help with regard to increasing the frame rate. However, I believe that it would be generally useful to do that multi-stepping also for ISO and aperture. My particular application does suffer somewhat that it is setting some center-values for shutterspeed, ISO, and aperture during startup and then adjusts the values as the situation demands. In case the initial settings of the camera is far-off of these center-values, it takes quite some time until the new values are set. This process could be speed up by doing this multi-setting also for ISO and aperture. However, this is more of a somewhat nasty thing rather than a knock-out criterion and one can live with that.
Anyway, if that multi-stepping can also be done for ISO and aperture, it should be done, I think. If needed, I can test these things on the A7S as well as on the a6300 and provide reports.
Nonetheless I'm still wondering why it takes so long to make these adjustments (let them be single- or multi-stepped). Are the cameras really that slow here, or is this a result of various compromises? I did browse a little bit through the libgphoto2 sources but was not yet able to find the code that is talking to the camera in the end.