Is There An Image Size Limit for fx_cpencil

Software G'MIC
1

Hi, I have a question about running fx_cpencil from the command line. The command is:

gmic inputImage.jpg fx_cpencil 1.3,50,20,2,2,1,0 o outputImage.jpg

I just ran this command on an image that had dimensions of 3k x 2k and it finished in less than a minute. Very cool.

But I first ran this same command against a 5k x 4k image and I wound up killing it after it had been running for a solid day. I tried again with a different source image of the same size and got the same results. In both cases there were no error messages and the last message written to the screen was:

Quantize image [0] using 20 levels, with keeping value range.

My question is this: is there an upper bounds on the number of pixels that the fx_cpencil algorithm can process.

Thanks, Jim

2

The amount of processing that your machine can handle depends on your specs. Processing will become more taxing as your pixel count increases. Think of it as 5000*4000-3000*2000=14000000: you have 14 million more pixels to process!

20 levels means that the command is repeating something 20 times. While the scale may be different, doing anything 20 times is time consuming.

3

I was thinking it actually may have to do with 32-bit restriction. I don’t even use 32-bit gmic. I doubt that this is the case.

4

Hi Reptorian, You are right about doubting. This is with the 64 bit version. But I am running an older version - 2.4.1 so I am overdue for an update.

5

Always a good idea to update. It is anecdotal but it seems G’MIC is getting faster by the version. Good job @David_Tschumperle et al. Stuff I haven’t been able to do on my ancient low end system is now possible.

I may also be getting better at making commands. :stuck_out_tongue:

6

Well gee, this isn’t promising. With the 2.4.1 version of G’MIC, running fx_cpencil got right quick to the quantize image output message where things hung. Running the same command (same parms) with 2.9.4, I’m bogged down at the very first message: Input all frames of TIFF file.

On the other hand, I’m guessing that this must represent a change in the filter’s work flow since this message does not appear in the output with version 2.4.1.

I’ll let her run for a day and see what happens.

7

Hi Afre,

It is amazing how things can quickly explode in size. But think about it like this. If 6 million pixels can be processed in 1 minute, then you wouldn’t think that 20 million pixels (3 times as many pixels) could not be processed in 1200 minutes, or 1,200 times more time. Perhaps the algorithm is such that there is an exponential increase in the number of instructions executed per pixel as image size increases.

8

Hi Afre,
Regarding “20 levels means that the command is repeating something 20 times” in this case I don’t think that’s right. The quantize value is similar to posterization in that you are saying how many levels of color you want in your output. 2 gives you b/w while 255 leaves color unaltered. Considered in isolation, the 255 option should run the quickest since you’re basically saying don’t do anything. However, setting this value to 255 could add to the processing burden of other downstream steps in the algorithm since there would be more color values to parse.

9

Ah, you are right. I answered without looking at fx_cpencil and pencilbw (which the former uses). sharpen and smooth (which the latter uses) can be intensive for larger images.

What I do know is that it isn’t as simple as 3x the resources for 3x the number of pixels. Think of it this way. Due to COVID-19, hospitals are near or at capacity. Not reaching capacity doesn’t mean that the work and stress level is the total effort divided by the number of patients. The same applies for RAM or swap, if I am running +75%, my system will likely be unstable, even if I still have some remaining.

10

As an update, I tried running the command on a 4k x 4k file and terminated it after 25 hours.

I just ran the command on a 3.2k x 3.2k image with debug on and piped the output to file. The process completed in about 1 minute and produced a log file of 517k bytes.

I followed up by running the command on a 3.6k x 3.6k image. The program has now been running for 14 minutes and the size of the log file is up to just over 4 Mb. It seems that the amount of processing has exploded for images at some point between a 3.2x3.2 k image and a 3.6x3.6 k image.

Update: Killed the 3.6x3.6k test after 1 hour of run time. Following are the last several lines of the log file.

<gmic>-3./fx_cpencil/*repeat/*local/*local/quantize/*repeat/*local/*if/colormap/*repeat/*local/*if/*if/*do/ Item 'if', selections [0,1,2].
<gmic>-3./fx_cpencil/*repeat/*local/*local/quantize/*repeat/*local/*if/colormap/*repeat/*local/*if/*if/*do/ Command 'if': arguments = '$is_half' -> '0'.
[gmic]-3./fx_cpencil/*repeat/*local/(...)/*if/*if/*do/*if/ Start 'if...endif' block -> condition '0' does not hold.
<gmic>-3./fx_cpencil/*repeat/*local/*local/quantize/*repeat/*local/*if/colormap/*repeat/*local/*if/*if/*do/*if/ Item '..,1,1,{1,s+1}' -> '..,1,1,4', selection [].
<gmic>-3./fx_cpencil/*repeat/*local/*local/quantize/*repeat/*local/*if/colormap/*repeat/*local/*if/*if/*do/*if/ Command 'input': arguments = '..,1,1,4' -> '[-2],1,1,4'.
[gmic]-3./fx_cpencil/*repeat/*local/(...)/*if/*if/*do/*if/ Input black image at position 3 (1 image 20x1x1x4).
<gmic>-4./fx_cpencil/*repeat/*local/*local/quantize/*repeat/*local/*if/colormap/*repeat/*local/*if/*if/*do/*if/ Item 'f..', selection [2].
<gmic>-4./fx_cpencil/*repeat/*local/*local/quantize/*repeat/*local/*if/colormap/*repeat/*local/*if/*if/*do/*if/ Command 'fill': arguments = '>I[#3\,i]+=[ I[#0\,x]\,1 ]'.
[gmic]-4./fx_cpencil/*repeat/*local/(...)/*if/*if/*do/*if/ Fill image [2] with expression '>I[#3,i]+=[ I[#0,x],1 ]'.

Unfortunately I don’t have the time just now to pursue this further - and am not sure when I’ll be able to return to it.

Thanks everyone for your feedback. Jim