Peter Fales wrote:
> Thanks for all your help. I think we're getting closer. I'm using the
> Makefile rules supplied with unpaper:
>
> unpaper:
> cc unpaper.c -o unpaper -lm
>
> so I was already using no optimization. I was using gcc-3.2.2 which
> is the default compile
Peter Fales schrieb:
> Now that's wierd. I was using a privately built copy of unpaper, but I
> just unpacked the tarball and get the same results with the prebuilt binary!
I just reproduced the problem on one remote Intel machine I have access to.
Try to compile without any optimization (no -O
Jens Gulden wrote:
Hi,
>> Unpaper seems to have endianness issues;
>
> Are you using 1-bit-per-pixel input or output files (i.e. .pbm, not
> .pgm)? The only place where I would ad-hoc suspect an endianess issue
I think I used pgm both times, I'll retry to confirm that.
> is when the single bit
Hi Jens,
Jens Gulden wrote:
> Peter Fales schrieb:
>
>> Now that's wierd. I was using a privately built copy of unpaper, but I
>> just unpacked the tarball and get the same results with the prebuilt
>> binary!
>
>
> I just reproduced the problem on one remote Intel machine I have access to.
On Fri, Mar 11, 2005 at 11:25:42PM +0100, Bertrik Sikken wrote:
> Try compiling it with compiler option --pedantic
> That results in lots of warnings, of which some look very suspicious.
>
> I' m not sure how big the stack is by default, but unpaper appears
> to put quite a lot of local variable
Can you attach a sample-image?
Peter Fales schrieb:
> The images I'm working with are faxes, so they are typically 1680x2200
> pbm (1 bit per pixel) image files.
>
> I wasn't specifying --layout, but adding "--layout single" didn't seem to
> help. Since my pixels are all black or white, I don't
Hello,
Peter Fales wrote:
> I get white pages as output on my i686 machine unless I use
> --no-border-scan. I haven't analyzed why - and I'm not sure whether
> running unpaper with all default arguments is even expected to work.
You're right, the default parameters are NOT expected to always w
Julien BLACHE wrote:
> Unpaper seems to have endianness issues;
Are you using 1-bit-per-pixel input or output files (i.e. .pbm, not
.pgm)? The only place where I would ad-hoc suspect an endianess issue is
when the single bits are accessed during conversion from/to 1-bit images...
Is it exactly t
Thanks for all your help. I think we're getting closer. I'm using the
Makefile rules supplied with unpaper:
unpaper:
cc unpaper.c -o unpaper -lm
so I was already using no optimization. I was using gcc-3.2.2 which
is the default compiler on my system. I tried building w
I have a UMAX Astra 1220S scanner connected to a BusLogic SCSI card that
I've used with SANE for years, but recently (possibly after a software
upgrade) it has been giving me headache & trouble, and I have just about
lost my wits.
I am suddenly unable to scan images at higher resolutions. Without
Hello!
I got a different firmware (from a CD), and now it works. Thanks a lot!
--
Sebastian Reichelt
On Thu, 2005-03-10 at 23:56 +0100, Sebastian Reichelt wrote:
> Hello!
>
> I have a Tevion MD9458 scanner which I would like to get to work with
> Linux. Apparently it is supported by SANE, and sane-find-scanner detects
> it correctly. However, when I try to access it with xsane or scanimage,
> I g
The images I'm working with are faxes, so they are typically 1680x2200
pbm (1 bit per pixel) image files.
I wasn't specifying --layout, but adding "--layout single" didn't seem to
help. Since my pixels are all black or white, I don't think changing
the thresholds would be expcted to make much di
Hello!
> This happened to me before I learned that my kernel was loading
> hpusbscsi.
No, sorry. hpusbscsi is not even compiled, neither as a module nor into
the kernel. No modules are loaded except some parport stuff, probably
because of scanner detection.
Something I forgot to mention: I got
14 matches
Mail list logo
