Freeimage library does not write EXR files

Bug #1614266 reported by Milos Hasan
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
freeimage (Ubuntu)
Fix Committed
Undecided
Unassigned

Bug Description

Writing an EXR file through Freeimage (3.17.0+ds1-2) on Xubuntu 16.04 results in a file with zero bytes, while a corresponding HDR file is written correctly. On 14.04 both images are written correctly. Here is a minimal example writing both formats and reproducing the problem:

// compile with g++ -lfreeimage test.cpp
#include <FreeImage.h>
#include <iostream>

struct Rgb
{
 float r, g, b;
 Rgb() {}
 Rgb(float x, float y, float z): r(x), g(y), b(z) {}
};

int main()
{
 const int n = 512;
 Rgb img[n * n];

 for (int i = 0; i < n; i++)
  for (int j = 0; j < n; j++)
   img[i*n + j] = Rgb((float) i / n, (float) j / n, 0.0f);

 FIBITMAP* pBitmap;
 pBitmap = FreeImage_AllocateT(FIT_RGBF, n, n);

 unsigned int nPitch = FreeImage_GetPitch(pBitmap);
 BYTE *pBits = reinterpret_cast<BYTE*>(FreeImage_GetBits(pBitmap));

 float *buf = reinterpret_cast<float*>(img);
 unsigned int i = 0;
 for (int y = 0; y < n; ++y)
 {
  float *pPixel = reinterpret_cast<float*>(pBits);
  for (int x = 0; x < n; ++x)
  {
   pPixel[0] = buf[i++];
   pPixel[1] = buf[i++];
   pPixel[2] = buf[i++];
   pPixel += 3;
  }
  pBits += nPitch;
 }

 if (!FreeImage_Save(FIF_EXR, pBitmap, "test.exr", EXR_DEFAULT)) std::cout << "EXR error\n";
 if (!FreeImage_Save(FIF_HDR, pBitmap, "test.hdr")) std::cout << "HDR error\n";
 FreeImage_Unload(pBitmap);
 return 0;
}

Tags: patch
Revision history for this message
Ghislain Vaillant (ghisvail) wrote :

Hi Milos,

Could you try building FreeImage 3.17.0 from source, run your example on it and report whether the same problem occurs.

The major difference between the packaged FreeImage and the source one is that the latter embeds its own dependencies whereas the former is (quite heavily) patched to use the system libraries. Consequently, we need to identify first whether the issue comes from the upstream code or the packaged version.

Cheers,
Ghis

Revision history for this message
Milos Hasan (milos-hasan) wrote :

Hi Ghis,

yes, we confirmed that it works correctly with FreeImage 3.17.0 built from source. So the bug is specific to Ubuntu 16.04 packaging.

(Note, the source did not build out of the box, there was some trivial bug with raw string delimiters that we had to manually patch.)

Hope this helps.

Thanks,
Milos

Revision history for this message
Ghislain Vaillant (ghisvail) wrote :

> (Note, the source did not build out of the box, there was some trivial bug with raw string delimiters that we had to manually patch.)

Could you forward the said patch please?

Revision history for this message
Milos Hasan (milos-hasan) wrote :

Hi Ghis,

sure, the patch is below, but note: this only patches the build of FreeImage 3.17.0 *from source*.

The original bug I reported above is that the *packaged* version FreeImage cannot write EXRs. That bug still exists and I have no idea how to fix it. For now our team has to resort to building FreeImage from source.

The patch should be applied to this source package:

sha1:
6752c83798c2f81dee71a2e8bb11657068672669 FreeImage3170.zip

Thanks,
Milos

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "FreeImage3170-ubuntu.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Ghislain Vaillant (ghisvail) wrote :
Revision history for this message
Milos Hasan (milos-hasan) wrote :

Yes, it appears to be the same bug. It's the FIF_EXR constant that's wrong.

A temporary workaround is to do this:

FREE_IMAGE_FORMAT exrFormat = FreeImage_GetFIFFromFilename("dummy.exr");

Then using exrFormat in place of FIF_EXR make the problem disappear.

Revision history for this message
Ghislain Vaillant (ghisvail) wrote :

The bug should be fixed in freeimage/3.17.0+ds1-4

Revision history for this message
Milos Hasan (milos-hasan) wrote :

I guess you meant the updated Ubuntu package based on freeimage/3.17.0+ds1-4, right? When is it going to be available?

Revision history for this message
Ghislain Vaillant (ghisvail) wrote :

It has already transitioned to the current dev version of Ubuntu. So, the next stable version (17.04) should have it.

Ghis

Revision history for this message
Milos Hasan (milos-hasan) wrote :

Any chance it will ever be backported to 16.04? I know this may not be your responsibility; just curious...

Revision history for this message
Ghislain Vaillant (ghisvail) wrote :

You may request a SRU [1] and motivate it in terms of the regressions you have observed. Another solution is requesting a backport [2] or build the package yourself [3].

[1] https://wiki.ubuntu.com/StableReleaseUpdates
[2] https://help.ubuntu.com/community/UbuntuBackports
[3] https://wiki.debian.org/BuildingTutorial

Revision history for this message
Ghislain Vaillant (ghisvail) wrote :

Fixed in freeimage/3.17.0+ds1-5

Changed in freeimage (Ubuntu):
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.