Scanner output always JPEG compressed

[Bruce Cowan]

Binary package hint: hplip

The hpaio backend compresses the scanned image with JPEG before it is received by xsane. This makes it impossible to scan anything losslessly. Editing ~/.sane/xsane/($scanner).drc to say

"compression"
"none"

Fixes this temporarily.

[Aaron Albright (albrigha-deactivatedaccount)]

This is correct, the default for xsane and most other applications are to have jpeg compression on to increase the speed of the scanning. You can disable the jpeg compression depending on the application you are using, and it should remain off until it's changed.

If I'm understanding what you are seeking correctly, you assumed that jpeg compression would be off and want that to be the default instead of on. If so the setting is set by the application you are using, although default on is preferred because of the increase speed in scanning and because for most users this setting is sufficient. It's a balance between speed and quality.

Hope this helps.

Aaron

[Aaron Albright (albrigha-deactivatedaccount)]

Setting to invalid because it's not likely this default will be changed.

A

[Andrey Paramonov (cmr-pent)]

Hi!

I'm the original bug submitter and I'm really disappointed that you have set status to invalid. I argue that the new default value for the compression option is *not* a good balance between speed and quality. For me, the new default behavior is a clear *regression* compared to the previous versions.

What you say sounds kind of like "90% of users' content is so poor that they will not even notice quality reduction anyway". Please note however, that in some areas such an evident image *corruption* is not acceptable, take for example OCR. I argue that OCR is a very common application for scanners, so most users probably would *not* benefit from image quality loss.

Having said all that, it *could* be a sensible default value if a user could easily switch the lossy compression off. As of now, there seems to be no system-wide setting, at least documented, that could switch the image corruption once and for all. It's even not obvious how to turn the image corruption off on program-by-program basis (please see man xsane and xsane html documentation -- there is no mention of "compression"). It took me considerable amount of time just to understand that this is not a bug but a [mis]feature. I guess many users just started to use higher resolution settings to compensate for quality reduction.

Please consider reopening the bug!

Andrey Paramonov

[Aaron Albright (albrigha-deactivatedaccount)]

Hey Andrey,

I spoke with the dev team and our thinking is this isn't a defect because it can be changed in the xsane settings and once changed it will stay with the new setting. The default is set because in a majority of cases default works good for most users.

As for system wide we primarily only support scanning with xsane and each user would need to change the setting.

Maybe we're not clear on the use case you are wanting to improve?

Thanks!

A

[Andrey Paramonov (cmr-pent)]

Hi Aaron!

You say that xsane is your primary frontend. But it doesn't seem to be documented anywhere in xsane manual how to disable the image corruption. A user should not have to play Sherlock Holmes in order to find a way to turn the image corruption off. As of now, the whole feature effectively resembles infamous proprietary Digital Restrictions Management systems. Please, provide a straightforward way to disable image corruption and document it!

Andrey Paramonov

[dwelch91 (dwelch91)]

Not commenting on the merits of this defect report, but I will point out that this has been the default in HPLIP since our first release, and was the default in HPOJ, the previous project for HP print/scan support (in other words, this default has been in place for approximately 9 years, it was not changed recently, AFAIK).

[Bruce Cowan (bruce89-deactivatedaccount)]

I'm unsubscribing from all my bug reports here once I receive any bugmail, but I'd like to point out that the last comment was rather rude.

[dwelch91 (dwelch91)]

Wow. OK...

I was merely addressing this comment:

"I argue that the new default value for the compression option is *not* a
good balance between speed and quality.
For me, the new default behavior is a clear *regression* compared to the
previous versions."

made by Andrey earlier in this thread. This is not a regression, since
nothing has changed.

On Wed, May 13, 2009 at 3:45 PM, Bruce Cowan <email address hidden>wrote:

> I'm unsubscribing from all my bug reports here once I receive any
> bugmail, but I'd like to point out that the last comment was rather
> rude.
>
> --
> Scanner output always JPEG compressed
> https://bugs.launchpad.net/bugs/192176
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Andrey Paramonov (cmr-pent)]

2009/5/13 dwelch91 <email address hidden>:
> Not commenting on the merits of this defect report, but I will point out
> that this has been the default in HPLIP since our first release, and was
> the default in HPOJ, the previous project for HP print/scan support (in
> other words, this default has been in place for approximately 9 years,
> it was not changed recently, AFAIK).
>

Hello!

As of now, I cannot really confirm or disprove your statement, because
I do not have older packages any more. Anyway, is it possible to
implement global config option to turn the undesired behavior off?

Thanks for your effort,
Andrey

[David Suffield (david-suffield)]

scanimage -h

Usage: scanimage [OPTION]...

Start image acquisition on a scanner device and write PNM image data to
standard output.

Parameters are separated by a blank from single-character options (e.g.
-d epson) and by a "=" from multi-character options (e.g. --device-name=epson).
-d, --device-name=DEVICE use a given scanner device (e.g. hp:/dev/scanner)
    --format=pnm|tiff file format of output file
-i, --icc-profile=PROFILE include this ICC profile into TIFF file
-L, --list-devices show available scanner devices
-f, --formatted-device-list=FORMAT similar to -L, but the FORMAT of the output
                           can be specified: %d (device name), %v (vendor),
                           %m (model), %t (type), and %i (index number)
-b, --batch[=FORMAT] working in batch mode, FORMAT is `out%d.pnm' or
                           `out%d.tif' by default depending on --format
    --batch-start=# page number to start naming files with
    --batch-count=# how many pages to scan in batch mode
    --batch-increment=# increase number in filename by an amount of #
    --batch-double increment page number by two for 2sided originals
                           being scanned in a single sided scanner
    --batch-prompt ask for pressing a key before scanning a page
    --accept-md5-only only accept authorization requests using md5
-p, --progress print progress messages
-n, --dont-scan only set options, don't actually scan
-T, --test test backend thoroughly
-h, --help display this help message and exit
-v, --verbose give even more status messages
-B, --buffer-size change default input buffersize
-V, --version print version information

Options specific to device `hpaio:/usb/PSC_750?serial=MY17KC22C0WB':
  Scan mode:
    --mode Lineart|Gray|Color [Color]
        Selects the scan mode (e.g., lineart, monochrome, or color).
    --resolution 75..600dpi [75]
        Sets the resolution of the scanned image.
  Advanced:
    --contrast 0..100 [inactive]
        Controls the contrast of the acquired image.
    --compression None|JPEG [JPEG]
        Selects the scanner compression method for faster scans, possibly at
        the expense of image quality.
    --jpeg-quality 0..100 [10]
        Sets the scanner JPEG compression factor. Larger numbers mean better
        compression, and smaller numbers mean better image quality.
    --batch-scan[=(yes|no)] [no]
        Enables continuous scanning with automatic document feeder (ADF).
    --source Flatbed [Flatbed]
        Selects the scan source (such as a document-feeder).
  Geometry:
    --length-measurement Unknown|Approximate|Padded [Padded]
        Selects how the scanned image length is measured and reported, which
        is impossible to know in advance for scrollfed scans.
    -l 0..215.9mm [0]
        Top-left x position of scan area.
    -t 0..296.926mm [0]
        Top-left y position of scan area.
    -x 0..215.9mm [215.9]
        Width of scan-area.
    -y 0..296.926mm [296.926]
        Height of scan-area.

Type ``scanimage --help -d DEVICE'' to ge...

[David Suffield (david-suffield)]

For xsane set Compression to None in the Advanced Options dialog. These options are sticky so you won't have to set it again for this device.

[Andrey Paramonov (cmr-pent)]

Hello!

Recently new SANE frontends started to appear. A very nice one is Simple Scan:

launchpad.net/simple-scan

However, it's focused on interface simplicity and does not provide a way to "set Compression to None in the Advanced Options dialog". Nor it supports command line option not to garble the image.

How should I proceed in this case?

Andrey Paramonov

[Till Kamppeter (till-kamppeter)]

This is a problem of simple-scan not offering the advanced options of the driver. The "hpaio" SANE driver has the needed functionality.

[Andrey Paramonov (cmr-pent)]

2010/2/15 Till Kamppeter <email address hidden>:
> This is a problem of simple-scan not offering the advanced options of
> the driver. The "hpaio" SANE driver has the needed functionality.

I do not agree. You say that simple-scan and every other frontend
should implement the ability to configure the backend. This is bad
design because:

1) There is no interoperability between frontends (user must configure
each frontend).
2) Every frontend author should take effort and write the code.
3) Code duplication.

Please tell if it's hard to implement global backend option and why.

Andrey Paramonov

[Robert Ancell (robert-ancell)]

Simple scan now disables compression on drivers that support it

[Andrey Paramonov (cmr-pent)]

2010/2/16 Robert Ancell <email address hidden>:
> Simple scan now disables compression on drivers that support it

Very nice, I'll upgrade to the new version as soon as it propagates to
the repository.

Andrey Paramonov

[Hans Petter Birkeland (hanspb)]

I'm returning to this.
I have Xsane 0.998 and hplip 3.12.2. In Xsane's Advanced Options dialog the only alternative I get for compression is JPEG. It is not possible to set to none. And if I try the OP's fix and edit that file, Xsane overwrites it the next time it starts. So after three years nothing has happened, it is still not possible to save an uncompressed tif file! I find this rather outrageous!

Also, Robert Ancell claims that Simple-scan will save uncompressed, but it certainly does not. Simple-scan 3.4.3.

Does all this mean that there is no way to scan uncompressed with a HP scanner? If so, what kind of scanner do I need to get uncompressed scans?

[Robert Ancell (robert-ancell)]

Hans, are you saving as a PNG? If there are compression artifacts, please attach ~/.cache/simple-scan/simple-scan.log after scanning and this will indicate if simple-scan attempted to disable this feature.

[Hans Petter Birkeland (hanspb)]

Here is simple-scan.log and the resulting PNG in a ZIP file. Also, in the log file there is a line about jpeg quality. And there is no setting for compression quality in Preferences. The only quality setting is Resolution (dpi).

[Hans Petter Birkeland (hanspb)]

Also, from David Suffield's output of 'scanimage -h' above:

 --compression None|JPEG [JPEG]
        Selects the scanner compression method for faster scans, possibly at
        the expense of image quality.

When I do the same command I only get

--compression JPEG [JPEG]

i.e. I don't get the 'None' option. So it seems uncompressed scans are not supported for my scanner (HP Photosmart 6510). I find this quite outrageous, that some devloper has taken the liberty to decide that I don't need uncompressed scans! Especially since there is AFAIK no alternative to Sane.

[Robert Ancell (robert-ancell)]

Simple Scan reports the same as scanimage does - it cannot disable compression which is why the image is compressed. Hans - I suggest you open a new bug here. This bug is about the default being set to compressed (and simple scan not being able to disable it). The bug you are reporting is that your driver/scanner can only do compressed.

[SmilingInSeattle (dixonhoyle)]

I found this thread after scanning to create PDFs for emailing with my recently purchased HPLaserJet M1212nf MFP. The quality of text scans are terrible. I thought I had a kludgy solution from the 2010 posts, but since I'm using hplip3.14.1 I see that solution is no longer even viable. I tried changing resolutions to no avail, but now I understand why scans are quicker no than with HP LaserJet 5 that this printer replaced. I thought it was a technological advancement. Ha! I would really like to have better quality than faster speeds.

[Till Kamppeter (till-kamppeter)]

SmilingInSeattle, please open a new bug (on the package hplip) about this problem, as Robert Ancell already suggests in comment #23.

[Vier Eck (viereck)]

The original problem and it's solution did also apply to me; however, I did not find any option in xsane to change compression; I had to change the .drc-file directly under the ~/.sane/xsane directory.

[Johnny Nielsen (johnny1000)]

Still a problem.
Arch Linux + HPLIP 3.22.10
Photosmart 5520
Photosmart 6520

At this point in time HPLIP does not include a quality settings value (gone ages ago), changing the .drc file does nothing (it's overwritten with the JPEG setting), xsane advanced settings includes only JPEG compression (no "none" option), and hp-scan --compression=none reports "error: Unable to set option compression to value None"

A patch was posted 2015-02-28:
https://bugs.launchpad.net/hplip/+bug/1245578/+attachment/4330834/+files/hpscan-final.patch

@HP: Please apply upstream.

[Karl Kastner (kastner-karl)]

I experience the same problem with a Brother scanner/printer using scanimage, simple-scan and xsane. This thus does not seem to be a bug in HPLIP but much deeper in the system.

My drc-files do not contain a compression field, appending
"compression"
"none"
does not change anything. Scanimage does not have a compression option for image acquisition, neither has xsane.

The compression artefacts appear both in Ubuntu 20.04 and Ubuntu 22.4. Scanning works flawlessly in 18.04. Creating an 18.04 partition/VM is thus an inconvenient workaround.

[Marcin Owsiany (marcin-owsiany-pl)]

FTR, the "Fix Released" status visible here on the Debian bug is misleading, it was closed because change was rejected by upstream.

Also, if changing the default is undesirable, can upstream please reinstate the knob so that those who would like to take advantage of the full potential of their hardware can do by changing a frontend cofiguration setting?