Scanned image scratch removal with “ICE”

@Jossie I just encountered the same bug today. Closing and restarting Gimp cured the problem for me.

@sguyader
Unfortunately that did not help.

Hermann-Josef

@Jossie same problem for me… maybe coincidence but the preview command was updated recently. Perhaps one for @David_Tschumperle

He’s no doubt the best to answer questions about the inpaint methods as well. They range from simple to sophisticated, I think the newest is based on “patchmatch” algorithm which you can find easily.

I’m sorry guys, I’ve indeed broke the split preview command today with a small update.
I’ve fixed it, and after updating your filters (push the filter update button), it should be working again.
Sorry for the inconvenience.

2 Likes

@David_Tschumperle

Good morning David,

thanks a lot for the quick repair!

I am new to G’MIC. The scratch removal it provides is something I was long thinking about working on. Now the issue seems to be solved at least for negatives and E6-emulsion. However, for Kodachrome there is the problem that the IR-channel contains a strong signal from the scene (due to the high Ag-content).

For the VueScan scratch removal approach on Kodachrome this is a disaster (applying corrections all over dark areas and thus reducing contrast there considerably) and it should not be used in my opinion. The G’MIC script and also SilverFast have problems with satisfactory consistent corrections both in dark and bright areas of the image. The correction either affects also dark areas, where there are no artefacts, or by lowering the threshold, artefacts in brighter regions are not corrected satisfactorily. Here I would like to find a solution with G’MIC.

Is there a more detailed description (more detailed than in the reference manual) on what the various inpaint commands actually do?

I guess, I will find instructions on how to write my own script in the documentation, which I have not yet studied carefully.

Many thanks for great software!

Hermann-Josef

We had a discussion about inpainting here, perhaps that helps a little bit:
https://discuss.pixls.us/t/differences-between-the-inpaint-methods/6600/6

Based on what you say about the IR channel, I’d guess more will be gained by manipulating that than tweaking the inpaint (assuming scratch removal is the goal). The inpaint pretty much does what a person might by hand; fill in selected areas with blended patches from the surrounding area.

Good evening,

you are 100% correct! This is what I did in the past, using imagemagick and imageJ in combination. However, this involved three different software packages to obtain a decent result (with one – SilverFast – being proprietary so I do not know what is going on inside.). My aim is to have a solution with just one software understanding each step.

The reason asking for details about the inpaint algorithm is that I do not want to use “black boxes” but understand what is going on. I could, of course, try the various inpaint-variants and see, what the result is. But it would be easier to have one ore two sentences describing what each of these commands does in principle.

Best wishes

Hermann-Josef

@Jossie
Then indeed you have the same curiosity as many on here :slight_smile:

It looks like the wiki page on inpainting is a bit out of date, but still holds good information. The patchmatch algorithm is even on wikipedia now (inpaint_patchmatch). The G’MIC “in-house” patch based algorithm (inpaint with a patch size specified) I think was developed by/with a student, I have no idea if there’s a paper but there’s a youtube video demonstrating it in slow motion.
There are various papers for the PDE/diffusion tensor based commands.

Please check the comparison in post number 21 above carefully. There, you can clearly observe that most of the algorithms try to interpolate or extrapolate. Only the patch based methods, especially “patchmatch”, preserve the structure of the texture and do not produce visible artefacts. Cost is the extreme computation time required.

Good morning,

thanks for the comments!

@garagecoder
following your previous post I had found the Wikipedia article and the paper on the patchmatch algorithm. I will check the other papers you mention as well.

@chris
I had seen the comparison and it is obvious that patchmatch is the winner, as you mentioned. Its big advantage is that it also includes the noise, i.e. whereas interpolation and extrapolation often produce patched areas without noise, which are easily recognized in e.g. the sky, the patchmatch version doesn’t. I will give it a try and compare the results for noise removal with VueScan and SilverFast for both E6 and K14 emulsions, as soon as I found the time to do so.

Currently the G’MIC-script in GIMP works only for VueScan scans. SilverFast, the other major scanning software, delivers the IR-channel on a sperate page in the TIF file (I do not know details about the DNG option). How about including SilverFast scans as an option in your script? There is, however, one issue with this (which should also hold for VueScan scans): Due to the wavelength difference between RGB and IR and the different paths of the light inside the scanner, there can be a slight, but constant, offset between the RGB and the IR image. I get optimum results for my scanner for a shift of (0,1) pixels.

Hermann-Josef

Hello,

experimenting with the G’MIC scratch removal I encounter a problem with the colours. I use GIMP 2.10 in its standard setup, i.e. I did not change any settings. I open the VueScan-scan and run the scratch removal. Then I export the image as a TIF – no image processing done. I would expect that the colours remain untouched. But they are not! On the left is the original image, at right the G’MIC version (both inverted with ColorPerfect in the very same way):

How come this pronounced difference in the colours?

Hermann-Josef

I wonder if it is introduced by the G’MIC script or Gimp. Could you please compare the before and after, but both saved with Gimp?

Good evening,

it is not that straight forward due to the alpha-channel, which gets stripped by G’MIC.

I loaded the image into imageJ and deleted the 4. channel and saved the image. Nothing should be done to the colours by imageJ as it is not colour managed. Then I inverted this image in the same way as the one treated with the G’MIC script. There is a colour difference:

However, the colours are different from the original! So I would conclude that it is both, GIMP and the script which produce the difference.

Hermann-Josef

Hmm it might be worth running the gmic part from console to look at the value ranges:

gmic update
gmic yourimage.tif +_fx_remove_scratches 72,2,4,3

A quick glance at the inpaint and remove scratches scripts gives me no reason to think gmic is altering it (plus there’s no automatic colourspace handling in gmic).

Edit: it occurs to me this could be hard to solve without an example input image.

The image is available here as VS_FN_0003.tif.

@garagecoder
To ensure that not some other operation introduces the colour shift I compared the original with the result of the G’MIC script directly (without converting in PhotoShop with ColorPerfect). I also compared the original with the orignal as exported by GIMP without applying the script (i.e. no changes at all!). I have removed the alpha-channel from all images with imageJ and then subtracted the GIMP-results from the original. The result is very strange:

On the left is the difference (original - script). It shows the defects as it should, but also some colour differences in all channels, which it shouldn’t. On the right is (original - GIMP only) and here only the R-channel differs, G and B are identical after the export from GIMP! Here all channels should be identical to zero, i.e. no colour difference, since no changes were made in GIMP. How can that be???

@chris
Just realized that in the TIF exported from GIMP after applying your script for scratch removal the alpha-channel is still there. All pixels are set to 65535. Since it does not contain any information it could be discarded.

Hermann-Josef

I think that is a limitation of the G’MIC plugin. I think you cannot remove channels from the image layers in Gimp, therefore you would have to remove the channel in Gimp before saving. But that information may be outdated.

Regarding the other topic, I am totally lost. I am not sure which processing chains with which software leads to which results. It may be beneficial if you could make a simple list with the different chains and results and where you observe something unusual. Furthermore, it may be beneficial for sure if you could a test file that is a bit more moderate in file size, either a crop from the file you uploaded, or, even better, a small scan that includes some pure film material at one of the edges such that we have a neutral colour reference.

But, it was a long day already, maybe @garagecoder is a bit more fresh and has a better view on the issue. Since G’MIC is not colour managed and the script does only change the image in areas that are not masked (you can check the mask by changing the “Show preview after …” drop down), I would not expect any colour change by the script.

Your TIF is very large. The alpha has noise info.

alpha

@chris
Thanks for your comments.

The colour change is very strange and probably is a GIMP problem. I come to this conclusion since a very straight forward test provides the results above: Load image into GIMP and export it without any changes as a TIF. This is what I showed above. The side aspect, that I deleted the alpha-channel in imageJ, is only for demonstration purposes, since with the alpha-channel the display looks odd. All this assumes that imagej is working correctly :slight_smile: .

@afre
Yes, the scans are quite large, indeed. The “noise info” are the scratches and defects!

Hermann-Josef

Here are the channel stats. I wonder how GIMP handles the alpha range in comparison to G’MIC. Also, I wonder if the colour change has to do with the alpha being grey scale. That would mean that there is interpolation happening on all the pixels in some manner.

R
min : 2069
max : 65535
mean: 38505.334375885774
std : 8831.2067611971379
rang: 63466

G
min : 752
max : 29167
mean: 13174.70579523862
std : 4620.8236825924314
rang: 28415

B
min : 304
max : 10904
mean: 5691.407874438356
std : 1372.6782105490483
rang: 10600

A
min : 6224
max : 56832
mean: 50701.402429768204
std : 1893.3387769891613
rang: 50608