Imagesharp: Error on load image: Header Size value '124' is not valid

Created on 21 Jul 2017  路  9Comments  路  Source: SixLabors/ImageSharp

Prerequisites

  • [x ] I have written a descriptive issue title
  • [x ] I have verified that I am running the latest version of ImageSharp
  • [x ] I have verified if the problem exist in both DEBUG and RELEASE mode
  • [x ] I have searched open and closed issues to ensure it has not already been reported

Description

Hi I am trying to resize an image: http://primanagerstoragedev.s3-website-us-east-1.amazonaws.com/17c095f0-06e5-4a06-b1cd-a7b70098c2f3

When I load the image I get an exception: Header Size value '124' is not valid.

Can you help me ?

Steps to Reproduce

Image image = Image.Load(@"PATH TO IMAGE")

System Configuration

Every environment.

  • ImageSharp version:
    1.0.0-alpha9-00171
    1.0.0-alpha9-00173
bug bmp

All 9 comments

@deliotomaz this image is actually a BMP with an incorrect extension. Image.Load("PATH") enforces to use the decoder that belongs to the given extension, so if you are not sure about it's correctness, use Image.Load(Stream) instead!

@JimBobSquarePants should we close this issue, or should we invent some fancy logic for cases like this?

@antonfirsov I don't see any reason why we can't actually use our IImageFormatDetector API to correctly determine and assign the decoder. Shouldn't need to be too fancy, we'll already have a filestream and we can read it, assign, and reset the stream.

@JimBobSquarePants I think the expected behavior is not trivial, we have several options here:

  1. Use the decoder that belongs to the extension, throw if it's not correct (that's what we do now).
  2. Ignore the file extension, use the real decoder that belongs to the header. (What if the user actually does want to notice this?)
  3. Throw an exception that the format does not belong to the extension. (Maybe too paranoid.)

Everything I've tested against on a Windows box (Photos, Paint.Net, Paint, Paint3D) will load that image even though it thinks it's a jpeg (details still says jpeg)

That for me is enough to say let's just load it.

@antonfirsov Thnaks a lot.
I will do it.

@JimBobSquarePants , Can I suggest a parameter on load method like 'AutoDetect(true/false)'. This can be useful when the user needs that the file has a specific format. So if AutoDetect is false the API throw an exception.

Best

We should just load it. I don't see the point of the AutoDetect if a user wants to ensure the loaded format is what they expected then they can just use the overload of Image.Load(...) that has the image format returned.

I've just taken a fresh look over the code and @antonfirsov was wrong we don't do any detection of file format based on the file extension as we always do format detection based on file headers, I'm guessing we actually have a bug in our bmp decoder (or we are too sensitive to technically corrupted images)

Done some more investigation this BMP is using BITMAPV5HEADER DIB Header format. We currently only support BITMAPCOREHEADER and BITMAPINFOHEADER formats.

What we should be doing is always read the BITMAPCOREHEADER part (or the largest format we can read) as all others are just extensions on top of that format and just skip the remaining bytes so that at least we open the file.

Details gleamed from https://en.wikipedia.org/wiki/BMP_file_format

missread that it should be BITMAPINFOHEADER. If the header size > 40 then just read as BITMAPINFOHEADER to get it to not fail

Was this page helpful?
0 / 5 - 0 ratings