What causes "load(): Failed to open file '%s'." in Yalantis/uCrop?

Verify the file exists and is readable at the exact absolute path passed (std::FILE *f=std::fopen(path,"rb"); f?fclose(f):log error).

Yalantis/uCrop · error · CImgIOException

load(): Failed to open file '%s'.

Error message

load(): Failed to open file '%s'.

What it means

CImg<T>::load() failed to open the given file via std_fopen because it does not exist, is unreadable, or the path is wrong. This is a generic entry-point loader in the vendored CImg.h (bundled with uCrop's JNI build) that tries multiple format-specific loaders; the very first step is opening the file, and failure is reported with CImgIOException.

Source

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

                 !cimg::strcasecmp(ext,"ogm") ||
                 !cimg::strcasecmp(ext,"ogg") ||
                 !cimg::strcasecmp(ext,"ogv") ||
                 !cimg::strcasecmp(ext,"qt") ||
                 !cimg::strcasecmp(ext,"rm") ||
                 !cimg::strcasecmp(ext,"vob") ||
                 !cimg::strcasecmp(ext,"webm") ||
                 !cimg::strcasecmp(ext,"wmv") ||
                 !cimg::strcasecmp(ext,"xvid") ||
                 !cimg::strcasecmp(ext,"mpeg")) load_video(filename);
        else is_loaded = false;
      } catch (CImgIOException&) { is_loaded = false; }

      // If nothing loaded, try to guess file format from magic number in file.
      if (!is_loaded) {
        std::FILE *file = cimg::std_fopen(filename,"rb");
        if (!file) {
          cimg::exception_mode(omode);
          throw CImgIOException(_cimg_instance
                                "load(): Failed to open file '%s'.",
                                cimg_instance,
                                filename);
        }

        const char *const f_type = cimg::ftype(file,filename);
        cimg::fclose(file);
        is_loaded = true;
        try {
          if (!cimg::strcasecmp(f_type,"pnm")) load_pnm(filename);
          else if (!cimg::strcasecmp(f_type,"pfm")) load_pfm(filename);
          else if (!cimg::strcasecmp(f_type,"bmp")) load_bmp(filename);
          else if (!cimg::strcasecmp(f_type,"inr")) load_inr(filename);
          else if (!cimg::strcasecmp(f_type,"jpg")) load_jpeg(filename);
          else if (!cimg::strcasecmp(f_type,"pan")) load_pandore(filename);
          else if (!cimg::strcasecmp(f_type,"png")) load_png(filename);
          else if (!cimg::strcasecmp(f_type,"tif")) load_tiff(filename);
          else if (!cimg::strcasecmp(f_type,"gif")) load_gif_external(filename);

View on GitHub (pinned to f788b534b4)

Solutions

Verify the file exists and is readable at the exact absolute path passed (std::FILE *f=std::fopen(path,"rb"); f?fclose(f):log error).
Convert Android URIs to a real file path (or copy to app cache) before handing the char* to CImg.
Check POSIX permissions and SELinux/storage permissions for the process.
Load from an in-memory buffer or std::FILE* you already opened instead of a filename.

Example fix

// before
img.load("photo.png");
// after
std::FILE *f = std::fopen("/sdcard/photo.png", "rb");
if (!f) { /* handle missing file */ }
else { fclose(f); img.load("/sdcard/photo.png"); }

Defensive patterns

Strategy: try-catch

Validate before calling

bool fileReadable(const char* p){ if(!p||!*p) return false; std::FILE* f=std::fopen(p,"rb"); if(!f) return false; std::fclose(f); return true; }

Try / catch

try { img.load(path); } catch (cimg_library::CImgIOException& e) { // file could not be opened: check path/permissions
  log("CImg load failed: %s", e.what()); }

Prevention

Always use absolute paths in JNI/Android code
Check file existence and readability with fopen before load
Handle Android content:// URIs by copying to a real file first
Verify storage permissions at runtime

When it happens

Trigger: Calling img.load(filename) (or load_cimg/load_other paths) where std_fopen(filename,"rb") returns NULL: file missing, wrong working directory, no read permission, or filename is an empty/garbage string.

Common situations: Passing an Android content:// or relative path instead of an absolute filesystem path in JNI code; file deleted between check and load; typo in extension/path; storage permission missing so the file simply cannot be opened.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

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