[sane-devel] Degrading images: Plustek OpticPro UT16

[rhn]

On Sat, 24 Sep 2016 14:55:18 +0900
Olaf Meeuwissen <paddy-hack at member.fsf.org> wrote:

> Hi rhn,
> 
> rhn writes:
> 
> > On Fri, 23 Sep 2016 10:40:35 +0200 (CEST)
> > Johannes Meixner <jsmeix at suse.de> wrote:
> >  
> >> Hello,
> >> 
> >> On Sep 22 18:33 rhn wrote (excerpt):  
> >> > the scanner I am using has a peculiar problem, where scanning
> >> > consecutive images causes the image quality to degrade:
> >> > the left part becomes yellow in vertical streaks that increase
> >> > in numbers; the right part becomes red. To get a completely
> >> > yellow-red image, about 10 scans are necessary, regardless
> >> > of options.
> >> > The backend for this scanner is plustek.    
> >> 
> >> at openSUSE we have an issue report with similar symptoms
> >> but different backend (HP Scanjet 2400, genesys backend):
> >> 
> >> https://bugzilla.opensuse.org/show_bug.cgi?id=905034
> >> 
> >> I was unable to reproduce it or debug the root cause
> >> so that all I did was basically blind guess, e.g. see:
> >> 
> >> https://bugzilla.opensuse.org/show_bug.cgi?id=905034#c18  
> 
> > Thanks for pointing out that bug report.  
> 
> Read the bug report.  Scan artifacts getting progressively worse during
> a scan.
> 
> > I think that my issue might be different. I forgot to mention, but
> > starting a new scan (second scanimage command) yields the same
> > results, i.e. first 2 pages are fine.  
> 
> So starting a new scan process will give you a good initial image or two
> but then things go downhill.
> 
> Just a thought but could this be caused by forgetting to (re)initialize
> reused dynamically allocated memory at the right times?  Like at the
> start of every *image* (in sane_start()) rather than with every call of
> sane_open() (or even worse, sane_init()).
> 
> In your case, the backend implementation may not have expected to be
> used for consecutive image acquisition to begin with (bad!).  But it can
> also be due to changes in the implementation defined behaviour of memory
> functions or dependent on what the kernel does with released resources.
> 
> > I managed to get the git build to run locally, and I'm testing it, so
> > my initial question is answered.
> >
> > I suspect my hardware is shot and needs extra resets. Is there any
> > other user of UT16 that can confirm?  
> 
> Hope this helps,


I looked closer and I still think the bugs are different.

The reported bug's problem increases during a scan, and, if I understand right, it resets at each new page. In addition, the errors do not repeat in the same places in consecutive lines.
The Plustek problem increases between "pages", and resets at a new process boundary. The errors appear in the same columns on consecutive "pages".

Another property of Plustek bug is that the bug always seems to transition from yellow to red square in the middle of the scan, regardless of position or resolution. It is also consistent across machines and builds.

While there is a chance they are both memory corruption, I'd wager they are both related to (different) arithmetic issues in image processing.
In the reported bug, the original image data are not overwritten, but altered, and that colors seem to be not far from original values at a glance.
In Plustek bug, it is unlikely that memory corruption will change its nature always at the same point, based on image size.

I'm going to try to bisect an offending commit if at all possible.

Cheers,
rhn