Upscale [dcci2x] seems to be broken

Software G'MIC
1

I just downloaded GMIC GIMP 1.7.9 pre-release and now Upscale [dcci2x] is giving blocky artefacts.

1535Ɨ1023 2.8 MB

2

Thanks for the feedback Iain, do you remember when you got the last version of dcci2x working ?
Iā€™ll check the filter code.

3

Ah OK, I think I know what happened. It is probably related to the recent changes in the centering of even-sized masks for convolution. Iā€™ll try to write a fix asap.

4

This commit should fix the bug. Iā€™ve pushed the update for this filter, and it should work now both for versions 1.7.8 and 1.7.9 of Gā€™MIC.
Could you test and tell me if thatā€™s OK now ?
Thanks again Iain for your report !

5

@garagecoder , I have a question for you :slight_smile:
Iā€™ve just read the wikipedia page about the dcci2x algorithm, and decided to try implementing it once again, in order to test the optimizations Iā€™ve made in the math parser, and with the hope I could end up with something more ā€œreadableā€ than your original code which uses a lot of (cool) tricks.

Indeed, this is typically the kind of algorithms that takes decisions based on very local regions, so very well calibrated for being expressed as a math expression. So, here is my version, mainly based on the use of the math parser (through the use of the command -fill). Note that it is not particularly shorter, but I think it is easier to understand that your version based on a more ā€˜globalā€™ pipeline.

What do you think about the code structure ?

After that, of course, Iā€™ve tested to see if my version gives the same results than yours. It doesnā€™t :frowning:
I donā€™t know why yet, maybe you have an idea about that. Iā€™ve followed the wikipedia page in a quite straightforward way. It seems to me that my results look a bit better for some images (see the girl example below). Iā€™ve upscaled all the results with nearest-neighbor interpolation afterwards to make the pixel-by-pixel differences more visible.

792Ɨ264 45.6 KB

Iā€™ve made also another test to compare the speed of the commands, on a relatively large image (bigmoto.jpg, size 3072x2048, RGB), using the same parameters:

$ gmic bigmoto.jpg -tic --scale_dcci2x , -toc -tic --scale_dcci2x_new[0] , -toc -p -q
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file '/home/dtschump/work/img/bigmoto.jpg' at position 0 (1 image 3072x2048x1x3).
[gmic]-1./ Initialize timer.
[gmic]-1./ Double xy-dimensions of image [0], using DCCI2x algorithm.
[gmic]-2./ Elapsed time: 15.757 s.
[gmic]-2./ Initialize timer.
[gmic]-1./ Double xy-dimensions of image [0], using DCCI2x algorithm.
[gmic]-3./ Elapsed time: 10.119 s.
[gmic]-3./ Print images [0,1,2] = 'bigmoto.jpg, bigmoto~.jpg, bigmoto~.jpg'.
[0] = '/home/dtschump/work/img/bigmoto.jpg':
  size = (3072,2048,1,3) [72 Mio of floats].
  data = (197,197,196,195,198,197,195,192,193,194,193,194(...),120,116,114,113,112,113,116,116,118,119,117,118).
  min = 0, max = 255, mean = 109.47, std = 60.9038, coords_min = (1896,282,0,0), coords_max = (2017,169,0,0).
[1] = '/home/dtschump/work/img/bigmoto~.jpg':
  size = (6143,4095,1,3) [287 Mio of floats].
  data = (197,197.65625,197,196.9943084716797,196,195.80078125,195,196.4596557617188,198,197.2039642333984,197,195.1484375,(...),114.5625,116,116.0625,116,117.03515625,118,118.7187423706055,119,117.48046875,117,117.2922897338867,118).
  min = -7.21874, max = 266.786, mean = 109.461, std = 60.9036, coords_min = (4248,507,0,2), coords_max = (3542,1293,0,2).
[2] = '/home/dtschump/work/img/bigmoto~.jpg':
  size = (6143,4095,1,3) [287 Mio of floats].
  data = (197,197.0625,197,196.5625,196,195.25,195,196.5,198,197.8125,197,196.125,(...),114.5625,116,116.0625,116,116.9375,118,118.75,119,118,117,117.375,118).
  min = -9.65234, max = 266.676, mean = 109.461, std = 60.9031, coords_min = (4248,507,0,2), coords_max = (3542,1293,0,2).

So, at least on my machine, my new command -scale_dcci2x_new is faster. But, I use the -fill command which evaluates the math expression in parallel by default, and I have 24 cores on my machine. So, on a more standard computer, the new command is probably slower.

What do you think ? Isnā€™t it worth to replace the old command by the new one ? Have you any ideas about why it doesnā€™t render the same outcomes ? Thanks by advance for your help :slight_smile:

6

Maybe some hint, Iā€™ve realized I had a bug in the sum() function of the math parser, so this may explain the difference. Iā€™ll fix it and try again :slight_smile:

7

Upsize [dcci2x] is now working properly.

8

Just a note to say I canā€™t read through this and reply properly until this evening at the earliest, but whatever you think needs to be done I certainly trust you to go ahead :smiley:

Iā€™ll hopefully answer any questions later!

9

Andy, Iā€™ve managed to optimize my version even more (but lost a bit of readability in the process :slight_smile: ).
Anyway, Iā€™ve replaced your command by mine, keeping the one you wrote with name -scale_dcci2x_old.

1 Like
10

Cool, all that matters is the result for the end user so itā€™s of no concern to me which method is used in the end. The fun was had during the writing and discovery :smiley:

There were various differences and errors between the wiki, released paper and matlab example (see original thread). In the end I just compared the Gā€™MIC output with images in the paper (canā€™t remember exactly where I extracted from), as well as checking the PSNR values were as close as I could get. If any double checking is required Iā€™d suggest comparing to the originalā€¦ itā€™s time consuming though.