Tiny OpenEXR image loader/saver library

Overview

Tiny OpenEXR image library.

Total alerts

Example

AppVeyor build status

Travis build Status

Coverity Scan Build Status

tinyexr is a small, single header-only library to load and save OpenEXR (.exr) images. tinyexr is written in portable C++ (no library dependency except for STL), thus tinyexr is good to embed into your application. To use tinyexr, simply copy tinyexr.h, miniz.c and miniz.h(for zlib. You can use system-installed zlib instead of miniz. Controlled with TINYEXR_USE_MINIZ compile flag) into your project.

Features

Current status of tinyexr is:

  • OpenEXR v1 image
    • Scanline format
    • Tiled format
      • Tile format with no LoD (load).
      • Tile format with LoD (load).
      • Tile format with no LoD (save).
      • Tile format with LoD (save).
    • Custom attributes
  • OpenEXR v2 image
    • Multipart format
      • Load multi-part image
      • Save multi-part image
      • Load multi-part deep image
      • Save multi-part deep image
  • OpenEXR v2 deep image
    • Loading scanline + ZIPS + HALF or FLOAT pixel type.
  • Compression
    • NONE
    • RLE
    • ZIP
    • ZIPS
    • PIZ
    • ZFP (tinyexr extension)
    • B44?
    • B44A?
    • PIX24?
  • Line order.
    • Increasing, decreasing (load)
    • Random?
    • Increasing (save)
    • decreasing (save)
  • Pixel format (UINT, FLOAT).
    • UINT, FLOAT (load)
    • UINT, FLOAT (deep load)
    • UINT, FLOAT (save)
    • UINT, FLOAT (deep save)
  • Support for big endian machine.
    • Loading scanline image
    • Saving scanline image
    • Loading multi-part channel EXR (not tested)
    • Saving multi-part channel EXR (not tested)
    • Loading deep image
    • Saving deep image
  • Optimization
    • C++11 thread loading
    • C++11 thread saving
    • ISPC?
    • OpenMP multi-threading in EXR loading.
    • OpenMP multi-threading in EXR saving.
    • OpenMP multi-threading in deep image loading.
    • OpenMP multi-threading in deep image saving.
  • C interface.
    • You can easily write language bindings (e.g. golang)

Supported platform

  • x86-64
    • Windows 7 or later
    • Linux(posix) system
    • macOS
  • AARCH64
    • aarch64 linux(e.g. Raspberry Pi)
    • Android
    • iOS
    • macOS
  • RISC-V(Should work)
  • Big endian machine(not maintained, but should work)
    • SPARC, PowerPC, ...
  • WebAssembly(JavaScript)
    • Loader only(See js)
  • Python binding

Requirements

  • C++ compiler(C++11 recommended. C++03 may work)

Use case

New TinyEXR (v0.9.5+)

Older TinyEXR (v0.9.0)

Examples

Experimental

Usage

NOTE: API is still subject to change. See the source code for details.

Include tinyexr.h with TINYEXR_IMPLEMENTATION flag (do this only for one .cc file).

//Please include your own zlib-compatible API header before
//including `tinyexr.h` when you disable `TINYEXR_USE_MINIZ`
//#define TINYEXR_USE_MINIZ 0
//#include "zlib.h"
#define TINYEXR_IMPLEMENTATION
#include "tinyexr.h"

Compile flags

  • TINYEXR_USE_MINIZ Use miniz (default = 1). Please include zlib.h header before tinyexr.h if you disable miniz support(e.g. use system's zlib).
  • TINYEXR_USE_PIZ Enable PIZ compression support (default = 1)
  • TINYEXR_USE_ZFP Enable ZFP compression supoort (TinyEXR extension, default = 0)
  • TINYEXR_USE_THREAD Enable threaded loading using C++11 thread (Requires C++11 compiler, default = 0)
  • TINYEXR_USE_OPENMP Enable OpenMP threading support (default = 1 if _OPENMP is defined)
    • Use TINYEXR_USE_OPENMP=0 to force disable OpenMP code path even if OpenMP is available/enabled in the compiler.

Quickly reading RGB(A) EXR file.

  const char* input = "asakusa.exr";
  float* out; // width * height * RGBA
  int width;
  int height;
  const char* err = NULL; // or nullptr in C++11

  int ret = LoadEXR(&out, &width, &height, input, &err);

  if (ret != TINYEXR_SUCCESS) {
    if (err) {
       fprintf(stderr, "ERR : %s\n", err);
       FreeEXRErrorMessage(err); // release memory of error message.
    }
  } else {
    ...
    free(out); // release memory of image data
  }

Reading layered RGB(A) EXR file.

If you want to read EXR image with layer info (channel has a name with delimiter .), please use LoadEXRWithLayer API.

You need to know layer name in advance (e.g. through EXRLayers API).

  const char* input = ...;
  const char* layer_name = "diffuse"; // or use EXRLayers to get list of layer names in .exr
  float* out; // width * height * RGBA
  int width;
  int height;
  const char* err = NULL; // or nullptr in C++11

  // will read `diffuse.R`, `diffuse.G`, `diffuse.B`, (`diffuse.A`) channels
  int ret = LoadEXRWithLayer(&out, &width, &height, input, layer_name, &err);

  if (ret != TINYEXR_SUCCESS) {
    if (err) {
       fprintf(stderr, "ERR : %s\n", err);
       FreeEXRErrorMessage(err); // release memory of error message.
    }
  } else {
    ...
    free(out); // release memory of image data
  }

Loading Singlepart EXR from a file.

Scanline and tiled format are supported.

  // 1. Read EXR version.
  EXRVersion exr_version;

  int ret = ParseEXRVersionFromFile(&exr_version, argv[1]);
  if (ret != 0) {
    fprintf(stderr, "Invalid EXR file: %s\n", argv[1]);
    return -1;
  }

  if (exr_version.multipart) {
    // must be multipart flag is false.
    return -1;
  }

  // 2. Read EXR header
  EXRHeader exr_header;
  InitEXRHeader(&exr_header);

  const char* err = NULL; // or `nullptr` in C++11 or later.
  ret = ParseEXRHeaderFromFile(&exr_header, &exr_version, argv[1], &err);
  if (ret != 0) {
    fprintf(stderr, "Parse EXR err: %s\n", err);
    FreeEXRErrorMessage(err); // free's buffer for an error message
    return ret;
  }

  // // Read HALF channel as FLOAT.
  // for (int i = 0; i < exr_header.num_channels; i++) {
  //   if (exr_header.pixel_types[i] == TINYEXR_PIXELTYPE_HALF) {
  //     exr_header.requested_pixel_types[i] = TINYEXR_PIXELTYPE_FLOAT;
  //   }
  // }

  EXRImage exr_image;
  InitEXRImage(&exr_image);

  ret = LoadEXRImageFromFile(&exr_image, &exr_header, argv[1], &err);
  if (ret != 0) {
    fprintf(stderr, "Load EXR err: %s\n", err);
    FreeEXRHeader(&exr_header);
    FreeEXRErrorMessage(err); // free's buffer for an error message
    return ret;
  }

  // 3. Access image data
  // `exr_image.images` will be filled when EXR is scanline format.
  // `exr_image.tiled` will be filled when EXR is tiled format.

  // 4. Free image data
  FreeEXRImage(&exr_image);
  FreeEXRHeader(&exr_header);

Loading Multipart EXR from a file.

Scanline and tiled format are supported.

  // 1. Read EXR version.
  EXRVersion exr_version;

  int ret = ParseEXRVersionFromFile(&exr_version, argv[1]);
  if (ret != 0) {
    fprintf(stderr, "Invalid EXR file: %s\n", argv[1]);
    return -1;
  }

  if (!exr_version.multipart) {
    // must be multipart flag is true.
    return -1;
  }

  // 2. Read EXR headers in the EXR.
  EXRHeader **exr_headers; // list of EXRHeader pointers.
  int num_exr_headers;
  const char *err = NULL; // or nullptr in C++11 or later

  // Memory for EXRHeader is allocated inside of ParseEXRMultipartHeaderFromFile,
  ret = ParseEXRMultipartHeaderFromFile(&exr_headers, &num_exr_headers, &exr_version, argv[1], &err);
  if (ret != 0) {
    fprintf(stderr, "Parse EXR err: %s\n", err);
    FreeEXRErrorMessage(err); // free's buffer for an error message
    return ret;
  }

  printf("num parts = %d\n", num_exr_headers);


  // 3. Load images.

  // Prepare array of EXRImage.
  std::vector<EXRImage> images(num_exr_headers);
  for (int i =0; i < num_exr_headers; i++) {
    InitEXRImage(&images[i]);
  }

  ret = LoadEXRMultipartImageFromFile(&images.at(0), const_cast<const EXRHeader**>(exr_headers), num_exr_headers, argv[1], &err);
  if (ret != 0) {
    fprintf(stderr, "Parse EXR err: %s\n", err);
    FreeEXRErrorMessage(err); // free's buffer for an error message
    return ret;
  }

  printf("Loaded %d part images\n", num_exr_headers);

  // 4. Access image data
  // `exr_image.images` will be filled when EXR is scanline format.
  // `exr_image.tiled` will be filled when EXR is tiled format.

  // 5. Free images
  for (int i =0; i < num_exr_headers; i++) {
    FreeEXRImage(&images.at(i));
  }

  // 6. Free headers.
  for (int i =0; i < num_exr_headers; i++) {
    FreeEXRHeader(exr_headers[i]);
    free(exr_headers[i]);
  }
  free(exr_headers);

Saving Scanline EXR file.

  // See `examples/rgbe2exr/` for more details.
  bool SaveEXR(const float* rgb, int width, int height, const char* outfilename) {

    EXRHeader header;
    InitEXRHeader(&header);

    EXRImage image;
    InitEXRImage(&image);

    image.num_channels = 3;

    std::vector<float> images[3];
    images[0].resize(width * height);
    images[1].resize(width * height);
    images[2].resize(width * height);

    // Split RGBRGBRGB... into R, G and B layer
    for (int i = 0; i < width * height; i++) {
      images[0][i] = rgb[3*i+0];
      images[1][i] = rgb[3*i+1];
      images[2][i] = rgb[3*i+2];
    }

    float* image_ptr[3];
    image_ptr[0] = &(images[2].at(0)); // B
    image_ptr[1] = &(images[1].at(0)); // G
    image_ptr[2] = &(images[0].at(0)); // R

    image.images = (unsigned char**)image_ptr;
    image.width = width;
    image.height = height;

    header.num_channels = 3;
    header.channels = (EXRChannelInfo *)malloc(sizeof(EXRChannelInfo) * header.num_channels);
    // Must be (A)BGR order, since most of EXR viewers expect this channel order.
    strncpy(header.channels[0].name, "B", 255); header.channels[0].name[strlen("B")] = '\0';
    strncpy(header.channels[1].name, "G", 255); header.channels[1].name[strlen("G")] = '\0';
    strncpy(header.channels[2].name, "R", 255); header.channels[2].name[strlen("R")] = '\0';

    header.pixel_types = (int *)malloc(sizeof(int) * header.num_channels);
    header.requested_pixel_types = (int *)malloc(sizeof(int) * header.num_channels);
    for (int i = 0; i < header.num_channels; i++) {
      header.pixel_types[i] = TINYEXR_PIXELTYPE_FLOAT; // pixel type of input image
      header.requested_pixel_types[i] = TINYEXR_PIXELTYPE_HALF; // pixel type of output image to be stored in .EXR
    }

    const char* err = NULL; // or nullptr in C++11 or later.
    int ret = SaveEXRImageToFile(&image, &header, outfilename, &err);
    if (ret != TINYEXR_SUCCESS) {
      fprintf(stderr, "Save EXR err: %s\n", err);
      FreeEXRErrorMessage(err); // free's buffer for an error message
      return ret;
    }
    printf("Saved exr file. [ %s ] \n", outfilename);

    free(rgb);

    free(header.channels);
    free(header.pixel_types);
    free(header.requested_pixel_types);

  }

Reading deep image EXR file. See example/deepview for actual usage.

  const char* input = "deepimage.exr";
  const char* err = NULL; // or nullptr
  DeepImage deepImage;

  int ret = LoadDeepEXR(&deepImage, input, &err);

  // access to each sample in the deep pixel.
  for (int y = 0; y < deepImage.height; y++) {
    int sampleNum = deepImage.offset_table[y][deepImage.width-1];
    for (int x = 0; x < deepImage.width-1; x++) {
      int s_start = deepImage.offset_table[y][x];
      int s_end   = deepImage.offset_table[y][x+1];
      if (s_start >= sampleNum) {
        continue;
      }
      s_end = (s_end < sampleNum) ? s_end : sampleNum;
      for (int s = s_start; s < s_end; s++) {
        float val = deepImage.image[depthChan][y][s];
        ...
      }
    }
  }

deepview

examples/deepview is simple deep image viewer in OpenGL.

DeepViewExample

TinyEXR extension

ZFP

NOTE

TinyEXR adds ZFP compression as an experimemtal support (Linux and MacOSX only).

ZFP only supports FLOAT format pixel, and its image width and height must be the multiple of 4, since ZFP compresses pixels with 4x4 pixel block.

Setup

Checkout zfp repo as an submodule.

$ git submodule update --init

Build

Then build ZFP

$ cd deps/ZFP
$ mkdir -p lib   # Create `lib` directory if not exist
$ make

Set 1 to TINYEXT_USE_ZFP define in tinyexr.h

Build your app with linking deps/ZFP/lib/libzfp.a

ZFP attribute

For ZFP EXR image, the following attribute must exist in its EXR image.

  • zfpCompressionType (uchar).
    • 0 = fixed rate compression
    • 1 = precision based variable rate compression
    • 2 = accuracy based variable rate compression

And the one of following attributes must exist in EXR, depending on the zfpCompressionType value.

  • zfpCompressionRate (double)
    • Specifies compression rate for fixed rate compression.
  • zfpCompressionPrecision (int32)
    • Specifies the number of bits for precision based variable rate compression.
  • zfpCompressionTolerance (double)
    • Specifies the tolerance value for accuracy based variable rate compression.

Note on ZFP compression.

At least ZFP code itself works well on big endian machine.

Unit tests

See test/unit directory.

TODO

Contribution is welcome!

  • Compression
    • B44?
    • B44A?
    • PIX24?
  • Custom attributes
    • Normal image (EXR 1.x)
    • Deep image (EXR 2.x)
  • JavaScript library (experimental, using Emscripten)
    • LoadEXRFromMemory
    • SaveMultiChannelEXR
    • Deep image save/load
  • Write from/to memory buffer.
    • Deep image save/load
  • Tile format.
    • Tile format with no LoD (load).
    • Tile format with LoD (load).
    • Tile format with no LoD (save).
    • Tile format with LoD (save).
  • Support for custom compression type.
    • zfp compression (Not in OpenEXR spec, though)
    • zstd?
  • Multi-channel.
  • Multi-part (EXR2.0)
    • Load multi-part image
    • Load multi-part deep image
  • Line order.
    • Increasing, decreasing (load)
    • Random?
    • Increasing, decreasing (save)
  • Pixel format (UINT, FLOAT).
    • UINT, FLOAT (load)
    • UINT, FLOAT (deep load)
    • UINT, FLOAT (save)
    • UINT, FLOAT (deep save)
  • Support for big endian machine.
    • Loading multi-part channel EXR
    • Saving multi-part channel EXR
    • Loading deep image
    • Saving deep image
  • Optimization
    • ISPC?
    • OpenMP multi-threading in EXR loading.
    • OpenMP multi-threading in EXR saving.
    • OpenMP multi-threading in deep image loading.
    • OpenMP multi-threading in deep image saving.

Python bindings

pytinyexr is available: https://pypi.org/project/pytinyexr/ (loading only as of 0.9.1)

Similar or related projects

License

3-clause BSD

tinyexr uses miniz, which is developed by Rich Geldreich [email protected], and licensed under public domain.

tinyexr tools uses stb, which is licensed under public domain: https://github.com/nothings/stb tinyexr uses some code from OpenEXR, which is licensed under 3-clause BSD license.

Author(s)

Syoyo Fujita ([email protected])

Contributor(s)

Comments
  • TinyEXR JavaScript version in a browser

    TinyEXR JavaScript version in a browser

    I've been trying to run JavaScript version provided in this repo in a browser, but I'm stuck on the step of converting image blob to a nodejs like Buffer. Please suggest

    Here is my code:

    <!DOCTYPE html>
    <html lang="en">
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
      <meta http-equiv="X-UA-Compatible" content="ie=edge">
      <title>TinyEXR Js</title>
      <script src="tinyexr_new.js"></script>
    </head>
    <body>
    </body>
    <script>
    
      var imgData;
      fetch("asakusa.exr")
      .then(function (response) {
        return response.blob();
      })
      .then(function (blob) {
    
        // TODO(Kirill):
        // Need to convert image blob to a nodejs like Buffer
    
        // here the image is a blob
        var data = new Uint8Array(buffer);
        console.log('Data length:', data.length);
    
        ParseEXRHeaderFromMemory = cwrap(
          'ParseEXRHeaderFromMemory', 'number', ['number', 'number', 'number']
        );
    
        LoadEXRFromMemory = cwrap(
          'LoadEXRFromMemory', 'number', ['number', 'number', 'string']
        );
    
        var widthPtr = _malloc(4);
        var widthHeap = new Uint8Array(HEAPU8.buffer, widthPtr, 4);
        var heightPtr = _malloc(4);
        var heightHeap = new Uint8Array(HEAPU8.buffer, heightPtr, 4);
        var ptr = _malloc(data.length)
        var dataHeap = new Uint8Array(HEAPU8.buffer, ptr, data.length);
        dataHeap.set(new Uint8Array(data.buffer))
    
        var ret  = ParseEXRHeaderFromMemory(widthHeap.byteOffset, heightHeap.byteOffset, dataHeap.byteOffset);
        console.log('Exr header:', ret);
    
        var width = (new Int32Array(widthHeap.buffer, widthHeap.byteOffset, 1))[0];
        var height = (new Int32Array(heightHeap.buffer, heightHeap.byteOffset, 1))[0];
        console.log('Width and height: ', width, height)
    
        var imgDataLen = width * height * 4 * 4;
        var img = _malloc(imgDataLen)
        var imgHeap = new Float32Array(HEAPU8.buffer, img, imgDataLen/4);
        ret = LoadEXRFromMemory(imgHeap.byteOffset, dataHeap.byteOffset, null)
    
        // Now imgHeap contains HDR image: float x RGBA x width x height
        console.log(imgHeap[0])
      });
    
    
    
    </script>
    </html>
    
    enhancement help wanted 
    opened by Kif11 19
  • PIZ decompression bug

    PIZ decompression bug

    I found a weird bug where reading an image with PIZ compression can cause artifacts, where line(s) of pixels that should be black instead have every second pixel's red channel set to a very high value. bug

    This only happens with PIZ compression, none of the others. It does not happen with all images. The position of the red lines depends on the image. But it is deterministic, so threading issues are unlikely. If there are multiple such lines, the distance between them is exactly 32 pixels.

    The problem is tied to specific files, the dots appear when reading the PIZ compressed file. Reading the same file with OpenEXR does not produce the red dots.

    To Reproduce

    1. Load EXR Image from the .zip below
    2. There will not be any red dots
    3. Save EXR again, as test.exr, making sure to use TINYEXR_COMPRESSIONTYPE_PIZ
    4. [optional] Read the new test.exr with OpenEXR - there will not be any red dots
    5. Read the new test.exr with tinyexr - the red dots appear
    6. [optional] Save again, the dots will now be visible in any viewer that uses OpenEXR

    RedDotsTest.zip

    Environment

    • OS: Windows, Ubuntu
    • Compiler: latest VS, gcc 9
    • OpenMP enabled
    bug 
    opened by pgrit 10
  • AddressSanitizer:  multiple heap-buffer-overflow in tinyexr::cpy2

    AddressSanitizer: multiple heap-buffer-overflow in tinyexr::cpy2

    POC files: https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6963_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6963_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6964_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6964_2.input.txt

    gdb backtrace: https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6963_1.gdb.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6964_1.gdb.txt

    help wanted invalid 
    opened by hongxuchen 10
  • Miniz/zlib

    Miniz/zlib

    I am already using Miniz in my project; I therefore want to do this to disable the embedded version of Miniz:

    #define TINYEXR_IMPLEMENTATION
    #define TINYEXR_USE_MINIZ 0
    #include "miniz.h"
    #include "tinyexr.h"
    

    However, tinyexr.h wants to include zlib.h:

    #if TINYEXR_USE_MINIZ
    #else
    #include "zlib.h"
    #endif
    

    My opinion is that it would be preferable to remove this dependency and leave it up to the user to include their zlib-compatible header (either zlib.h or miniz.h, as in my case) before including tinyexr.h.

    opened by john-chapman 10
  • Adds usage of memory-mapping where available to read files; fixes some handle leaks; improves C++98-compatibility

    Adds usage of memory-mapping where available to read files; fixes some handle leaks; improves C++98-compatibility

    Hi Syoyo! Thanks for making TinyEXR.

    During static analysis, we found a couple of places where file handles could be leaked (i.e. fclose() not called in some situations). While fixing these, I noticed that there were TODO items about adding memory-mapping (referenced in PR #182). In this pull request, I've tried to combine the solutions to these two topics:

    • Adds memory-mapping code for reading files
      • I've based this code off viewer.cc, with additional checks around error handling.
      • It includes code paths for Windows (it should work as early as Windows XP) and POSIX APIs. If neither is available, it falls back to C file I/O calls with additional error-checking (e.g. checking that ftell() succeeds - it's difficult, but possible, to get it to return a negative number!)
      • The code to memory-map a file is somewhat long, but moving the file I/O calls to a common place make TinyEXR shorter overall as a result.
    • Fixes some file handle leaks
      • For instance, if the file was shorter than kEXRVersionSize, calling ParseEXRVersionFromFile() would fail to call fclose() at https://github.com/syoyo/tinyexr/blob/2a3ffbfab2112d541aa464fd749c528533bef172/tinyexr.h#L8499-8500.
      • I've done this generally by moving file opening to a MemoryMappedFile object; constructing a MemoryMappedFile opens a file for memory mapping, and closes the handle whenever it is destroyed. This ensures file handles are always closed on all code paths. When saving, I've added fclose() calls to the other code paths.
    • Zero-initializes ChannelInfo in ReadChannelInfo - I noticed this left requested_pixel_type uninitialized.

    I've run the unit tests on Windows under Visual Studio 2017 and 2022, and on Ubuntu Linux on WSL2 using clang 12 and the latest version of the openexr-images repository. All 36 test cases pass on Windows; on Linux, I see some errors from UndefinedBehaviorSanitizer, though they don't seem to be due to these changes.

    I've only modified the code to read files here; if it would be good for MemoryMappedFile to also be used in the save paths, let me know and I'd be happy to modify it to support those! I could also modify ParseEXRVersionFromFile - with MemoryMappedFile, it becomes

    int ParseEXRVersionFromFile(EXRVersion *version, const char *filename) {
      if (filename == NULL) {
        return TINYEXR_ERROR_INVALID_ARGUMENT;
      }
    
      MemoryMappedFile file(filename);
      if (!file.valid()) {
        return TINYEXR_ERROR_CANT_OPEN_FILE;
      }
    
      if (file.size < tinyexr::kEXRVersionSize) {
        return TINYEXR_ERROR_INVALID_FILE;
      }
    
      return ParseEXRVersionFromMemory(version, file.data,
                                       tinyexr::kEXRVersionSize);
    }
    

    but on platforms where neither Windows nor POSIX APIs are available, it would read the full file when it only needs to read the first 8 bytes.

    Thanks again!

    opened by NeilBickford-NV 9
  • Integrating with OSS-Fuzz

    Integrating with OSS-Fuzz

    Greetings tinyexr developers and contributors,

    We’re reaching out because your project is an important part of the open source ecosystem, and we’d like to invite you to integrate with our fuzzing service, OSS-Fuzz. OSS-Fuzz is a free fuzzing infrastructure you can use to identify security vulnerabilities and stability bugs in your project. OSS-Fuzz will:

    • Continuously run at scale all the fuzzers you write.
    • Alert you when it finds issues.
    • Automatically close issues after they’ve been fixed by a commit.

    Many widely used open source projects like OpenSSL, FFmpeg, LibreOffice, and ImageMagick are fuzzing via OSS-Fuzz, which helps them find and remediate critical issues.

    Even though typical integrations can be done in < 100 LoC, we have a reward program in place which aims to recognize folks who are not just contributing to open source, but are also working hard to make it more secure.

    We want to stress that anyone who meets the eligibility criteria and integrates a project with OSS-Fuzz is eligible for a reward.

    We find you already have a fuzzing test folder and there exist some fuzzers. In this case, we can help you integrate your project into OSS-Fuzz. Later, when you add your fuzzers in your test folder, OSS-Fuzz will automatically run fuzzing test for you.

    If you're not interested in integrating with OSS-Fuzz, it would be helpful for us to understand why—lack of interest, lack of time, or something else—so we can better support projects like yours in the future.

    If we’ve missed your question in our FAQ, feel free to reply or reach out to us at [email protected].

    Thanks!

    Zhicheng and Tommy OSS-Fuzz Team

    opened by zchcai 9
  • AddressSanitizer: multiple heap-buffer-overflow in tinyexr::cpy4

    AddressSanitizer: multiple heap-buffer-overflow in tinyexr::cpy4

    POC files: https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6994_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6994_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6995_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6995_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6996_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6996_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6997_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6997_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7004_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7004_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7005_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7005_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7006_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7006_2.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7007_1.input.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7007_2.input.txt

    gdb backtrace: https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A6995_1.gdb.txt https://github.com/ntu-sec/pocs/blob/master/tinyexr-16aba30/crashes/hbo_tinyexr.h%3A7006_2.gdb.txt

    help wanted invalid 
    opened by hongxuchen 9
  • heap overflow in tinyexr::DecodePixelData

    heap overflow in tinyexr::DecodePixelData

    desc

    There is a heap based buffer overflow in tinyexr::DecodePixelData before 20220506 that could cause remote code execution depending on the usage of this program.

    asan output

    ==2363537==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000009210 at pc 0x000000563bd4 bp 0x7fffffffc4b0 sp 0x7fffffffc4a8
    READ of size 1 at 0x629000009210 thread T0
        #0 0x563bd3 in tinyexr::cpy4(float*, float const*) /tinyexr/./BUILD/tinyexr.h:759:12
        #1 0x563bd3 in tinyexr::DecodePixelData(unsigned char**, int const*, unsigned char const*, unsigned long, int, int, int, int, int, int, int, int, unsigned long, unsigned long, TEXRAttribute const*, unsigned long, TEXRChannelInfo const*, std::vector<unsigned long, std::allocator<unsigned long> > const&) /tinyexr/./BUILD/tinyexr.h:3593:13
        #2 0x505f79 in tinyexr::DecodeTiledPixelData(unsigned char**, int*, int*, int const*, unsigned char const*, unsigned long, int, int, int, int, int, int, int, int, unsigned long, unsigned long, TEXRAttribute const*, unsigned long, TEXRChannelInfo const*, std::vector<unsigned long, std::allocator<unsigned long> > const&) /tinyexr/./BUILD/tinyexr.h:4115:10
        #3 0x505f79 in tinyexr::DecodeTiledLevel(TEXRImage*, TEXRHeader const*, tinyexr::OffsetData const&, std::vector<unsigned long, std::allocator<unsigned long> > const&, int, unsigned char const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /tinyexr/./BUILD/tinyexr.h:4841:16
        #4 0x504abc in tinyexr::DecodeChunk(TEXRImage*, TEXRHeader const*, tinyexr::OffsetData const&, unsigned char const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /tinyexr/./BUILD/tinyexr.h:5015:19
        #5 0x519246 in tinyexr::DecodeEXRImage(TEXRImage*, TEXRHeader const*, unsigned char const*, unsigned char const*, unsigned long, char const**) /tinyexr/./BUILD/tinyexr.h:5756:15
        #6 0x519246 in LoadEXRImageFromMemory /tinyexr/./BUILD/tinyexr.h:6444:10
        #7 0x53f3bf in LLVMFuzzerTestOneInput /tinyexr/./SRC/test/fuzzer/fuzz.cc:20:9
        #8 0x4fbaad in fuzzfile(char*) /tinyexr/../../../harness/aflharness.cc:35:5
        #9 0x4fbc06 in main /tinyexr/../../../harness/aflharness.cc:52:13
        #10 0x7ffff7a51082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
        #11 0x41e65d in _start (/tinyexr/fuzzrun/harness+0x41e65d)
    
    0x629000009210 is located 0 bytes to the right of 16400-byte region [0x629000005200,0x629000009210)
    allocated by thread T0 here:
        #0 0x4f8c17 in operator new(unsigned long) /fuzz/fuzzdeps/llvm-project-11.0.0/compiler-rt/lib/asan/asan_new_delete.cpp:99:3
        #1 0x55b2b2 in __gnu_cxx::new_allocator<unsigned char>::allocate(unsigned long, void const*) /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/ext/new_allocator.h:114:27
        #2 0x55b2b2 in std::allocator_traits<std::allocator<unsigned char> >::allocate(std::allocator<unsigned char>&, unsigned long) /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/alloc_traits.h:443:20
        #3 0x55b2b2 in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_allocate(unsigned long) /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stl_vector.h:343:20
        #4 0x55b2b2 in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_create_storage(unsigned long) /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stl_vector.h:358:33
        #5 0x55b2b2 in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_Vector_base(unsigned long, std::allocator<unsigned char> const&) /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stl_vector.h:302:9
        #6 0x55b2b2 in std::vector<unsigned char, std::allocator<unsigned char> >::vector(unsigned long, std::allocator<unsigned char> const&) /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stl_vector.h:508:9
        #7 0x55b2b2 in tinyexr::DecodePixelData(unsigned char**, int const*, unsigned char const*, unsigned long, int, int, int, int, int, int, int, int, unsigned long, unsigned long, TEXRAttribute const*, unsigned long, TEXRChannelInfo const*, std::vector<unsigned long, std::allocator<unsigned long> > const&) /tinyexr/./BUILD/tinyexr.h:3484:32
        #8 0x505f79 in tinyexr::DecodeTiledPixelData(unsigned char**, int*, int*, int const*, unsigned char const*, unsigned long, int, int, int, int, int, int, int, int, unsigned long, unsigned long, TEXRAttribute const*, unsigned long, TEXRChannelInfo const*, std::vector<unsigned long, std::allocator<unsigned long> > const&) /tinyexr/./BUILD/tinyexr.h:4115:10
        #9 0x505f79 in tinyexr::DecodeTiledLevel(TEXRImage*, TEXRHeader const*, tinyexr::OffsetData const&, std::vector<unsigned long, std::allocator<unsigned long> > const&, int, unsigned char const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /tinyexr/./BUILD/tinyexr.h:4841:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /tinyexr/./BUILD/tinyexr.h:759:12 in tinyexr::cpy4(float*, float const*)
    Shadow bytes around the buggy address:
      0x0c527fff91f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c527fff9200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c527fff9210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c527fff9220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c527fff9230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c527fff9240: 00 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c527fff9250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c527fff9260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c527fff9270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c527fff9280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c527fff9290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==2363537==ABORTING
    

    reproduce

    • compile this project using address sanitizer
    • run ./test/fuzzer ./poc
    enhancement 
    opened by sleicasper 8
  • Get layer names, display RGBA channels from given layer

    Get layer names, display RGBA channels from given layer

    Hi, This is my attempt to handle loading channels by layer name (issue #53). It's different from original ImfChannelList.h implementation because I tried not to introduce new classes like iterator and such.

    I updated tinyexr.h library and exrview example. exrview prints out layer names and accepts layer name command line argument.

    There are certainly cases where the implementation can fail, like channels with names different from RGBA, or with number of channels in the layer less than 3 and so on.

    Please let me know what you think and thanks for review, Sergo.

    opened by usakhelo 8
  • LoadEXR/SaveEXR from/to memory

    LoadEXR/SaveEXR from/to memory

    Describe the issue While LoadEXR and SaveEXR are deprecated functionality, they are very useful is one wants to quickly put together applications. This is in the same vein as stb_image. It would be helpful I think to have this functionality not deprecated and add a simple to use SaveEXR to memory option. In fact, it would be great to have even simpler functions that have an API that is the same as stbi_load and stb_write.

    Expected behavior Three things:

    • Do not deprecate the simple-to-use interface
    • Add Load/Save from/to memory
    • Consider an even simpler interface that matches stb headers to make integration trivial.
    opened by xelatihy 7
  • Loading half data directly

    Loading half data directly

    Hi - thanks for all your work on this library. I'm working with @richardeakin to explore integrating it with Cinder. If I'm not misreading it, it looks like there's no way to load image data as half even when that is the format on disk. Is this something you'd be open to adding? Essentially we're trying to do a fp16 .exr -> OpenGL texture pipeline without any intermediate conversion to or from float.

    opened by andrewfb 7
  • Use wuffs for fast & secure ZIP/LZW decoding/encoding

    Use wuffs for fast & secure ZIP/LZW decoding/encoding

    Describe the issue

    wuffs is a fast, secure and portable algorithm library(zip, huffman decoding for LZW, etc)

    https://github.com/google/wuffs

    Currently TinyEXR uses codes from OpenEXR, which is not optimized, difficult to interpret code(hard to apply fixes found by fuzzers), and also not secure(although various fixes already added in TinyEXR thanks to fuzzer)

    replacing such code part with wuffs would make TinyEXR more faster, secure and portable.

    This change also open the possiblity to relicense TinyEXR to MIT or Apache 2.0 by removing OpenEXR code part. (We also need to rewrite PIZ and other pixel encodings though)

    To Reproduce

    N/A

    Expected behavior

    TinyEXR becode faster, secure and portable.

    Environment

    N/A

    enhancement 
    opened by syoyo 0
  • [TODO] Support nested layer name

    [TODO] Support nested layer name

    Describe the issue

    https://openexr.readthedocs.io/en/latest/ReadingAndWritingImageFiles.html#layers

    Layer can be nested, but current TinyEXR's ChannelsInLayer API does not support nested layers.

    To Reproduce

    EXR with nested layer name. e.g. "diffuse.left.R", "diffuse.right.G"

    Expected behavior

    Support nested layer in some way.

    Environment

    N/A

    enhancement 
    opened by syoyo 0
  • [Enhancement] Support spectral layout

    [Enhancement] Support spectral layout

    Describe the issue

    Support spectral image layout proposed by

    An OpenEXR Layout for Spectral Images http://jcgt.org/published/0010/03/01/

    Spectral images are getting popular, so built-in spectral layout support in TinyEXR is recommended.

    Environment N/A

    enhancement 
    opened by syoyo 3
Owner
Syoyo Fujita
No ray tracing no life.
Syoyo Fujita
C++ trainable detection library based on libtorch (or pytorch c++). Yolov4 tiny provided now.

C++ Library with Neural Networks for Object Detection Based on LibTorch. ?? Libtorch Tutorials ?? Visit Libtorch Tutorials Project if you want to know

null 62 Dec 29, 2022
Tiny library for C++ enum introspection and more!

#smart_enum Tiny library for C++ enum introspection... and more! (Sorry for this readme being incomplete, I'm working on updating it. For now, please

Jarda 32 Jan 19, 2022
A tiny C++11 library for reading BVH motion capture data

bvh11 A tiny C++11 library for reading (and writing) BVH motion capture data. Dependencies C++11 standard library Eigen 3 http://eigen.tuxfamily.org/

Yuki Koyama 33 Dec 19, 2022
a generic C++ library for image analysis

VIGRA Computer Vision Library Copyright 1998-2013 by Ullrich Koethe This file is part of the VIGRA computer vision library. You may use,

Ullrich Koethe 378 Dec 30, 2022
A easy-to-use image processing library accelerated with CUDA on GPU.

gpucv Have you used OpenCV on your CPU, and wanted to run it on GPU. Did you try installing OpenCV and get frustrated with its installation. Fret not

shrikumaran pb 4 Aug 14, 2021
Simple C++ one-header library for the creation of animated GIFs from image data.

gif-h This one-header library offers a simple, very limited way to create animated GIFs directly in code. Those looking for particular cleverness are

Charlie Tangora 423 Dec 26, 2022
Pipy is a tiny, high performance, highly stable, programmable proxy.

Pipy Pipy is a tiny, high performance, highly stable, programmable proxy. Written in C++, built on top of Asio asynchronous I/O library, Pipy is extre

null 539 Dec 28, 2022
Training and fine-tuning YOLOv4 Tiny on custom object detection dataset for Taiwanese traffic

Object Detection on Taiwanese Traffic using YOLOv4 Tiny Exploration of YOLOv4 Tiny on custom Taiwanese traffic dataset Trained and tested AlexeyAB's D

Andrew Chen 5 Dec 14, 2022
YOLOV4 tiny + lane detection on Android with 8 FPS!

YOLOV4 Tiny + Ultra fast lane detection on Android with 8 FPS! Tested with HONOR 20PRO Kirin 980

yq-pan 3 Dec 28, 2022
In this tutorial, we will use machine learning to build a gesture recognition system that runs on a tiny microcontroller, the RP2040.

Pico-Motion-Recognition This Repository has the code used on the 2 parts tutorial TinyML - Motion Recognition Using Raspberry Pi Pico The first part i

Marcelo Rovai 19 Nov 3, 2022
Tiny CUDA Neural Networks

This is a small, self-contained framework for training and querying neural networks. Most notably, it contains a lightning fast "fully fused" multi-layer perceptron as well as support for various advanced input encodings, losses, and optimizers.

NVIDIA Research Projects 1.9k Jan 7, 2023
Minctest - tiny unit testing framework for ANSI C

Minctest Minctest is a very minimal unit-testing "framework" written in ANSI C and implemented in a single header file. It's handy when you want some

Lewis Van Winkle 47 Oct 20, 2022
Video, Image and GIF upscale/enlarge(Super-Resolution) and Video frame interpolation. Achieved with Waifu2x, SRMD, RealSR, Anime4K, RIFE, CAIN, DAIN and ACNet.

Video, Image and GIF upscale/enlarge(Super-Resolution) and Video frame interpolation. Achieved with Waifu2x, SRMD, RealSR, Anime4K, RIFE, CAIN, DAIN and ACNet.

Aaron Feng 8.7k Dec 31, 2022
Super Mario Remake using C++, SFML, and Image Processing which was a project for Structure Programming Course, 1st Year

Super Mario Remake We use : C++ in OOP concepts SFML for game animations and sound effects. Image processing (Tensorflow and openCV) to add additional

Omar Elshopky 5 Dec 11, 2022
The code implemented in ROS projects a point cloud obtained by a Velodyne VLP16 3D-Lidar sensor on an image from an RGB camera.

PointCloud on Image The code implemented in ROS projects a point cloud obtained by a Velodyne VLP16 3D-Lidar sensor on an image from an RGB camera. Th

Edison Velasco Sánchez 5 Aug 12, 2022
NVIDIA Texture Tools samples for compression, image processing, and decompression.

NVTT 3 Samples This repository contains a number of samples showing how to use NVTT 3, a GPU-accelerated texture compression and image processing libr

NVIDIA DesignWorks Samples 33 Dec 20, 2022
NVIDIA Image Scaling SDK

NVIDIA Image Scaling SDK v1.0 The MIT License(MIT) Copyright(c) 2021 NVIDIA CORPORATION & AFFILIATES. All rights reserved. Permission is hereby grante

NVIDIA GameWorks 394 Dec 30, 2022
Using image classification with ConvMixer

Japanese Handwriting Classification with Fragment Shaders NOTE: This was built and tested with Unity 2019.4.31f1 using built-in render pipeline, there

null 11 Nov 22, 2022
NCNN implementation of Real-ESRGAN. Real-ESRGAN aims at developing Practical Algorithms for General Image Restoration.

Real-ESRGAN ncnn Vulkan This project is the ncnn implementation of Real-ESRGAN. Real-ESRGAN ncnn Vulkan heavily borrows from realsr-ncnn-vulkan. Many

Xintao 602 Jan 6, 2023