maqifrnswa
commented
4 years ago Awesome, you got through a whole picture. Right now, based on the spec, every packet has to be the exact same size. This way the decoder knows which pixels correspond to which packet id number. The problem is that the total number of pixels isn't wholely divisible by the number of packets per image. So those remainder pixels don't get sent. The units are "Y" (luma) pixels received out of the total pixels in the image. The fix can be to do some modulo arithmetic and just fill out the packet by resending the first pixels. (The code gracefully accepts repeated pixels). I can just add a special case in the spec for the last packet, or describe the packet id to pixel number conversion using some modulo arithmetic. It hasn't been implemented yet since it has negligible affect on image quality, but it is confusing to users that expect 100% if all packets are received. Instead, we can use the metric of "packets received" instead of "pixels received" - that will reach 100% with the current code
This may be related to #4
I am running the latest version (git head) on Linux. The receiver never reaches 100% complete. I always end up with 99.8% complete for my test image. The image is 192x192 - 36864px and I receive 36806. The last packet is short. It is both sent and received. I can manually send it using CuteCom. It appears to be received. I see the following logged by the receiver:
I see the same value logged for this last packet both when sent from PCSI and when sent manually. So it appears to be receiving the data.
If I restart the PCSI GUI, send the last packet first manually via CuteCom, it is received and processed, showing 58 received. However, even after all of the packets have been sent/received, it still shows 99.8% complete and appears to be missing 58. (58 what? px? bytes? it's not clear what unit this number represents.)