Issue 7 in jfreesane: Implementation of the SANE_NET_CANCEL RPC request (RPC Code 8 of the SANE protocol)

85 views
Skip to first unread message

jfre...@googlecode.com

unread,
Jul 23, 2013, 5:04:24 AM7/23/13
to jfreesan...@googlegroups.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 7 by rr.m...@voila.fr: Implementation of the SANE_NET_CANCEL RPC
request (RPC Code 8 of the SANE protocol)
http://code.google.com/p/jfreesane/issues/detail?id=7

With my Plusteck OptiSlim M12 scanner, I need to send a cancel request to
eject the page after acquiring image.
I pushed the implementation of this request in the clone
rrmath-jfreesanewithcancel.
Only SaneDevice.java and SaneSession.java have been modified.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

jfre...@googlecode.com

unread,
Jul 23, 2013, 10:23:09 AM7/23/13
to jfreesan...@googlegroups.com

Comment #1 on issue 7 by s...@jdns.org: Implementation of the
SANE_NET_CANCEL RPC request (RPC Code 8 of the SANE protocol)
http://code.google.com/p/jfreesane/issues/detail?id=7

Excellent, thanks for the patch! Quite an omission because upon reading the
sane API spec (http://www.sane-project.org/html/doc013.html):

"Once all desired frames have been acquired, function sane_cancel() must be
called. This operation can also be called at any other time to cancel a
pending operation. Note that sane_cancel() must be called even if the last
read operation returned SANE_STATUS_EOF."

Will merge right away, thanks again.

jfre...@googlecode.com

unread,
Jul 24, 2013, 3:53:36 AM7/24/13
to jfreesan...@googlegroups.com

Comment #2 on issue 7 by rr.m...@voila.fr: Implementation of the
SANE_NET_CANCEL RPC request (RPC Code 8 of the SANE protocol)
http://code.google.com/p/jfreesane/issues/detail?id=7

Thank you very much.

Roland Quast

unread,
Jul 29, 2013, 7:53:40 PM7/29/13
to jfreesan...@googlegroups.com, codesite...@google.com, jfre...@googlecode.com
I had a look at the diff for this patch you did. Does that mean that we have to call cancel after acquireImage? It sounds like the spec says it should always be called and if that is the case, should it be implicitly called in aquireImage?

James Ring

unread,
Jul 29, 2013, 7:56:13 PM7/29/13
to Roland Quast, jfreesane-discuss, codesite...@google.com, jfre...@googlecode.com
It shouldn't be up to the user to call cancel, it's a bug that we
don't do this yet. I want to hide this detail from the user, but we
shouldn't call cancel() if the user wants to acquire more images. This
means we need to change the JFreeSane API to allow our users to say
"ok we're done scanning for now".
> You received this message because you are subscribed to the Google Groups
> "jfreesane-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jfreesane-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Roland Quast

unread,
Jul 29, 2013, 7:56:28 PM7/29/13
to jfreesan...@googlegroups.com, codesite...@google.com, jfre...@googlecode.com
Also, the diff you had closed the connection on the last image - should it be canceled first then close?

James Ring

unread,
Jul 29, 2013, 8:04:16 PM7/29/13
to Roland Quast, jfreesane-discuss, codesite...@google.com, jfre...@googlecode.com
That connection represents a connection to the sane data port
negotiated upon sane_start. We are free to close it after the last
frame is detected (see
http://www.sane-project.org/html/doc017.html#s5.2.8).

Roland Quast

unread,
Jul 29, 2013, 8:13:56 PM7/29/13
to jfreesan...@googlegroups.com, Roland Quast, codesite...@google.com, jfre...@googlecode.com
Yeah I figured that after I posted the last message. So are you saying that acquireImage needs to be run as a thread with a callback to get images or something and if the thread is interrupted, you call cancel? I'm not really clear on why you wouldn't call cancel after it is done? If you wanted to acquire more images, wouldn't you open up the device again or is unnecessary overhead? Please excuse my ignorance. ;-)

James Ring

unread,
Jul 29, 2013, 8:17:31 PM7/29/13
to Roland Quast, jfreesane-discuss, codesite...@google.com, jfre...@googlecode.com
If you open up the device again, you have to set all the options
again. This can be time consuming. Also I imagine some backends might
have a problem if you're in the middle of doing some scanning and you
reset the options (e.g. you're doing a scan from the ADF).

Roland Quast

unread,
Jul 29, 2013, 8:18:34 PM7/29/13
to jfreesan...@googlegroups.com, Roland Quast, codesite...@google.com, jfre...@googlecode.com
More on that last point... what about 2 different method... a non-threaded acquireImages (which you could deprecate) and a threaded one?

Roland Quast

unread,
Jul 29, 2013, 8:24:24 PM7/29/13
to jfreesan...@googlegroups.com, Roland Quast, codesite...@google.com, jfre...@googlecode.com
You could also count the page number that you're up (to display to the user) to if you have a callback and it's threaded. One thing if it is threaded, though... if you were to throw an exception (say a paper jam), you'd need to make sure the exceptions get handled by the parent thread properly.

James Ring

unread,
Jul 29, 2013, 8:25:48 PM7/29/13
to Roland Quast, jfreesane-discuss, codesite...@google.com, jfre...@googlecode.com
I think we should have a threaded version. It would be nice to get
progress information out of the scanner and allow the user to cancel
an in-progress scan. This could be done without much effort I think.

This is kind of orthogonal to the issue of when to send cancel()
though. We need to send it when the user doesn't want any more images,
not only when they want to abandon the current image that is being
scanned. This requires a change to the API. I would propose:

* remove acquireImage from SaneDevice
* add a beginScanning method to SaneDevice that returns a ScanSession,
or something
* add a ScanSession.acquireImage to get the next image synchronously
* also add acquireImageLater that returns some ScanFuture that extends
Future<BufferedImage> for asynchronous fetching
* add ScanSession.finish() to indicate to jfreesane that the user is done
* add methods to ScanSession like addListener(ScanListener), that can
listen for scanning events (e.g. a line was scanned, a page was
scanned, scanning finished, an error occurred, etc)

Roland Quast

unread,
Jul 29, 2013, 8:31:45 PM7/29/13
to jfreesan...@googlegroups.com, Roland Quast, codesite...@google.com, jfre...@googlecode.com
Yes, a listener would be perfect.

Roland Quast

unread,
Jul 29, 2013, 8:55:41 PM7/29/13
to jfreesan...@googlegroups.com, Roland Quast, codesite...@google.com, jfre...@googlecode.com
Can I also suggest that you use tiles?

There are two reasons why tiles would be good:

1. Tiles means you can persist each tile rather than storing them in RAM. This is particularly important for two reasons - 1. if you don't allocate enough heap space for your app and you scan a 600DPI colour image into a single bufferedimage - 2. you don't want your app to consume loads of RAM or you don't have a machine with much ram (embedded devices for instance).
2. You can display tiles as things scan in a preview window to the user.

PlanarImage in JAI is a good place to start with tiles, though, one issue with JAI is the licensing.

Roland Quast

unread,
Jul 29, 2013, 9:19:58 PM7/29/13
to jfreesan...@googlegroups.com, Roland Quast, codesite...@google.com, jfre...@googlecode.com
And if you don't want to use JAI or any other library to do a TiledImage - maybe make that bit of code extensible so it can be done?

Roland Quast

unread,
Jul 29, 2013, 9:38:18 PM7/29/13
to jfreesan...@googlegroups.com, codesite...@google.com, jfre...@googlecode.com
Final post about this topic before I stop going on about it...


The last post there says a 600DPI colour bufferedimage uses 100mb. If you were to use a listener, and the code that the listener calls couldn't keep up with the speed of the scanner, you'd very quickly end up with an out of memory issue if you don't use writable tiles or save the entire image to disk rather than storing it in a bufferedimage.

Also, one other thing I just remembered.... My document scanner will scan everything to the sane server's memory first before it sends it on if I have adf-auto-scan turned on. This is really really good because it doesn't have to wait for SANE to send the image first before scanning the next page. I haven't seen any other SANE clients that support this - so it's a real bonus that it works well with jfreesane. It's in this situation where you'd run out of RAM pretty quickly, not the situation where sane waits on the scanning for jfreesane to request the next image.

Roland Quast

unread,
Jul 29, 2013, 10:02:59 PM7/29/13
to jfreesan...@googlegroups.com, codesite...@google.com, jfre...@googlecode.com
Nevermind that last post... I was thinking that the listener would be called on a separate thread as well (so that it could request the next image from saned).. I guess that ability would also be good too so it could speed up processing for jfreesane clients (only if you have writable tiles or files though).

jfre...@googlecode.com

unread,
Aug 21, 2013, 1:38:02 PM8/21/13
to jfreesan...@googlegroups.com
Updates:
Status: Fixed

Comment #3 on issue 7 by s...@google.com: Implementation of the
SANE_NET_CANCEL RPC request (RPC Code 8 of the SANE protocol)
http://code.google.com/p/jfreesane/issues/detail?id=7

(No comment was entered for this change.)
Reply all
Reply to author
Forward
0 new messages