What causes "load_pfm(): SCALE field is undefined in file '%s'." in Yalantis/uCrop?

Fix the PFM header to include a proper scale line, e.g. "1.0" for big-endian data or "-1.0" for little-endian, right after the dimensions

Yalantis/uCrop · warning

load_pfm(): SCALE field is undefined in file '%s'.

Error message

load_pfm(): SCALE field is undefined in file '%s'.

What it means

CImg<T>::load_pfm() parses Portable FloatMap headers: magic (PF/Pf), width height, and a SCALE line (a positive scale means big-endian samples, negative little-endian). If the SCALE field fails to parse (cimg_sscanf('%lf') != 1), it warns non-fatally and continues with an uninitialized scale, which then yields wrong byte-order interpretation (is_inverted) and bogus pixel values.

Source

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

      }
      while ((err=std::fscanf(nfile," %16383[^\n]",item.data()))!=EOF && (*item=='#' || !err)) std::fgetc(nfile);
      if ((err=cimg_sscanf(item," %d %d",&W,&H))<2) {
        if (!file) cimg::fclose(nfile);
        throw CImgIOException(_cimg_instance
                              "load_pfm(): WIDTH and HEIGHT fields are undefined in file '%s'.",
                              cimg_instance,
                              filename?filename:"(FILE*)");
      } else if (W<=0 || H<=0) {
        if (!file) cimg::fclose(nfile);
        throw CImgIOException(_cimg_instance
                              "load_pfm(): WIDTH (%d) and HEIGHT (%d) fields are invalid in file '%s'.",
                              cimg_instance,W,H,
                              filename?filename:"(FILE*)");
      }
      if (err==2) {
        while ((err=std::fscanf(nfile," %16383[^\n]",item.data()))!=EOF && (*item=='#' || !err)) std::fgetc(nfile);
        if (cimg_sscanf(item,"%lf",&scale)!=1)
          cimg::warn(_cimg_instance
                     "load_pfm(): SCALE field is undefined in file '%s'.",
                     cimg_instance,
                     filename?filename:"(FILE*)");
      }
      std::fgetc(nfile);
      const bool is_color = (pfm_type=='F'), is_inverted = (scale>0)!=cimg::endianness();
      if (is_color) {
        assign(W,H,1,3,(T)0);
        CImg<floatT> buf(3*W);
        T *ptr_r = data(0,0,0,0), *ptr_g = data(0,0,0,1), *ptr_b = data(0,0,0,2);
        cimg_forY(*this,y) {
          cimg::fread(buf._data,3*W,nfile);
          if (is_inverted) cimg::invert_endianness(buf._data,3*W);
          const float *ptrs = buf._data;
          cimg_forX(*this,x) {
            *(ptr_r++) = (T)*(ptrs++);
            *(ptr_g++) = (T)*(ptrs++);
            *(ptr_b++) = (T)*(ptrs++);

View on GitHub (pinned to f788b534b4)

Solutions

Fix the PFM header to include a proper scale line, e.g. "1.0" for big-endian data or "-1.0" for little-endian, right after the dimensions
Ensure no comments or stray characters sit between the width/height line and the scale line
Regenerate the file with a conforming writer (ImageMagick, PFSTools) to normalize the header
Pre-validate the PFM header in your pipeline (magic, two integers, one float) before handing it to load_pfm

Example fix

// before (broken header)
PF
640 480
<binary float data>   // missing scale line
// after
PF
640 480
-1.0
<binary float data>   // little-endian samples

Defensive patterns

Strategy: validation

Validate before calling

// validate PFM header: magic, w h, scale before load_pfm
std::ifstream in(path);
std::string magic; int w = 0, h = 0; double scale = 0;
in >> magic >> w >> h >> scale;
if (!((magic == "PF" || magic == "Pf") && w > 0 && h > 0 && scale != 0))
  throw std::runtime_error("malformed PFM header (missing/invalid SCALE)");

Type guard

bool valid_pfm_header(const std::string& magic, double scale) {
  return (magic == "PF" || magic == "Pf") && scale != 0.0;
}

Prevention

Always emit a scale line (e.g. "-1.0") when writing PFM files
Match the scale sign to actual byte order of the samples
Validate the header (magic, ints, float) before loading HDR assets
Use conforming writers (PFSTools, ImageMagick) to produce PFM files

When it happens

Trigger: Loading a .pfm whose header omits the scale line (e.g. "PF\n640 480\n" then data) or whose scale line is malformed/comment-corrupted so %lf parsing fails.

Common situations: HDR pipeline tools writing non-conforming PFM headers, hand-trimmed or generated PFM files missing the scale, comment lines between header fields confusing the token scanner.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

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