afre's G'MIC diary

Seem like you’re getting to the point where you’re solving it, I take it?

Not by a long shot. :sweat_smile: :man_shrugging: :woman_shrugging: In fact, the method I used on sample pencils noise 40 cut 0,255 destroys @Iain’s sample image.

This much simpler method is more consistent.

Original

“Denoised”

Noisy

pencils-1-og

“Denoised”

pencils-2-dn

1 Like

I think that’s about the best that is possible. If I attempt to denoise using my own brain, the denoised result is how I envision it. However, on the right-bottom corner, it’s not how I envision it though.

Update
1 afre_compare Added a tile mode. axis is now called layout to accommodate it. Several more to do items for this command. :wink:

afre_compare:
    crop={ 1=once | 2=twice },_layout={ x | y | z | tile },_normalize={ 0 | 1 }

  Crop then compare selected images interactively.
  Default values: 'crop=1', 'layout=x' and 'normalize=1'.
  ...

As usual, wait several hours before updating your commands.

2 I am going to let go of my “denoise” efforts for now. I use scare quotes because the motivation was to see how far I could get with my afre_gui* in a minimalist way. It is mostly because my tank has been empty for some time. More time + effort ≠ success.

1 Like

Awesome update

1 New afre_sdpatch Similar to variance_patch but an improvement. Was about to call it “afre_lsd” for local standard deviation but you know.

2 Feature afre_edge now has a parameter method that allows user to choose between afre_gnorm and afre_sdpatch.

As usual, wait several hours before updating your commands.

2 Likes

Regrettably, when I refreshed my system, I forgot to back up user.gmic. About a year (and a half) of R&D and private commands gone. :sob: Oh well, no use complaining about it. I can rebuild based on my other *.gmic files.

Back up your stuff please!

Oh jeez. :anguished: That’s no good at all.

Unfortunately, the G’MIC plugin only reads from user.gmic and not the imported *.gmic files. Initially, I made sure that I only used it for testing. Over time, I started writing directly to it my notes, tests, filters and commands. That was 1.5 years ago according to the last backup’s timestamp.

My fault for not backing up more regularly and laxness for writing into the one file that I forgot about but I hope that the plugin dev would consider what I requested a long time ago, which is to allow the plugin to read imported *.gmic files, which I keep them on my data drive. That would save me the hassle of backing this one file and keep all of my G’MIC files together. What do you think @David_Tschumperle?

I second the motion of having the plugin read imported .gmic files. I actually would like to have separate .gmic because it’s a little messy to work with user.gmic. It’s not too bad, just not ideal, but ok.

P.S. both gitlab and github will give you free private or public repositories.

1 Like

Hard linked user.gmic and started pushing it to a private repository. Was time consuming to set up. Now I just need to automate the process.

Now to rewrite stuff starting with the “denoising” command. Terrible memory but I am good at making things up. Good thing I can retrace this diary and compare the results.

1 Like

I guess not all is lost. I should really back up my own .gmic file. I have a code that aids into connecting points to points.

Still alive :running_man:


“Denoise” rewrite.

Noisy

pn

Method 1

0-adn0

Method 2

1-adn1

Methods 1+2

2-adn2


PS BTW, the noise type is Gaussian ATM. Current method works on tiger too, which has different characteristics (busy textures and thin detail).

Noisy

Methods 1+2

2 Likes

Could be. Does it?

As a former traditional painter, yes that seem to be doable with a lot of time.

Interesting Updates
As usual, remember to update gmic and the G’MIC plugin after an hour or so.

1 afre_edge is now in the Contours category. Filters in Testing are probably good enough to use but in my mind they will always be in development. Let me know if I should move more filters.

2 afre.gmic has a new section called MISC: Untested or Incomplete, which would house demo and misc filters. I may relegate these commands to this section:

afre_gleam afre_halfhalf fx_darken_sky fx_gamify fx_hnorm

3 afre_cleanphoto* are commands and filters that fit in the MISC section, a demo because it is trying to solve a problem brought up by the forum (start reading here), in this case dealing with dust and scratches. It is meant for illustrative purposes but it may be good enough for you to use. There are improvements coming. What will be committed is still up in the air. One that works for me is selection based local processing. See #4 below.

4 afre_section is a new command that overlays a grid on top of the image and labels the sections. This helper command would help the user determine which sections would benefit from local processing. E.g., afre_cleanphoto* will greatly benefit from a piece-wise approach to prevent overreach of the not so robust masking algorithm.

2 Likes

In Action

afre_cleanphoto graduated from the misc section. :partying_face:

ATM, it is only available in CLI. Remember to gmic update. (I will leave the rush commands afre_cleanphoto0 and afre_cleanphoto1 in afre.gmic for now, even though this replaces them.)

afre_cleanphoto:
    2<=size<=10,1<=_recovery<=100,-50<=_xy_sections<=50,_mask1>=1,_mask2>=1,...

  Clean dust and scratches from photos.
  Default values: 'size=3', 'recovery=10', 'xy_sections=1' and 'mask1=1'.

  'xy_sections' has special properties.
  - 'xy_sections>0': process masked regions specified by 'mask1','mask2',...
  - 'xy_sections<0': assign and display numbered regions.

In this segment, I will show you what it does. There is nothing special about afre_cleanphoto per se; it is a matter of thinking through the problem. Take the following image, which has dust fragments that we want to remove or reduce:

Since the fill algorithm is simple and unintelligent, we don’t want it to alter more of the image than is necessary, so the plan is to separate the image into regions, the simplest of which is a grid that would be small enough to grab areas of similar features. Roughly for this image, that would be a 30x30 mapping.

afre_section helps us with this and is built into afre_cleanphoto. You invoke it by giving the third parameter ‘xy_section’ a negative number; in our case, I have chosen -30 to subdivide the image into 900 subregions. Again, this is a minimalist method but that is our objective. It may introduce tiling artifacts and I have applied weights to mitigate that somewhat.

gmic 502.jpeg afre_cleanphoto 6,10,-30 output 502-section.png

If xy_section=1, then the command will filter the entire image as one big section. Besides unnecessarily altering unblemished areas, this kind of processing is rather slow. Therefore, I would rather take a hit in introducing tiling artifacts that weights won’t ameliorate completely.

Now, we are tasked with choosing which areas to modify. I have selected about 80% of the blemishes.

gmic 502.jpeg afre_cleanphoto 6,10,30,152,182,725,755,296,297,784,814,816,845,846,871,775,798,330,360,536,224,220,655,715,240,270,852,706,818,453 output 502-cleanphoto.png

Now for the result. You may zoom and toggle among the images in this post to see the difference. Better than before!

Note that it would have probably been easier on the command if we had considered doing some pre-processing. This input image has lots of things needing correction: lens distortion, vignetting, chromatic aberration, scanning artifacts, nonlinear gamma, file type and compression artifacts, among others. There is only so much a single command can do in light of these.

3 Likes

I rewrote afre_cleanphoto to be simpler yet faster and better (I hope), though the testing is next to nil. (Only on 502.jpeg; living dangerously. :stuck_out_tongue:)

Highlights

1 One less parameter, which I like.
2 Connected regions are processed as one region. No splitting tiles: faster in place processing.
3 Inpainting using inpaint(or inpaint_pde) instead of morphological open. May have the downsides I have shown in another thread on inpainting but when it works it looks less noticeable than open.

Discussion

2 and 3 are in fact two separate problems and could be two independent commands. 2 could be a generalized command used for user specified local processing, saving time and leaving parts of the image unprocessed. Next steps would be to make it smarter and blend better. 3 has room to grow too. It isn’t exactly seamless, doesn’t content fill evenly and removes and doesn’t add in texture. Of course, none of this is easy to do.

Only when there is more than one item, which there isn’t. Good catch.

I decided to do it that way because it makes more sense.

The first question is addressed, and the second?