Re: TODO list

From: kwlee (kwlee88@tpts5.seed.net.tw)
Date: Thu Nov 09 2000 - 02:32:16 PST

  • Next message: kwlee: "Re: New backends for SANE 1.0.4"

     Hi,
    > > well, i need a API which frontend can query backend the warm up
    remaining
    > > time.
    >
    > I think that is possible at the moment. Just define an option that
    > includes this time. The problem is that this option won't be polled
    > every x seconds by the frontend.
    well, before call start_scan() we can pop up a dialogbox(in xsane), then
    call
    this API(maybe per second) to check/display the warmup remaining time.

    >
    > But why should the frontend know about this scanner internal warm-up
    > time at all? scan immediately, just wait for the scanner to be ready? In
    > this case the frontend will block until start_scan is finished. It
    > would be nicer if the frontend printed out a message like "wait for
    > warmup" but I don't think it's really necessary.
    :( this option of course no need by high-end scanner, but seems "must"
    for low cost scanner to get consistent quality.
    Normally, the lamp reach stable stage will need 1.5 minutes(in my memory)
    but reach 95% stable will only need about 30 seconds, so most of time
    we use 30 secs as warm-up count down, but you know no matter 1.5 minutes
    or 30 secs waiting, users can not tolerate without any prompting message,
    they maybe thinking your scanner hang-up again, counting down will make
    them believe their scanner is still alive.

    >
    > > humm this is necessary for no-cpu(or firmware) CCD scanner(not for CIS
    one)
    > > drivers have to check the lamp is warming up enough.
    > > this behavior is only necessary for user the first time connect the
    power,
    > > if the lamp always turn-on, there is no need to check warm up remain
    time...
    >
    > But shouldn't this be done in the backend completely? Why should the
    > frontend know about the warm-up time? Is it so long that the user
    > kills the frontend because he thinks it's frozen?

    YEP! as said above.
    >
    > > OK! the jpeg data coming from scanner, some manufactures use this mode
    > > to speed-up scanning, for example A4 600 dpi color can be achieved
    > > around 1.5 minutes, so scanning with jpeg mode, and decompress by
    driver.
    > > In SANE, the decompressing can be done by backend or frontend! but
    > > in my opnion, there could be more & more H/W jpeg supported scanners,
    > > so better there has API can support this kind of decompression
    >
    > So ypou want to have an sanei_ function to decompress jpeg? The SANE
    > API itsself deals mainly with transfering information between the
    > frontend and the backend. So if one of the standard frame types is
    > used the decompression will be done in the backend. If a jpeg frame
    > type is used (when it will be available) it's done in the frontend (at
    > least if the file isn't saved directly to the disk).
    for example, scanner scaned in jpeg mode, but user hope to save as
    pnm or tif format(this could save many scan time), in such case what
     will you thinking ?
    >
    >
    > PROJECTS is a summary of backends and other parts of SANE that are not
    > included until now. These may be programs that are already finished,
    > in alpha state or just an idea/concept. If there is a backend that
    > already works we can add a description file (.desc) to SANE. This will
    > make sure that the backend is listed on the SANE website. So in your
    > case we should make both.
    done!

    Many thanks!
    kw

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
    



    This archive was generated by hypermail 2b29 : Thu Nov 09 2000 - 02:25:11 PST