asalamon74
commented
7 years ago K-70 is not yet supported. I've created a test version, please test it and copy the output here.
Open jmozmoz opened 7 years ago
asalamon74
commented
7 years ago K-70 is not yet supported. I've created a test version, please test it and copy the output here.
jmozmoz
commented
7 years ago Thank you for your very fast response. The GUI version crashed on startup. This is the output from Visual Studio Debugger:
Unhandled exception at 0x76739170 (msvcrt.dll) in pktriggercord.exe: 0xC0000005: Access violation reading location 0x00000000.
If there is a handler for this exception, the program may be safely continued.
----
Exception thrown at 0x76739170 (msvcrt.dll) in pktriggercord.exe: 0xC0000005: Access violation reading location 0x00000000.
If there is a handler for this exception, the program may be safely continued.
----
and so on...Here is the output of the status from the command line:
c:\opt\pktriggercord-0.84.03>pktriggercord-cli -status --debug
Debug messaging is now enabled.
pktriggercord-cli 0.84.03
model (null)
device (null)
[C] plsr_init()
driveNum:24
Checking drive: C
Checking drive: D
Checking drive: E
Checking drive: F RICOHIMG DSC_K-70
Found camera RICOHIMG DSC_K-70
before connect
[C] pslr_connect()
[C] ipslr_status()
[C] command(fd=f0, 0, 1, 0)
[C] get_result(0xf0)
[R] => [1C 00 00 00]
[C] read_result(0xf0, size=28)
[R] => [02 00 00 00 00 00 00 00 10 02 00 02 01 00 80 80
00 00 00 00 02 00 00 00 00 00 00 00]
[C] ipslr_set_mode(0x1)
[C] _ipslr_write_args(cmd_2 = 0x0, {0x1})
[C] command(fd=f0, 0, 0, 4)
[C] get_status(0xf0)
[R] => ERROR: 0x01
[C] ipslr_status()
[C] command(fd=f0, 0, 1, 0)
[C] get_result(0xf0)
[R] => [1C 00 00 00]
[C] read_result(0xf0, size=28)
[R] => [02 00 00 00 00 00 00 00 10 02 00 01 01 00 80 80
00 00 00 00 00 00 00 00 00 00 00 00]
[C] ipslr_identify()
[C] command(fd=f0, 0, 4, 0)
[C] get_result(0xf0)
[R] => [08 00 00 00]
[C] read_result(0xf0, size=8)
[R] => [22 32 01 00 4A 02 00 00]
id of the camera: 13222
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 0
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 10 02 00 01 01 00 80 80
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
init bufmask=0x0
[C] ipslr_cmd_00_09(0x2)
[C] _ipslr_write_args(cmd_2 = 0x0, {0x2})
[C] command(fd=f0, 0, 9, 4)
[C] get_status(0xf0)
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 0
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 10 02 00 02 01 00 80 80
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] ipslr_cmd_10_0a(0x1)
[C] _ipslr_write_args(cmd_2 = 0x0, {0x1})
[C] command(fd=f0, 10, a, 4)
[C] get_status(0xf0)
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 0
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] pslr_camera_name()
pktriggercord-cli: K-70 Connected...
[C] pslr_get_status()
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 0
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] pslr_get_status()
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 0
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] pslr_get_status()
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 0
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
current iso : 0
current shutter speed : 0/0
camera max shutter speed : 0/0
current aperture : unknown
lens max aperture : unknown
lens min aperture : unknown
set shutter speed : 0/0
set aperture : unknown
fixed iso : 0
auto iso : 0-0
jpeg quality : 0
jpeg resolution : 24M
jpeg image tone : Natural
jpeg saturation : 0
jpeg contrast : 0
jpeg sharpness : 0
jpeg hue : 0
zoom : unknown mm
focus : 0
color space : sRGB
image format : JPEG
raw format : PEF
light meter flags : 0
ec : unknown
custom ev steps : 1/2
custom sensitivity steps : 0
exposure mode : 0 (NONE)
user mode flag : 0
ae metering mode : Multi
af mode : MF
af point select : Auto-5
selected af point : 0
focused af point : 0
drive mode : Single
auto bracket mode : off
auto bracket picture count : 0
auto bracket ev : unknown
shake reduction : off
white balance mode : Auto
white balance adjust : M7B7
flash mode : Manual
flash exposure compensation : 0.00
manual mode ev : 0.00
lens : M-42 or No Lens
battery : 0.00V 0.00V 0.00V 0.00V
I was also able to get a picture in manual and "green" mode:
c:\opt\pktriggercord-0.84.03>pktriggercord-cli --file_format=JPEG -o test.jpg -i 100 -t 2 -m M -a 4.5
c:\opt\pktriggercord-0.84.03>pktriggercord-cli --file_format=JPEG -o test1.jpg -m GREENSo actually, everything I need is there :smile: :clap: :+1: (ok, it would be nice to have all this status infos, but as everything is in the exif data of the picture, it is not so important)
asalamon74
commented
7 years ago Looks promising. I attach a new version which tries to parse the status info. Please try the following command:
pktriggercord-cli.exe --status_hex --debug
It might also fix the GUI. I'm not sure. You can also add --debug for the GUI.
jmozmoz
commented
7 years ago c:\opt\pktriggercord-0.84.03>pktriggercord-cli.exe --status_hex --debug
Debug messaging is now enabled.
pktriggercord-cli.exe 0.84.03
model (null)
device (null)
[C] plsr_init()
driveNum:24
Checking drive: C
Checking drive: D
Checking drive: E
Checking drive: F RICOHIMG DSC_K-70
Found camera RICOHIMG DSC_K-70
before connect
[C] pslr_connect()
[C] ipslr_status()
[C] command(fd=f0, 0, 1, 0)
[C] get_result(0xf0)
[R] => [1C 00 00 00]
[C] read_result(0xf0, size=28)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00]
[C] ipslr_set_mode(0x1)
[C] _ipslr_write_args(cmd_2 = 0x0, {0x1})
[C] command(fd=f0, 0, 0, 4)
[C] get_status(0xf0)
[R] => ERROR: 0x01
[C] ipslr_status()
[C] command(fd=f0, 0, 1, 0)
[C] get_result(0xf0)
[R] => [1C 00 00 00]
[C] read_result(0xf0, size=28)
[R] => [02 00 00 00 00 00 00 00 10 02 00 01 01 00 80 80
00 00 00 00 00 00 00 00 00 00 00 00]
[C] ipslr_identify()
[C] command(fd=f0, 0, 4, 0)
[C] get_result(0xf0)
[R] => [08 00 00 00]
[C] read_result(0xf0, size=8)
[R] => [22 32 01 00 4A 02 00 00]
id of the camera: 13222
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 456
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 10 02 00 01 01 00 80 80
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
0x0000 | 02 00 00 00 00 00 00 00 10 02 00 01 01 00 80 80
0x0010 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0020 | 00 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00
0x0030 | 00 01 00 00 02 00 00 00 01 00 00 00 2d 00 00 00
0x0040 | 0a 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00
0x0050 | 03 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00
0x0060 | 00 00 00 00 0c 00 00 00 64 00 00 00 64 00 00 00
0x0070 | 80 0c 00 00 00 00 00 00 07 00 00 00 07 00 00 00
0x0080 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090 | 00 00 00 00 04 00 00 00 05 00 00 00 05 00 00 00
0x00a0 | 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00b0 | 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00c0 | 03 00 00 00 06 00 00 00 00 40 00 00 00 00 00 00
0x00d0 | 00 00 00 00 05 00 00 00 00 00 00 00 03 00 00 00
0x00e0 | 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00f0 | 01 00 00 00 01 00 00 00 00 00 00 00 88 13 00 00
0x0100 | 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0110 | 02 00 00 00 01 00 00 00 2d 00 00 00 0a 00 00 00
0x0120 | 00 00 00 00 0a 00 00 00 00 00 00 00 0a 00 00 00
0x0130 | 01 00 00 00 70 17 00 00 64 00 00 00 00 00 00 00
0x0140 | 00 00 00 00 03 00 00 00 32 00 00 00 0a 00 00 00
0x0150 | 40 01 00 00 0a 00 00 00 00 00 00 00 00 00 00 00
0x0160 | 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00
0x0170 | 50 02 00 00 21 03 00 00 f9 02 00 00 00 00 00 00
0x0180 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0190 | 00 00 00 00 84 00 00 00 00 00 00 00 00 00 00 00
0x01a0 | fc 00 00 00 ac 0d 00 00 64 00 00 00 14 00 00 00
0x01b0 | d8 ff ff ff 00 00 00 00 02 00 00 00 0f 00 00 00
0x01c0 | 3f 00 00 00 00 00 00 00
init bufmask=0x0
[C] ipslr_cmd_00_09(0x2)
[C] _ipslr_write_args(cmd_2 = 0x0, {0x2})
[C] command(fd=f0, 0, 9, 4)
[C] get_status(0xf0)
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[R] => ERROR: 0x01
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 456
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
buf[008] last 10h 16 new 00h 0
buf[00B] last 01h 1 new 02h 2
buf[014] last 00h 0 new 03h 3
buf[064] last 0Ch 12 new 00h 0
---------------------------
[C] ipslr_cmd_10_0a(0x1)
[C] _ipslr_write_args(cmd_2 = 0x0, {0x1})
[C] command(fd=f0, 10, a, 4)
[C] get_status(0xf0)
[R] => ERROR: 0x01
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 456
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] pslr_camera_name()
pktriggercord-cli.exe: K-70 Connected...
[C] pslr_get_status()
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 456
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] pslr_get_status()
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 456
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] pslr_get_status()
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 456
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
[C] pslr_get_status_buffer()
[C] ipslr_status_full()
[C] command(fd=f0, 0, 8, 0)
[C] get_result(0xf0)
[R] => [C8 01 00 00]
read 456 bytes
expected_bufsize: 456
[C] read_result(0xf0, size=456)
[R] => [02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ... (424 bytes more)]
0x0000 | 02 00 00 00 00 00 00 00 00 02 00 02 01 00 80 80
0x0010 | 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
0x0020 | 00 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00
0x0030 | 00 01 00 00 02 00 00 00 01 00 00 00 2d 00 00 00
0x0040 | 0a 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00
0x0050 | 03 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00
0x0060 | 00 00 00 00 00 00 00 00 64 00 00 00 64 00 00 00
0x0070 | 80 0c 00 00 00 00 00 00 07 00 00 00 07 00 00 00
0x0080 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090 | 00 00 00 00 04 00 00 00 05 00 00 00 05 00 00 00
0x00a0 | 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00b0 | 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00c0 | 03 00 00 00 06 00 00 00 00 40 00 00 00 00 00 00
0x00d0 | 00 00 00 00 05 00 00 00 00 00 00 00 03 00 00 00
0x00e0 | 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00f0 | 01 00 00 00 01 00 00 00 00 00 00 00 88 13 00 00
0x0100 | 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0110 | 02 00 00 00 01 00 00 00 2d 00 00 00 0a 00 00 00
0x0120 | 00 00 00 00 0a 00 00 00 00 00 00 00 0a 00 00 00
0x0130 | 01 00 00 00 70 17 00 00 64 00 00 00 00 00 00 00
0x0140 | 00 00 00 00 03 00 00 00 32 00 00 00 0a 00 00 00
0x0150 | 40 01 00 00 0a 00 00 00 00 00 00 00 00 00 00 00
0x0160 | 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00
0x0170 | 50 02 00 00 21 03 00 00 f9 02 00 00 00 00 00 00
0x0180 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0190 | 00 00 00 00 84 00 00 00 00 00 00 00 00 00 00 00
0x01a0 | fc 00 00 00 ac 0d 00 00 64 00 00 00 14 00 00 00
0x01b0 | d8 ff ff ff 00 00 00 00 02 00 00 00 0f 00 00 00
0x01c0 | 3f 00 00 00 00 00 00 00
current iso : 100
current shutter speed : 2/1
camera max shutter speed : 1/6000
current aperture : 4.5
lens max aperture : 32.0
lens min aperture : 5.0
set shutter speed : 2/1
set aperture : 4.5
fixed iso : 100
auto iso : 100-3200
jpeg quality : 3
jpeg resolution : 24M
jpeg image tone : Natural
jpeg saturation : 4
jpeg contrast : 5
jpeg sharpness : 5
jpeg hue : 4
zoom : 35.00 mm
focus : 0
color space : sRGB
image format : JPEG
raw format : PEF
light meter flags : 0
ec : 0.00
custom ev steps : 1/3
custom sensitivity steps : 0
exposure mode : 0 (NONE)
user mode flag : 0
ae metering mode : Multi
af mode : AF.A
af point select : SelfTimer-12
selected af point : 16384
focused af point : 0
drive mode : Single
auto bracket mode : off
auto bracket picture count : 0
auto bracket ev : 0.30
shake reduction : off
white balance mode : Auto
white balance adjust : 0
flash mode : Auto
flash exposure compensation : 0.00
manual mode ev : 0.00
lens : smc PENTAX-DA 18-55mm F3.5-5.6 AL
battery : 5.92V 8.01V 0.00V 0.00VThe 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.
asalamon74
commented
7 years ago 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.
jmozmoz
commented
7 years ago 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.
jmozmoz
commented
7 years ago So I traced down my problem (without really knowing what I am doing): The check at https://github.com/asalamon74/pktriggercord/blob/0c3d8e20a70ee645b6e2744d3afd568674050bfc/pslr.c#L909 for bufmask results in a return from the function. The likely reason is, that the bufmask value is read from the wrong address within the status buffer (set at https://github.com/asalamon74/pktriggercord/blob/9e0be49212738029a9212da043e98354c0a3b430/pslr_model.c#L607).
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?
asalamon74
commented
7 years ago 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).
jmozmoz
commented
7 years ago 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.
asalamon74
commented
7 years ago 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 pslr_delete_buffer function.
asalamon74
commented
7 years ago @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.
jmozmoz
commented
7 years ago 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)?
jmozmoz
commented
7 years ago But I will further investigate the buffer issue...
asalamon74
commented
7 years ago @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. pktriggercord-0.84.03-win.zip
jmozmoz
commented
7 years ago I added a python wrapper to the internal functions of pktriggercord to make it easier to experiment: 18000b340cff663a48b47fd2df237edf6447149d 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)
jmozmoz
commented
7 years ago Ok, here is what I found: There is an address in the buffer (0xe8) which changes during taking bracketing shots: Before taking pictures, it contains 1, also after the first shot, after the second, it's 2.
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 pslr_shutter(camhandle);
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 pslr_get_status(camhandle, &status);. This results in (re)setting the above mentioned counter to 1.
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.
jmozmoz
commented
7 years ago 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?
asalamon74
commented
7 years ago @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...
asalamon74
commented
7 years ago @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.
asalamon74
commented
7 years ago @jmozmoz I've added a new status field auto_bracket_picture_counter to the program.
asalamon74
commented
7 years ago @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.
asalamon74
commented
7 years ago @jmozmoz Does you bufmask change work correctly? Can you save images?
jmozmoz
commented
7 years ago @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:
./pktriggercord-cli -o test0001 -F 3 --file_format=dng -q 4 -t 1/100 -i 100 -m M --dangerous -w --debug >log 2>&1In 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).
jmozmoz
commented
7 years ago 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.
asalamon74
commented
7 years ago I've started testing the empty SD card (Card is not formatted error message) problem (I have a new K-70 camera):
I had no problems using a 32GB FAT32 card. Problems started when I switched to a 64GB exFAT card.
When I put the card into my computer it shows that the dirty bit is set. Mounting the card in my computer and correctly unmount it solves the problem, I can put it back into my camera and it works fine again.
Even if I don't use pktriggercord but connect the camera and the computer using a USB cable and turn off the camera without correctly unmounting it will give me the exact same error message.
asalamon74
commented
7 years ago 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.
asalamon74
commented
7 years ago 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.
asalamon74
commented
7 years ago I have removed the --dangerous hack, it is no longer needed if you want to connect to K-70. If you don't turn off the camera without proper unmount it will work correctly. Even if the camera shows that the card is empty, connecting to the PC, correctly unmounting fixes the problem.
asalamon74
commented
7 years ago I've merged bulb_modern branch into master
legel
commented
6 years ago 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.
asalamon74
commented
6 years ago @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.
legel
commented
6 years ago 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.
asalamon74
commented
6 years ago 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.
Nats-ji
commented
6 years ago 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.
I can help with testing it on K3II
asalamon74
commented
6 years ago @Nats-ji That would be great. There is a specific issue for K-3II bulb problem, I've added the info there: Issue #25
asalamon74
commented
6 years ago 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.
asalamon74
commented
6 years ago 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.
legel
commented
6 years ago @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
legel
commented
6 years ago 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...
legel
commented
6 years ago 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:
./pktriggercord-cli -o test0001 -F 3 --file_format=jpg -q 4 -t 1/100 -i 100 -m M --dangerous -w --debug >log 2>&1
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.
asalamon74
commented
6 years ago @legel
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?