Yalantis/uCrop · error · CImgArgumentException

"[" cimg_appname "_math_parser] CImg<%s>: Function 'resize()

Error message

"[" cimg_appname "_math_parser] CImg<%s>: Function 'resize()': Cannot both fill and resize image (%u,%u,%u,%u) to new dimensions (%u,%u,%u,%u)."

What it means

Inside the math parser, resize() cannot operate when the parser is in fill mode (mp.is_fill) and the target image shares its data buffer with the parser's output image (img._data==mp.imgout._data): resizing would reallocate the buffer currently being filled, corrupting parser state. CImg deliberately rejects this combination.

Source

Thrown at ucrop/src/main/jni/CImg.h:27298

      static double mp_image_resize(_cimg_math_parser& mp) {
        mp_check_list(mp,"resize");
        const unsigned int ind = (unsigned int)cimg::mod((int)_mp_arg(2),mp.imglist.width());
        cimg::mutex(6);
        CImg<T> &img = mp.imglist[ind];
        const double
          _w = mp.opcode[3]==~0U?-100:_mp_arg(3),
          _h = mp.opcode[4]==~0U?-100:_mp_arg(4),
          _d = mp.opcode[5]==~0U?-100:_mp_arg(5),
          _s = mp.opcode[6]==~0U?-100:_mp_arg(6);
        const unsigned int
          w = (unsigned int)(_w>=0?_w:-_w*img.width()/100),
          h = (unsigned int)(_h>=0?_h:-_h*img.height()/100),
          d = (unsigned int)(_d>=0?_d:-_d*img.depth()/100),
          s = (unsigned int)(_s>=0?_s:-_s*img.spectrum()/100),
          interp = (int)_mp_arg(7);
        if (mp.is_fill && img._data==mp.imgout._data) {
          cimg::mutex(6,0);
          throw CImgArgumentException("[" cimg_appname "_math_parser] CImg<%s>: Function 'resize()': "
                                      "Cannot both fill and resize image (%u,%u,%u,%u) "
                                      "to new dimensions (%u,%u,%u,%u).",
                                      img.pixel_type(),img._width,img._height,img._depth,img._spectrum,w,h,d,s);
        }
        const unsigned int
          boundary = (int)_mp_arg(8);
        const float
          cx = (float)_mp_arg(9),
          cy = (float)_mp_arg(10),
          cz = (float)_mp_arg(11),
          cc = (float)_mp_arg(12);
        img.resize(w,h,d,s,interp,boundary,cx,cy,cz,cc);
        cimg::mutex(6,0);
        return cimg::type<double>::nan();
      }

      static double mp_image_s(_cimg_math_parser& mp) {
        unsigned int ind = (unsigned int)mp.opcode[2];

View on GitHub (pinned to f788b534b4)

Solutions

Split the operation: perform fill(...) and resize(...) as two separate commands/expressions.
Resize a different image index, or copy the data first and resize the copy.
Remove resize() from inside the fill/math-parser expression and apply it after evaluation completes.
Restructure the pipeline so the output image is fully sized before filling.

Example fix

// before: fill and resize entangled on same image
fill(expr_with_resize(#0,...))
// after: separate steps
resize(#0,w,h,d,s,-1); fill(#0,expr_without_resize)

Defensive patterns

Strategy: fallback

Validate before calling

// Detect the conflicting in-place resize-before-evaluating
function isUnsafeInPlaceResize(targetIndex, fillOutputIndex) { return targetIndex === fillOutputIndex; }

Try / catch

try { evalMath(expr); } catch (e) { if (String(e).includes("Function 'resize()'") && String(e).includes('Cannot both fill and resize')) { runSplitPipeline(); } else throw e; }

Prevention

Never call resize() on the output image inside a fill/expr expression
Split fill and resize into sequential commands
Pre-size the output image before evaluation
Keep math expressions free of buffer-reallocation calls on the evaluated image

When it happens

Trigger: Calling resize(...) on the same image that the enclosing fill/expr expression is writing into (identical data pointer) while is_fill is active — e.g. resize(#0,...) where #0 is the output image of the current math evaluation.

Common situations: In-place expressions that both fill and resize the output image; scripts combining fill(...) with resize(...) on the same image index; refactorings that merged two separate pipeline steps into one expression.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

AI-assisted analysis of Yalantis/uCrop@f788b534b4 (2026-09-08). Data as JSON: /api/errors/dadaab8c7e3c6615. Report an issue: GitHub.