Yalantis/uCrop · error · CImgArgumentException

CImgList<%s>::get_unserialize(): Unsupported pixel type '%s'

Error message

CImgList<%s>::get_unserialize(): Unsupported pixel type '%s' defined in serialized buffer.

What it means

After exhaustively checking every known pixel-type keyword (bool, uint8, int8, uint16, int16, uint32, int32, uint64, int64, float32, float64), CImgList::get_unserialize() found no matching _cimg_unserialize_case, meaning the pixel type string in the serialized header is not one this build knows. CImg throws CImgArgumentException naming the offending type string.

Source

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

        throw CImgArgumentException("CImgList<%s>::get_unserialize(): CImg header not found in serialized buffer.",
                                    pixel_type());
      if (!cimg::strncasecmp("little",str_endian,6)) endian = false;
      else if (!cimg::strncasecmp("big",str_endian,3)) endian = true;
      res.assign(N);
      _cimg_unserialize_case("bool",0,0,cimg_uint8);
      _cimg_unserialize_case("uint8","unsigned_char","uchar",cimg_uint8);
      _cimg_unserialize_case("int8",0,0,cimg_int8);
      _cimg_unserialize_case("char",0,0,char);
      _cimg_unserialize_case("uint16","unsigned_short","ushort",cimg_uint16);
      _cimg_unserialize_case("int16","short",0,cimg_int16);
      _cimg_unserialize_case("uint32","unsigned_int","uint",cimg_uint32);
      _cimg_unserialize_case("int32","int",0,cimg_int32);
      _cimg_unserialize_case("uint64","unsigned_int64",0,cimg_uint64);
      _cimg_unserialize_case("int64",0,0,cimg_int64);
      _cimg_unserialize_case("float32","float",0,cimg_float32);
      _cimg_unserialize_case("float64","double",0,cimg_float64);
      if (!loaded)
        throw CImgArgumentException("CImgList<%s>::get_unserialize(): Unsupported pixel type '%s' defined "
                                    "in serialized buffer.",
                                    pixel_type(),str_pixeltype._data);
      return res;
    }

    //@}
    //----------------------------------
    //
    //! \name Others
    //@{
    //----------------------------------

    //! Return a CImg pre-defined font with requested height.
    /**
       \param font_height Height of the desired font (exact match for 13,23,53,103).
       \param is_variable_width Decide if the font has a variable (\c true) or fixed (\c false) width.
    **/
    static const CImgList<ucharT>& font(const unsigned int requested_height, const bool is_variable_width=true) {

View on GitHub (pinned to f788b534b4)

Solutions

  1. Regenerate the serialized data using a standard CImg pixel type (uint8/float32/etc.).
  2. Use matching CImg versions on producer and consumer.
  3. Inspect the header line and correct an obviously corrupted pixel-type token.
  4. Convert the data to a standard pixel type before serializing on the producer side.

Example fix

// before (custom type in header)
// '3 half 0' -> unsupported
// after: re-save with a standard type
CImgList<float> imgs; // cast source data to float32 and re-save
imgs.save("data.cimg");    // header now declares 'float32'
Defensive patterns

Strategy: validation

Validate before calling

// Check the pixel-type token in the header before unserializing
std::istringstream hdr(headerLine); // e.g. '3 float32 0'
unsigned N; std::string ptype;
hdr >> N >> ptype;
static const char* known[] = {"bool","uint8","int8","uint16","int16","uint32","int32","uint64","int64","float32","float64"};
bool ok = false;
for (const char* k : known) if (ptype == k) { ok = true; break; }
if (!ok) throw std::runtime_error("unsupported pixel type: " + ptype);

Try / catch

try {
  imgs.unserialize(raw);
} catch (CImgArgumentException& e) {
  cimg::warn("unsupported pixel type in buffer: %s", e.what());
  // re-request data serialized with a standard pixel type
}

Prevention

When it happens

Trigger: Unserializing a buffer whose header declares a pixel type string that is unknown or misspelled (e.g. written by a custom fork, a newer CImg version, or a hand-edited header), leaving the 'loaded' flag false.

Common situations: Producer used a CImg variant/fork with extra pixel types; header line manually edited or corrupted; passing a non-CImg file whose second token happens to parse as a count but not as a valid pixel type.

Related errors


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