[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: Kåre_Särs <kare.sars () iki ! fi>
Date: 2012-03-07 10:34:49
Message-ID: 30254957.h8pcWu3okM () sars-laptop32
[Download RAW message or body]
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. In the latter case, there
> >> is little advantage over a kio slave. I would think that a kio slave
> >> 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 need
> > 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). In 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. In
> 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 t=
he =
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 images.
2) You have options (folders?)
- scan mode: grayscale, color
- resolution 50 100 150 300 600 1200 2400 4800 ...
- source: flatbed, automatic document feeder, transparency unit, ...
- how would you adjust gamma if available
- contrast/light...
- ...
3) Multipage scanning from ADF can not have a preview...
For simple point and shoot it might work some of the time but I'm not sure =
the =
amount of bug reports for heuristics failures would be fun to go through ;)
I think a Qt ORC library would be more than welcome also for the kio slave =
and =
that could be the main target for the GSoC.
K=E5re
>> 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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic