[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:       Sune Vuorela <nospam () vuorela ! dk>
Date:       2012-03-08 8:52:44
Message-ID: slrnjlgsqs.p7v.nospam () sshway ! ssh ! pusling ! com
[Download RAW message or body]

On 2012-03-07, K=E5re S=E4rs <kare.sars@iki.fi> wrote:
> How do we go forward from here? =


Put it on the wikipage, wait for KDE to be a gsoc approved organization,
wait for official project submissions, get the student to submit the
project. hope that KDE as a organization selects your project.

> Who is willing to mentor for an ORC library + plugins + ...? =


My best guess for a great mentor for such a project would be someone
with a iki.fi address with a firstname and a lastname of 4 letters, both
containing some 'nordic' letters. :)

> What does a mentor do and how much time does it take?

a mentor answers questions from the student. A mentor ensures the
student is on right track. A mentor fails or passes the project.
A mentor does a lot of code review
A mentor also ensures that the project plan is good and sane.

Mentoring, depending on student and the task, is probably 1-2 hours a
day or something like that.

Fram my experience with santa, he is probably going to be one of the
students who is going to be pretty light to mentor.

/Sune



>
> /K=E5re
>
> On Wednesday 07 March 2012 16:16:59 todd rme wrote:
>> 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> wr=
ote:
>> >> >> > 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, the=
re
>> >> >> is little advantage over a kio slave.  I would think that a kio sl=
ave
>> >> >> would be more natural, since users would not need to know terminol=
ogy
>> >> >> 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 useca=
ses,
>> > 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 ph=
otos
>> > 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.
>> =

>> 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?)
>> >  - 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...
>> =

>> 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 =
sure
>> > 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 unsubsc=
ribe
>> >> <<
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscri=
be <<
>


>> 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]