70015237d17bc17c97dd7937993e2c02f16a830a motor positions are now stored in a singleton object and the first 4 bytes of each image hold the current step position as int32 in single endian order
86b673a35e920f4e758c9674b00ea984f561d188 Previews can now be stored.
When storing pictures, the highest resolution is taken.
The pictures are then stored along with their step value in a new folder generated via guid
5d629b6884225627cb95426608b3ae3bfc30398b After moving the motor, the caller has to wait, that a picture arrives, which has the step count of the target to reach.
Else moves are sent with wrong current positions.
Furthermore this guarantees that atleast one target photo is taken
e7007038ea6f079440a4748256ed1b30c0a50f25 The rpicam does automatically crop, if a lower resolution than full hd is taken. This is bad for showing a preview. But the mode can be set via command line, which eliminates the cropping issue. Reference link: https://forums.raspberrypi.com/viewtopic.php?t=347335
5603686460a67cde41f0a0b42c3a0e1ac1976476 enable the watchdog timer to run. When the os is not responsive for 10 seconds, then the device gets rebooted. A reboot should take 2 minutes in the worst case. Currently it takes under 30 seconds on raspberry pi zero 2w
6078ccb43f2ff3802a760f0eeda00c7c35d9b7f5 Added a new site to replay pictures. Currently folders can be selected and the images only viewed once. But I need a side to side comparison between different pictures of the same or other folders.
Furthermore I adjusted the selection of devices. Selections and health information is now permanently displayed on the top row
8f3913a16d47498a4c3328e2873bafd02688895d When not a webapi is called, then the index page should be returned for enabling the frontend to do the routing
d53988415fe514595478d3578937b8659640fb41 added a replay option for taken image series
bb5a96bee77583265b1e023f982b021ea2e26248 The device stores now the read image data to disk and then serves the disk images one after another to the gateway server.
No frames are dropped this way and a flaky connection can still send the image data.
The current date of the images is stored inside the byte array as ticks. This means the first 4 bytes are the step position and the second 8 bytes the ticks when the image was read. With the 12th byte, the picture begins
ed94dc64dbecbeb5d456a2bb08fec7952193a48a added fps limiting to the image taking.
Furthermore on streams to store the images, images are sent later to the client, because as much performance as possible should be available to take and store as many images as possible
765bb32f8f4c7ea64d39a3aaf2545fd40d760800 seems to be much more performant doing the image stream this way. I just execute the program directly without piping any data around, as this seems to be a major bottleneck.
Problematic is retrieving the correct position, when a file is read.
5a0c5394b9e521b261582d30a85dac0f2d3373d6 motor positions are now stored in a history according to the time in milliseconds.
Out of sync streaming should now skip files to serve the latest one
d79b7ddc5c66197a76713854c46ebe590b163e3f reading of files with skipping has now a test, that it does not leave any images behind.
7a164dfb337b7f314377e4a1bc327b8da3771966 Even when showing no preview of the pictures, the client should get the data where the pi currently is.
Else coordination at which points the raspberry pi should stay for how long is not that easy