[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: GSoC idea: improving scanning and OCR in KDE (skanlite/kooka)
From:       todd rme <toddrme2178 () gmail ! com>
Date:       2012-03-07 15:16:59
Message-ID: CADb7s=u7r9idbVP6hvmwKsJymASB+WccX2WUhrWBBgy-Kjjqcg () mail ! gmail ! com
[Download RAW message or body]

2012/3/7 K=E5re S=E4rs <kare.sars@iki.fi>:
> On Wednesday 07 March 2012 10:59:50 todd rme wrote:
>> On Wed, Mar 7, 2012 at 10:46 AM, Andreas Pakulat <apaku@gmx.de> wrote:
>> > On 07.03.12 10:23:32, todd rme wrote:
>> >> On Tue, Mar 6, 2012 at 8:03 PM, Klaas Freitag <freitag@kde.org> wrote:
>> >> > On 06.03.2012 18:02, todd rme wrote:
>> > [...]
>> >
>> >> > These kind of things. Not sure if a kio is cool for any of these.
>> >>
>> >> A gui able to do all the things you listed would necessarily be
>> >> extremely complicated and likely difficult to use, unless most of the
>> >> tasks were automated push-button affairs. =A0In the latter case, there
>> >> is little advantage over a kio slave. =A0I would think that a kio sla=
ve
>> >> would be more natural, since users would not need to know terminology
>> >> or the menu structure.
>> >
>> > Maybe I didn't use enough of the more fancy kio-slaves, but I have a
>> > hard time imagining how I'd be able to use this with say konqueror. I'd
>> > go to
>> >
>> > kscan://<scannername>/
>> >
>> > And then see whats been scanned, but how do I initiate a scan? Do I ne=
ed
>> > to go to some special url? If so, how do I trigger the OCR creation
>> > after scanning?
>>
>> To activate a scan of an image, you either drag the image file in the
>> kio slave to another folder, or you open it in a program (either by
>> clicking or using the right-click menu). =A0In the case of dragging it
>> to a folder, it will be automatically scanned and saved in the
>> destination folder without the user needing to do anything else. =A0In
>> the case where you open it in a program, it will probably be scanned
>> to a temporary folder or stored in memory and then opened in the
>> program, once again without the user doing anything else.
>>
>> In the case of OCR, it would be the same, except a temporary image
>> file woulds be scanned, OCRed, and deleted (or again stored in
>> memory).
>>
>> This, at least, is how the CD kio slave does it.
>>
>
> If somebody is interested in making such a kio slave, for simple usecases=
, I
> would say go ahead and scratch your itch :) I do have a some doubts about=
 the
> usability tho.
>
> 1) You would have to "refresh" the view to get a new preview of new photos
> placed on the scanner and the automatic photo finder is bound to fail
> sometimes and you would be unable to select the correct part of the image=
s.

Yes, refreshing would be needed, both for this and for a standalone app.

The issue with incorrectly detected borders would also affect a
standalone app.  Of course this is intended for simple jobs, anything
complicated would need a more advanced app.  But for most cases simple
is enough.

> 2) You have options (folders?)
> =A0- scan mode: grayscale, color
> =A0- resolution 50 100 150 300 600 1200 2400 4800 ...
> =A0- source: flatbed, automatic document feeder, transparency unit, ...
> =A0- how would you adjust gamma if available
> =A0- contrast/light...

The only folders would probably be resolution, and one extra folder
for the ADF if available.  The ADF would primarily be useful for PDFs,
TIFFs, and OCR, so in that folder could be individual files for OCR,
PDFs at various resolutions, and TIFFs at various resolutions.

Color vs. grayscale could have two images for the whole scan, so only
one more file per resolution.  OCR would handle that automatically,
and scanned photos are unlikely to be in grayscale.

Transparency units usually replace the main scan bed, so the could be
detected as individual pictures and scanned that way.

Gamma, contrast, lightness, etc would require a standalone app.

> 3) Multipage scanning from ADF can not have a preview...

No, but this is true in a standalone app as well.

> For simple point and shoot it might work some of the time but I'm not sur=
e the
> amount of bug reports for heuristics failures would be fun to go through =
;)

The same bug reports would be needed for a standalone app, since it
would be using the same defaults.

-Todd

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]