The last four bytes of the IMAGE_SUPPORT_INFO struct seem to contain the maximum image size that the printer will support. On my Link Wide, it's 0x52800 = 337920 = 330 * 1024:
-> b'Ab\x00\x08\x00\x02\x00R'
<- b'aB\x00\x13\x00\x02\x00\x00\x04\xec\x03H\x02{\x00\x05(\x00b'
EventType.SUPPORT_FUNCTION_INFO 000004ec0348027b00052800
I can confirm that this is in fact the max supported image size by experimenting with PRINT_IMAGE_DOWNLOAD_START. If you give it a valid image size, it responds with the printer's desired chunk size, but if you give it a size that's too big, it seems to respond with 0x81:
337919
-> b"Ab\x00\x0f\x10\x00\x02\x00\x00\x00\x00\x05'\xff\x10"
<- b'aB\x00\x0c\x10\x00\x00\x00\x00\x03\x84\xb9'
EventType.PRINT_IMAGE_DOWNLOAD_START 0000000384
337920
-> b'Ab\x00\x0f\x10\x00\x02\x00\x00\x00\x00\x05(\x00\x0e'
<- b'aB\x00\x0c\x10\x00\x00\x00\x00\x03\x84\xb9'
EventType.PRINT_IMAGE_DOWNLOAD_START 0000000384
337921
-> b'Ab\x00\x0f\x10\x00\x02\x00\x00\x00\x00\x05(\x01\r'
<- b'aB\x00\x08\x10\x00\x81\xc3'
EventType.PRINT_IMAGE_DOWNLOAD_START 81
This is 3x higher than the currently hardcoded value of 105kb and can allow for significantly higher quality.
Also, I think there's a bug in pil_image_to_bytes: img_buffer is never cleared between calls to save_img_with_quality, so it never actually shrinks in size. If you call save_img_with_quality(80), then save_img_with_quality(50), you will get a buffer that has the same length as the quality-80 JPEG but contains the quality-50 JPEG followed by leftover trailing bytes from the quality-80 one. Because print_image then does len(imgData), it will get an invalid value, and printing might fail if the buffer was too long on any iteration of the binary search.
The last four bytes of the IMAGE_SUPPORT_INFO struct seem to contain the maximum image size that the printer will support. On my Link Wide, it's 0x52800 = 337920 = 330 * 1024:
I can confirm that this is in fact the max supported image size by experimenting with PRINT_IMAGE_DOWNLOAD_START. If you give it a valid image size, it responds with the printer's desired chunk size, but if you give it a size that's too big, it seems to respond with
0x81:This is 3x higher than the currently hardcoded value of 105kb and can allow for significantly higher quality.
Also, I think there's a bug in
pil_image_to_bytes:img_bufferis never cleared between calls tosave_img_with_quality, so it never actually shrinks in size. If you callsave_img_with_quality(80), thensave_img_with_quality(50), you will get a buffer that has the same length as the quality-80 JPEG but contains the quality-50 JPEG followed by leftover trailing bytes from the quality-80 one. Becauseprint_imagethen doeslen(imgData), it will get an invalid value, and printing might fail if the buffer was too long on any iteration of the binary search.