Color correct scan preview

Bug #498029 reported by Robert Ancell on 2009-12-18
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Simple Scan

Bug Description

No color management tools.

Some scanners may not scan colors well or medium to expert users may want to get their colors perfect.

Ideally integrate/use code from GNOME color manager (see:

The color management would have to be non-distracting to users.

Proposed solution:
Add color profile combo boxes to preferences like F-Spot has.

Robert Ancell (robert-ancell) wrote :

Note that the profiles will need to be per-scanner (and this raises the question: should these profiles be more centrally managed?)

Changed in simple-scan:
importance: Undecided → Medium
status: New → Triaged
Robert Ancell (robert-ancell) wrote :

From Richard Hughes (gnome-color-manager developer)

> I don't know much about color management so my question is:
> - What do I need to do to make Simple Scan work with GNOME Color Manager?
> - Is there a GPL project I can lift some code from?

Well, first you need to ask gnome-color-manager for a list of suitable
profiles using the DBus interface:

If you know the device you're using (you probably should) then you can
call GetProfilesForDevice() with the sysfs path, and a list of
profiles will be returned. If more than one profile is returned you
probably need to show it in a combo-box or something, but it would be
quite unusual for more than one profile to be returned. If you get no
results, then it's probably because the user has never assigned a
profile for that device (i.e. there is no a-priori mapping). In this
case you can either default to not doing color conversion yourself, or
instead call the GetProfilesForType() dbus method, using the
type=scanner. This will return a list of profiles that are suitable
for use with scanners.

Now, when you have a filename of the profile you want to use it's an
easy (!) case of acquiring the image like usual, and then you can

* Just save the image with an embedded color profile (see bug -- I'm working as
fast as I can on the infrastructure bits)
* Convert the image from device-mapping to something like sRGB using
lcms (there are examples in the lcms tarball)

I think it's probably best you do the first one, unless you know
you're going to be using the images in a non-color-aware application.

Robert Ancell (robert-ancell) wrote :

Color management patch as provided by Richard Hughes. Committed with some structural changes. This patch loads the profile for scanned documents (at scan time) and embeds it in the saved files.

Work still to be done:
- Need a proper color manager in simple-scan that watches for color profile changes and doesn't make a dbus-call for each page
- The preview needs to apply the color profile (using lcms?)

summary: - No color management
+ Color correct scan preview
Pascal de Bruijn (pmjdebruijn) wrote :

Here are some sample files:

it8_before.png (scan before applying profile)
it8_after.png (scan after applying profile)
sane_hp_photosmart_c6280.icc (simple ICC profile)

Pascal de Bruijn (pmjdebruijn) wrote :

I notice that the color profile is getting embedded in the image, but this means all non-color-managed application will show the wrong colors...

Especially for simple-scan it would be a much better idea to convert to sRGB at all times, since simple-scan primarily caters to joe normal.

Any chance the color management patch + preview adjustment will make it into Lucid?

Robert Ancell (robert-ancell) wrote :

Thanks for the test data! It is too late for Lucid for this feature but newer versions of simple-scan will be available in a PPA for those who want this to work in Lucid.

MarkieB (ubunt-u-markbenjamin) wrote :

Am I right in thinking that this patch needs a UI component to allow the necessary adjustments?

ps it won't patch cleanly to bzr HEAD now

$ patch -p0 < simple-scan-color-manage.patch
patching file
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 31.
1 out of 1 hunk FAILED -- saving rejects to file
patching file src/book.c
Hunk #6 succeeded at 376 (offset 25 lines).
Hunk #7 succeeded at 387 (offset 25 lines).
Hunk #8 succeeded at 422 (offset 25 lines).
patching file src/book.h
patching file src/page.c
Hunk #1 FAILED at 785.
Hunk #2 FAILED at 799.
Hunk #3 FAILED at 819.
3 out of 3 hunks FAILED -- saving rejects to file src/page.c.rej
patching file src/page.h
Hunk #1 succeeded at 116 (offset 4 lines).
patching file src/scanner.c
Hunk #1 succeeded at 1173 (offset 23 lines).
patching file src/scanner.h
Hunk #1 succeeded at 131 (offset 9 lines).
patching file src/simple-scan.c
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 15.
Hunk #2 succeeded at 304 (offset 84 lines).
Hunk #3 succeeded at 470 (offset 84 lines).
Hunk #4 succeeded at 491 (offset 84 lines).
1 out of 4 hunks FAILED -- saving rejects to file src/simple-scan.c.rej
patching file src/ui.c

the / simple-scan.c difficulties are a simple matter of an include/link, no trouble there; it's less clear how to resolve page_save() in src/page.c as the patch adds a function parameter icc_profile while HEAD seems to access an icc_profile from page->priv->icc_profile, as well as the modification of gdk_pixbuf_save_to_callbackv() to gdk_pixbuf_save_to_callback()

Robert Ancell (robert-ancell) wrote :

MarkieB, these changes are already applied in simple-scan. The change that isn't in Lucid is the book preview being colour corrected (this patch does not yet exist and is waiting on changes in GTK+).

MarkieB (ubunt-u-markbenjamin) wrote :

Hi Robert,

thanks for writing back so quickly; I see no way of adjusting the color profile though? Should there be a(n) UI component / should we generate the profile independently?



Pascal de Bruijn (pmjdebruijn) wrote :

Generating a color profile is not really simple-scan's task, this is why we have GNOME Color Manager...

Robert Ancell (robert-ancell) wrote :

Yes, colour profiles are managed by GNOME Color Manager. There's probably a case for a button in the preferences/menu/toolbar to open GNOME Color manager.

MarkieB (ubunt-u-markbenjamin) wrote :

I see :-)

however "Before profiling the device, you have to manually capture an image of the calibrated target" sounds as though it's less than simple - unless there's one printed on the cover of every ubuntu cd :-D

plus from the looks of it there's no simple gui tool for generation of custom profiles from slider settings?

Pascal de Bruijn (pmjdebruijn) wrote :

Well, I think GNOME Color Manager, can capture data from SANE directly now (at least if I'm not mistaken).

MarkieB (ubunt-u-markbenjamin) wrote :

what difference would that make? Unless you scan a target - you need a pre-printed target to scan it I suppose - then gnome-color-manager has no basis for making a comparison?

Not that I necessarily understand what a color profile is, I'm currently checking the 112-page specification to see whether it would be feasible to write a plug-in/app to manually create color profiles from arbitrary files - as most scan software includes at least brightness/contrast/gamma correction, some color curves would potentially be appropriate too?

I'll have to guess that for an OS that 'works' people may need a scanning application that is capable of making adjustments without specialist tools;

one pathway that suggests itself is to color-adjust an arbitrary scan in, say, gimp, then compare it to the scan pre-adjustment, in gnome-color-manager, although precisely how to manage that is unclear; possibly involving adding an arbitrary target / chart type, although how?

As my color laser printer won't print a chart looking remotely similar to the reference charts, I suppose the most straightforward would be that when I order picture prints, then I order one of a chart I've downloaded, hope the picture printing service manages to print it properly :-)

sounds a load of hassle for a 'simple' scanning application though

Pascal de Bruijn (pmjdebruijn) wrote :

That's probably not a really good idea...

For decent profiles you simply need a decent IT8 chart...

Anyway, for simple-scan, we only want to be able to apply a previously created profile, and have gcm convert the output to sRGB, creation of the profiles can remain in GNOME Color Manager...

MarkieB (ubunt-u-markbenjamin) wrote :


so as I say, the 'decent IT8 chart' it's printed on the Ubuntu cd? :-D

Pascal de Bruijn (pmjdebruijn) wrote :

As in, bought from Wolf Faust or another respected vendor.

MarkieB (ubunt-u-markbenjamin) wrote :

My point then, it's neither free nor particularly simple; a slider-based color correction would be both

Pascal de Bruijn (pmjdebruijn) wrote :

Yes, but slider based color correction would be too inaccurate to bother with...

Proper profiling is the only way to get accurate color (with any scanner (cheap or expensive))...

possibly, you're the specialist :-)

I'd have said that a gimp-style [even gimp-derived] color-correction
interface, that is possibly one of the more involved slider interfaces I
could think of, would give sufficient control? It includes curves rather
than sliders for the actual color values; I'm thinking, though, of a
simpler interface such as brightness/contrast at least - although that
may be for my specific needs rather than everyone's - as even windows
Vista has that :-D

So, what's new? IS color managed scanning not going to be available in 2.32?

Renne (renne) wrote :

How to get a ICC-Profile for your scanner?

1.) Since M$ added ICC-based color management to Windoze Vista/7 scanner/printer/display vendors have switched from proprietary color management in their drivers/applications to shipping model-based ICC-profiles with the Windoze drivers! Just check the shipped Windoze Vista/7 drivers! ;-)

2.) If model-specfic profiles are not good enough or not available get a IT.8 target with a reference file (e.g. from, scan the reference file and feed GCM with the image and reference file to get a profile.

Which libraries to use for processing color management?

GCM uses Argyll, which has very fast and sophisticated libraries. So, to get high quality color management and keep dependencies low use Argyll, too.

How to decide whether to process color management or embed profile?

Most applications do not support color management, so

1. ) If scanning into FILE process raw data with scanner profile as source and SRGB profile as target! Additionally provide a 16-bit "Professional" preset scanning raw data with embedded scanner profile and without color space processing into a lossless TIFF file (don't use JPEG or PNG, as lossy encodings make NO sense for professional scans) .

2.) If directly sending scans to target devices with profiles (e.g. printer, display, etc.) use scanner profile as source and target profile to process color space (Argyll even allows to merge source device profiles and target device profiles to get quality and speed optimized mapping tables). If the target does not provide any profile, process raw data with scanner profile as source and SRGB or CMYK profile as target!

Michael Nagel (nailor) wrote :

(19:29:57) Michael Nagel: Color correct scan preview
(19:31:02) robert_ancell: yes we need it, don't know how to do it
(19:31:07) Michael Nagel: what about that patch? it is commited and works, but it does not offer preview?
(19:31:32) robert_ancell: that gets the profile and puts it in the output image, but doesn't show the correction in the scan preview
(19:32:35) Michael Nagel: preview is what you see in the simple-scan application on screen?
(19:33:17) robert_ancell: yes

Rik Shaw (rik-shaw) wrote :

"photo" scans with Canon LIDE 110 and 210 all come out with heavy "gray" background, and "over scan" so that the back sides of documents show through.

I don't think most simple-scan users are after full color correction, but just making "white not gray". I know this is complicated, but am holding out hope that there is some solution possible *for simple-scan* that will make it so users won't have to GIMP adjust every color scan.

The following askubuntu post seems to give a good summary of the problem:

I am guessing the user was doing a "photo" scan even though the document is gray / black / white.

Is there some way to include a checkbox "make white" or something like that? Maybe a pointer can be used to select what pixel could be "white". If user need other color corrections (reds / blues, etc) then not for simple scan. But the most simple uses of scanning color documents need to have "white" not gray backgrounds.

Pascal de Bruijn (pmjdebruijn) wrote :

Black/White autolevels, has very little to do with the bug as reported here, please report a seperate issue for that.

Rik Shaw (rik-shaw) wrote :

Thanks for the reply indicating this would be a different bug. I will attempt to do so. The reason I posted here is because the blueprint for "ensure white background of pages are white" was linked here to this bug. Here is a link back to that blueprint:

I'll make a new bug and link it to the above blueprint. In my testing with xsane, if I bump contrast up to 60% then the page will be white and no "back side of document shadows are introduced". Of course then may need other adjustments to offset that contrast bump! Which then gets back to the application being a bit heavy. Maybe pre-settings for "color text" and "grayscale" could be added to "text" and "photo" (2 current options).

Rik Shaw (rik-shaw) wrote :

This bug seems to represent the majority of my concerns for "a clean white background" to scanned color (or gray-scale) documents (that aren't photographs):

Made a better summary of the situation there.

Is the color profile from GNOME not enough to handle this ?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.