search

imazen / resizer

The official repository for ImageResizer
http://imageresizing.net/
Other
569 stars 172 forks source link

FreeImage pipeline fails to parse /Samples/sample.tif #70

Closed lilith closed 10 years ago

lilith commented 10 years ago

It appears this issue is within FreeImage itself, but I haven't much time to do a full debug.

We're using a custom build of FreeImage against libjpeg-turbo.

JaredReisinger commented 10 years ago

The 'resizer' repo only has the binaries for FreeImage, correct? Do you have the sources from which you built the DLL, or should I re-fetch 3.15.1? Alternatively, FreeImage is now at 3.15.4, and there have been TIFF-related fixes (which might fix this, can't know without trying):

... and the libTIFF used has been updated as well.

Unless you've had reports of this happening in the wild (that is, if this is a "only seems to happen with this one sample file" issue), I'll probably put this on the back-burner and focus on the other issues/enhancements first.

lilith commented 10 years ago

Could you generate a few .tiff files and see if it works with any .tiff files? Due to low usage this might have gone unnoticed.

lilith commented 10 years ago

I just got a clarification back from the customer - they downloaded FreeImage 3.15.4.0 separately originally, and used downloadNativeDependencies="true" only recently, which is when the issue happened. So upgrading to a newer version should fix it. We generally get a custom build that uses 'libjpeg-turbo' without metadata (which is much, much faster), but we can resume that practice later.

For now, let's test against the latest version of FreeImage, and then upload it for downloadNativeDependencies use.

JaredReisinger commented 10 years ago

Upgrading to 3.15.4.0 seems to fix the issue. The existing "Native.xml" for the FreeImage plugin lists freeimage/3.15.4-custom-nometa in the path, but it's not really 3.15.4... so I'm not sure what's going on there. I grabbed the 3.15.4-win32 ZIP from the FreeImage site and used to replace everything under Plugins\Libs\FreeImage. It looked to me like you renamed the .NET wrapper project from "Library.csproj" (what were they thinking!?) to "WrapperFreeImage.NET.csproj". I also rolled back the wrapper's dependencies from .NET 3.5 to 2.0. Oddly, the wrapper source in 3.15.4 claims that the wrapper is still version 3.15.1.

Then, I manually copied the native binary into the _PluginTestingApp\bin directory and fiddled the FreeImage "native.xml" file to expect the new file's byte count. That done, the test site shows FreeImage-decoded TIFF images just fine!

Is the wholesale replacement of Plugins\Libs\FreeImage with the content of the new ZIP the way you manage the external dependency? Other than the native.xml/cloudfront update, which I don't think I can do, nothing else seems to refer to the native DLL. Should I go ahead and commit the 3.15.4 binaries/wrappers so that you can push the binary to the cloud (and then the plugin's native.xml can be updated)?

lilith commented 10 years ago

I've uploaded 3.16 and updated Native.xml. This will be fixed in the next release.