Support for K-70? #14
Comments
|
K-70 is not yet supported. I've created a test version, please test it and copy the output here. |
|
Thank you for your very fast response. The GUI version crashed on startup. This is the output from Visual Studio Debugger: Here is the output of the status from the command line: I was also able to get a picture in manual and "green" mode: So actually, everything I need is there 😄 👏 👍 |
|
Looks promising. I attach a new version which tries to parse the status info. Please try the following command:
It might also fix the GUI. I'm not sure. You can also add |
The GUI does not crash (immediately) anymore. If I press "Green Button" is hangs. I can access status, focus and take picture. But it looks like pictures are not saved. At least I cannot find them. |
|
Most of the fields look good. "af point select" is invalid, I'll fix it, because it may cause problems. Battery fields also look strange but those fields are not too important. Green button: It is best to test the command line version first. Try to take a picture with and without --green option. GUI save: The GUI does not save the image if you take a picture (it saves only in the camera buffer). You can save it using the save as button. Or alternatively you can turn on auto save and add specify the prefix of the filename. |
|
The second version you send me seems to include some regression: With the first version I could take pictures and transfer them to the computer. With the second version, the (command line) program hangs and only a picture file with size 0 is created. I have attached two log files, _v1 was created using the first version you linked in your comment on 2016-12-13, _v2 used the second version of 2016-12-14. |
|
So I traced down my problem (without really knowing what I am doing): The check at Line 909 in 0c3d8e2 Line 607 in 9e0be49 If I understand the code correctly, the status buffer should contain a 1 at the correct address. By setting the bufmask address to 0x0C, it seems to work (because the value at that address is equal to 1). Is this just a coincidence? Actually, what is the meaning of the buffer mask? |
|
There is a buffer in the camera for the images. It can store several images but no more than 16. bufmask is a 16-bit word. Each bit shows if the camera buffer is occupied/empty at that index. Invalid bufmask reading may cause the strange regression. My first version ignored the bufmask , the second tried to read it. Test it using bracketing. If you take 3 images using bracketing the camera stores the 3 images in the camera buffer and the program only downloads (and deletes) the images at the end. If it works than your patch is great. Send me a pull request after that. (If you don't want to do that just copy the info here, and I'll patch it). |
|
Ok, what if found out is: There seems to be only one buffer in the camera. If I select bracketing and take 3 or 5 pictures, I am able to store the last picture as raw file (if I selected JPEG as standard format). The other 2 (or 4) pictures seem not available. I tried different setups and downloaded the hex-status, and nearly all the time the buffer address 0x0c contains 0x01. Only in one case, there was 0 stored. Unfortunately, I was not able to reproduce this. Is there a known way to clear this internal buffer? It looks like, if I remove the SD card, this buffer address contains zero, after turning on the camera. If I take one picture, it is back to 1. But this also does not work all the time. So what to do? My suggestion would be to use 0x0c as address for the buffer. |
|
Limiting the camera buffer size to 1 is a very strange change. Quite a few functions of the program will work even in this case, but a few advanced things (like bracketing...) will not work. It also assumes that 0x0c is 0 at the beginning, 1 after taking an image and 0 after deleting the buffer. If 0x0c is always 1 it will not work. Camera buffers can be deleted by the |
|
@jmozmoz I attach a new test version which uses your patch. Someone tested the Linux/K-70 and the program deleted the SD-card. This is very strange because the program is not able to save images to the sd-card. Make a backup before testing the K-70 support. |
|
I saw a somewhat similar problem: At some point, the SD cards seems to be empty (if accessed from within the camera). But if I put it into a computer, the images were still there. I put it back into the camera and again, it looked empty. I turned the camera off and on several times, but it seemed not to help. Finally, I removed the SD card (I think, the camera) was turned off at that moment, and put it back into the camera while the camera was turned on. Then suddenly, the pictures were again accessible from the camera. So, did the user tried to read the SD card from a computer (directly putting it into a card reader and not via the USB-cable from within the camera)? |
|
But I will further investigate the buffer issue... |
|
@jmozmoz I've asked the user about it. Waiting for the answer. I've added --dangerous switch to the program (commited to github). Both the commandline and GUI version. Without this the program will refuse to connect to K-70. |
|
I added a python wrapper to the internal functions of pktriggercord to make it easier to experiment: 18000b3 and the corresponding branch. At the moment I just added a small test script, which prints the name of the camera and then exists. What I have found out about the SD card "erasing": As long as the camera is connected to pktriggercord, it will show an empty SD card in the display (which turns on during this time). This even happens, if you use the command line tool pktriggercord-cli and it stops after detecting, that the camera is a K-70. The display shows that 9999 pictures can be stored on the camera. Normally, after closing the connection correctly and then disconnect the camera from the computer, the SD card is handled correctly and the pictures can be accessed by the camera. So what might have caused the problem of the user user and what I have observed was some error of the program (or a break by the user with CTRL+C) which left the camera in an invalid state, because the connection was not closed correctly. Now that I have the Python wrapper, I will proceed with experiments about the internal buffer. P.S. I use Python 3.4 (but it looks like it is also working with Python 2.7) |
|
Ok, here is what I found: If the number of bracketing pictures set in the camera is 3, then after the third shot, it contains 0. Correspondingly, if the number of bracketing pictures is set to 5 in the camera, this counter(?) starts with 1 at the beginning (before the first shot), after the first shot it is still 1, then 2, ..., after the fifth shot, it contains 0. So this looks like a counter. There are no other changes in the status buffer (ok, sometimes battery values). I tested this, by adding the following code to pktriggercord-cli after the call to if (1) {
int bufsize = pslr_get_model_buffer_size( camhandle );
uint8_t status_buffer[MAX_STATUS_BUF_SIZE];
pslr_get_status_buffer(camhandle, status_buffer);
hexdump( status_buffer, bufsize > 0 ? bufsize : MAX_STATUS_BUF_SIZE);
fflush(stdout);
}I also tried to call Does this counter also exist for other cameras? I tried to force to read out the buffers by removing the check for the bufmask. However, this resulted in a crash of the camera software. The only way to get it to work again was remove the battery. |
|
One additional question: At the moment, the code contains mixed spaces and tabs. Are there any coding style rules, e.g. only spaces (8 characters indention) or only tabs? |
|
@jmozmoz I'll check that counter (using my K-x). Coding style rules: I prefer spaces (4 character indentations). I should convert all the remaining tabs one day... |
|
@jmozmoz I've tested bracketing with my K-x, and I've found a similar field. The address of the byte is 0xe7 (so 0xe4 for 32-bit big-endian). It is 0 at the beginning. After the first shot it's 1, after the second it's 2. After the third (=last) it's 0 again. I cannot test the 5-picture mode because my camera does not support it. So it's similar but not exactly the same. |
|
@jmozmoz I've added a new status field auto_bracket_picture_counter to the program. |
|
@jmozmoz I've created a new Makefile target (astyle) to format the source code (using astyle) and reformatted the code. So far I mostly modified only whitespaces (like replacing tabs using spaces) later I'll also clean up braces and other parts of the code. Maybe I'll also check the style in travis. |
|
@jmozmoz Does you bufmask change work correctly? Can you save images? |
|
@asalamon74 Unfortunately I still did not find the correct address for the bufmask. I can download one picture, or several pictures, but not with bracketing turned on. I have attached a log for the following command: In the camera bracketing is set to 5 frames from -0.6 to +0.6 EV with step size 0.3 EV. The first frame is downloaded but then the command stalls. (so exactly the same command as above is working if bracketing is turned off in the camera). |
|
I think I tried everything, but I was never able to download more than one picture in bracketing mode. So I guess the handling of buffers changed. I can take 3 or 5 shots on the camera quite fast before the picture are written to the SD card, so they are somewhere buffered. I also tried to ignore the bufmask before selecting/downloading the pictures but this also does not help. So I would suggest to say the K70 is supported only in limited fashion without bracketing or continuous shooting. |
|
I've started testing the empty SD card (Card is not formatted error message) problem (I have a new K-70 camera):
|
|
A small update on the bracketing problem: If someone wants to take bracketing shots (e.g. 3 pictures) using older Pentax cameras, one has to press the shutter button multiple times. pktriggercord-cli was designed to support this mode. Newer Pentax cameras has a so called 'one push bracketing mode' when one has to press a single button and the camera takes all the pictures at once. I've found a way to read this field for K-70, so now pktriggercord-cli knows when to send multiple and when to send single buttonpress commands. Unfortunately I can still only access the first buffer image, so it's not a big help. |
|
I've found a solution for the bulb problem, I'm able to take bulb pictures using K-70. Hopefully the solution will work for the other cameras as well, but it needs camera-specific data. The bulb_modern branch contains the solution. I'll merge it into master when I eliminate the hardwired K-70 code. |
|
I have removed the |
|
I've merged bulb_modern branch into master |
|
Just following up on this (very exciting to discover this project), with the K-70 what is currently not supported? By the way, I noticed there is no mention of the K-70 in the documentation, would support a pull request but not sure what the status of it actually is. |
|
@legel K-70 is not listed in the documentation because it is quite buggy. Pentax cameras can store several images in their buffer, so you can take multiple images using pktriggercord before you need to download (and delete) the image from the buffer. Unfortunately we can only access the first image for K-70 which makes it quite difficult to use the program. I was looking for several ways to read the other images, probably it would be a better approach to create a limited mode for K-70 which always downloads/deletes the image before the next shot. You can download the latest version from github (not the latest release) and try it. For me it works better with the latest firmware, it was quite bad with the earlier versions. |
|
Thanks @asalamon74 this is good to know. A version that always downloads/deletes makes sense, and leaves no room for ambiguity so long as it is documented and maybe even printed to the user. |
|
I've modified the code, I'm using a different method to read the buffer mask. It is still not the single-buffer version I've mentioned above, but it's a more reliable way to find the first image at least. |
I can help with testing it on K3II |
|
I've modified the code, the command line version supports the single-buffer mode. I had to modify the bracketing handling:
During the testing I've realized, that the program works better if I turn on the camera first and connect it to the PC only after that. |
|
Unfortunately not only the number of buffers is limited to 1, but that buffer can only read once. So the GUI is not working correctly because it reads the buffer twice. first the preview (640x480) after the full size image (jpeg or raw). I've created a workaround, I read the fullsize jpeg instead of the preview, so now it's possible to show the preview and download the jpeg image. Unfortunately if I want to download the raw image, this workaround is not too good. Turning off preview would be possible, but it would make it rather difficult to use the GUI. |
|
@asalamon74 thanks. an update, I'm going to try to get this working "in production" with a Raspberry Pi, no GUI needed. The use case: the DSLR is attached to a 3 meter tall robotic arm with 6 joints, which is moving around objects that are being scanned by photogrammetric methods. So, ideally, there is a way to potentially dump the buffer's memory of the photo without needing to wait for USB to finish the transfer. But in any case, I'm able to engineer whatever hardware would be ideal for making continuous shoots of ~100 photos, as fast as possible, and open to any suggestions. Will update on progress (and some photos ;) cheers |
|
PS as I'm spec'ing hardware, and trying to push the investment already made in the K-70 to the max, and prepared to hack on some bytes streams or whatever, if there are any ideas with respect to e.g. faster USB transfer to a Raspberry Pi, ideas with respect to hacking the K-70 etc., I'd be open to exploring them... |
|
FYI I've got the DSLR hooked up with the Raspberry Pi, sending commands, seems to be working... at least, unless I'm missing something... when I ran @jmozmoz command: I managed to get 3 pictures downloaded to my Pi. Which is perfect. By the way, I installed the PKTriggerCord with the latest package available for the Pi, not from Github. |
|
This project sounds interesting. It is not possible to save the images to the SD card, the pictures should be downloaded to the computer via USB. Downloading is not too fast. We have already checked it (#9), I'm afraid it's not possible to speed it up. For most camera models it is possible to take multiple images (not 100, only a limited number) and download them only later one by one. Unfortunately it is not possible to use this feature for K-70, only the first buffer can be downloaded. The command line version is quite good for K-70, you might want to try the current github version, a few K-70 bugs has been fixed (for instance no need for --dangerous). So I think K-70 works quite well using the command line interface, but the image download will not be too fast. |
I tried to use the command line utility (using Windows) to connect to my K-70:
Is there any change to add support for it? Where to start?
The text was updated successfully, but these errors were encountered: