Upscale [dcci2x] seems to be broken


#1

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


(David Tschumperlé) #2

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


(David Tschumperlé) #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.


(David Tschumperlé) #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 !


(David Tschumperlé) #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.

http://pastebin.com/qJPbE8b2

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.

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:


(David Tschumperlé) #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!


(David Tschumperlé) #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.


#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.