alexpevzner / sane-airscan

Scanner Access Now Easy - universal driver for eSCL (Apple AirScan) and WSD
Other
278 stars 39 forks source link

Support reporting live progress of scanning operation? #279

Open twelho opened 1 year ago

twelho commented 1 year ago

It seems that sane-airscan is not able to show the live progress of a scan as it progresses. On both an ET-2650 and an ET-2820, running

$ scanimage -d "airscan:e0:<hostname>" -vvv -p -o /tmp/scan.png
scanimage: scanning image of size 2550x3510 pixels at 24 bits/pixel
scanimage: acquiring RGB frame

causes the process to just wait here until the entire scan has finished, after which a progress indicator briefly appears and flies straight from 0% to 100%. This is also evident in graphical scanning applications such as simple-scan, where the image only appears after the scan has finished (when the progress breezes from 0% to 100%). Finally, the following is printed:

scanimage: min/max graylevel value = 211/255
scanimage: read 26851500 bytes in total

Running with SANE_DEBUG_DLL=255, I can see that the progress blocks at the first

[16:11:20.264073] [dll] sane_read(handle=0x56039bd3a5e0,data=0x56039bd5dfc0,maxlen=32768,lenp=0x7ffdf4d9005c)

until the scan is finished, after which all of the rest of the sane_read calls are printed in quick succession. However, when monitoring the network activity, I can see the scanner streaming data during the entire scan. What prevents live progress reporting in airscan, since it works with, e.g., the epson2 backend?

alexpevzner commented 1 year ago

Hi @twelho,

I was thinking about that, but it is not so simple to implement. It implies on-a-fly incremental image decoding. Not all of the supported image formats even provide some guarantees that it can be done in principle, for any actual image (for example, TIFF image is not guaranteed to be incrementally decodable, though real TIFFs as they come from scanners most likely do). Plus. WSD adds yet another level of complexity: image comes wrapped into MIME multipart, which also needs to be decoded on-a-fly, before all HTTP response data is received.

I won't close this issue and hope eventually I'll implement this feature. But who knows ho much time will it take...