Image cleanup tips

[SBT]

This is a continuation of a discussion started on the "ebooks we're working on" thread:

Originally Posted by SBT
Since that posting, I've discovered the wonderful world of the G'MIC plugin for GIMP, which can make a lot of difference, especially for line drawings.

G'MIC offers an overwhelming number of filters. Which ones are best suited for the rehabilitation of line drawings and what settings do you usually use?

My aim when restoring a scan of a line drawing is:

• Remove noise.
• Increase grayscale range, i.e. make the white parts white and the black parts black.

Short walk-through with gimp with G'MIC plugin installed:
Used this image from "First crossing of Greenland", F. Nansen.

• Crop image
• Select Colors->Desaturate: Luminosity
  
• At this point, I used to just clip the greyscale range using Colors->Levels. Problem is, this easily either removes bits of the drawing, or leaves noise in place. So..
• Select Filters-G'MIC:Smooth->Bilateral. You can reduce the default settings if you like, one iteration is probably sufficient. Click "Apply"
  
• Still in the G'MIC window; select Details->Sharpen[Inverse diffusion]. Click "OK"
  
• Now, go to Colors->Levels, and reduce the range to make the white bits white and the black bits black.
  
  

[Pablo]

Very good!
Thanks for sharing this.

[Jellby]

I would recommend some additional touches.

First, convert the image to true grayscale (may save some bytes, speed up processing, and avoid adding unwanted colour): Image -> Mode -> Grayscale.

Add a new black layer on top, and change its mode to "Burn" (I think that's the right English name, my Gimp is translated). This will show all the pixels either black or white, everything that's pure white in the image, stays white, but the slightest off-white becomes black. I find this very useful to detect noise and speckles that would be more noticeable in an e-ink screen.



Make sure you select the bottom layer (the image), or add an empty intermediate layer (to make it easier to correct mistakes, compare before/after, etc.), and paint white the areas in the background that should be white. Zoom in if necessary. When in doubt whether a particular spot should be white or not, disable the black layer to see the real image, it should be clearer then.



When you are done, disable or delete the black layer and save the cleaned up image.

This is especially useful when you are going to make the background transparent, but in any case it will also save additional bytes (plain speckleless background compresses better).

[SBT]

Thanks, Jellby. Good suggestion.
You mention saving space. One trick I often use for B&W line drawings is to reduce the number of shades of gray. Fifty is ample ;-) That gives quite a saving, and personally I find it difficult to detect any degradation. However, I only know how to do this in ImageMagick; "mogrify -colors 50 image.png", though it must be possible to do the same in Gimp.
I like keeping some kind of "source" images in full size, full colour, and then pass them through an Imagemagick command to shrink them, and possibly use pngcrush as well to save another few bytes, before I use them in the ebook.

[DaleDe]

Originally Posted by SBT

Thanks, Jellby. Good suggestion.
You mention saving space. One trick I often use for B&W line drawings is to reduce the number of shades of gray. Fifty is ample ;-) That gives quite a saving, and personally I find it difficult to detect any degradation. However, I only know how to do this in ImageMagick; "mogrify -colors 50 image.png", though it must be possible to do the same in Gimp.
I like keeping some kind of "source" images in full size, full colour, and then pass them through an Imagemagick command to shrink them, and possibly use pngcrush as well to save another few bytes, before I use them in the ebook.

When working with binary it is usually more space efficient to use binary values. For example 2, 4, 8, 16, 32, 64 so 50 would not be as good a choice as 32 or 64 depending on how many shades you want. 50 is likely to take the same space as 64. 16 is all most e Ink readers support so even picking 16 will make it smaller and will likely display faster since less processing will be needed to reduce the image to 16.

Dale

[SBT]

That's what I initially thought too, Dale. However, to me it seems like the PNG compression is so well thought out that it doesn't make much difference, and that the size reduction increases pretty smoothly with decreased colour space. OK, the number fifty was chosen mostly for comic relief, but using 48-64 shades seems adequate. You are of course quite correct that 16 shades will suffice on all present e-ink displays, but I've ended up using a bit more to be sure that the images look good on LCD's as well.

A word of warning: It is possible to tell PNG to use a specific bit depth (1,2,4,8,16), and save quite a few bytes. A lower bit depth can lead to trouble on certain devices – I believe this was discussed in a thread some time back, but I can't find it now.

[Tex2002ans]

Fantastic work on this tutorial SBT. We need more helpful tutorials like this on the boards!

Originally Posted by SBT

You mention saving space. One trick I often use for B&W line drawings is to reduce the number of shades of gray. Fifty is ample ;-) That gives quite a saving, and personally I find it difficult to detect any degradation. However, I only know how to do this in ImageMagick; "mogrify -colors 50 image.png", though it must be possible to do the same in Gimp.

This is possible in GIMP by changing the image from Grayscale into an Indexed image.

Image > Mode > Indexed, and under "Generate optimum palette" you insert the number of colors you want to allow. So in your case, you would place 50 in the box.

Originally Posted by DaleDe

When working with binary it is usually more space efficient to use binary values. For example 2, 4, 8, 16, 32, 64 so 50 would not be as good a choice as 32 or 64 depending on how many shades you want. 50 is likely to take the same space as 64. 16 is all most e Ink readers support so even picking 16 will make it smaller and will likely display faster since less processing will be needed to reduce the image to 16.

The way that PNG compression works, the lower the amount of colors, the smaller the file size. 50 colors will be marginally smaller than 64.

If you continue to lower the amount of colors, and hit the "plateaus" of 2, 4, or 16 colors, that is where lowering the bit depth can kick in, and you can get much larger savings (although I would avoid lowering the bit depth to 2-bit or 4-bit, see topic below).

Originally Posted by SBT

You are of course quite correct that 16 shades will suffice on all present e-ink displays, but I've ended up using a bit more to be sure that the images look good on LCD's as well.

[...]

A word of warning: It is possible to tell PNG to use a specific bit depth (1,2,4,8,16), and save quite a few bytes. A lower bit depth can lead to trouble on certain devices – I believe this was discussed in a thread some time back, but I can't find it now.

You may want to avoid messing with the 2-bit (4 color) and 4-bit (16 color) PNGs. Here is the topic where GrannyGrump ran across a 4-bit PNG bug in the Sony Readers. I also posted some of my research on the topic, and a sample EPUB with different bit-depth PNGs for testing:

https://www.mobileread.com/forums/sho...d.php?t=222916

If you can, you would still want to save your 16 color images as 8-bit depth PNGs (instead of 4-bit depth).

Or you can always settle on something with <256 colors: 50 colors, 72, 150, or even 240. Heck, I settled on 17 colors as a "hackish" way to get around certain PNG compression tools lowering my bit depth from 8-bit!

Side Note: If you ever do need to find PNG info on MobileRead, you can always type in "ScriptPNG" or "Tex2002ans PNG", and you will come across posts about me discussing it over the years.

[Jellby]

Originally Posted by Tex2002ans

Image > Mode > Indexed, and under "Generate optimum palette" you insert the number of colors you want to allow. So in your case, you would place 50 in the box.

I think I ran into some problem with this at some point. Maybe it reduced the bit depth of the final image, or maybe it was simply that it became inconvenient to work with indexed images afterwards. Another possibility is Colors > Posterize.