I'm still using a version I pulled from May/2016, as I have not yet updated to .NET Core V1 (still using RC1, Update 2).. anyway, I plan to update, but cringing on it at the moment.
However, I have run across a JPG type that is throwing this ImageFormatException "Too many components".
I'm waiting to get a hold of a copy of the image for testing now.. but just wanted to ask how rare does this occur?
Could exporting the image with a different software package (like Photoshop) make a difference on the resulting JPG image?
It's probably CMYK. The current jpeg decoder doesn't support that but the original Go decoder we have ported does. Sadly I can't get my head around Go at all so I'm at a loss to convert it.
The expert on the manner is @mweber26 who kindly ported the code across. I have done some further work in my Core-Flava branch to handle JFIF headers better but CMYK support is still missing. Perhaps once Flava becomes the main branch we can collaborate add the missing functionality?
Thanks m8, I'm still waiting on getting a hold of the image >.<, I'll post back here once I get it and take a looksie.
Post the image here and I'll take a look at it.
Thanks @mweber26
@mweber26 ... if I can ever get them to send it! >.<
I'm 99% sure though that @JimBobSquarePants was spot on... based on the sketchy server logs I maintained (only dumped e.Messages on the exceptions), I generated a few CMYK JPG images in Photoshop and sure enough, "Too many components" was being thrown.
I will still post the image(s) that they send me though...
That's everything merged into the Core branch now so once we have a test image we are good to go.

Hi @mweber26 This image should be CMYK for debugging against. Could you have a wee look when you can please?
I will try to look at fixing this, but it looks like you guys have moved on to .Net core and I don't use that (under linux and mac). So I can't get the current master to compile. I will try to fix under an older version and get a diff.
Like I said -- I can't really make a pull request since I can't compile the master branch. But here is the diff from an old revision to enable CMYK (4 components)
https://github.com/mweber26/ImageProcessor/commit/dfabf30fa872444cff7b0f427850b031190461e1
That's absolutely brilliant @mweber26 Thanks for your help!
I was able to easily translate your work to a solution I could include it. There's been a lot of changes in the repo since you last looked.
I dunno what the tooling is like on linux and mac for .NET Core as it stands. That's our target now as it means much greater visibility
No problem. I understand. The tooling for .Net Core on linux and mac is very good (I've looked at it before). We just haven't transitioned to it at our company since we have third party libraries that have not made the transition.
I tried to compile Core on standard .net mono and the thing that was incompatible was the System.Runtime.CompilerServices.Unsafe class (from PixelAccessor), which only exists in .net core. There could be a way to #if for the two versions. If we ever need the new features, I can look into that solution.
Yeah, there's a lot of stuff still to make the transition. We're pioneers here!
I'm very surprised that wasn't able to compile. The support matrix seems quite large according to nuget, I actually thought it would be complete given that it is a single class made up of IL.
Unfortunately no way around it just now. An alternative would have required multiple classes to cater for each IPackedVector<T> implementation which gets messy fast.
Hello, I'm using last library version 2.5.3, I did a little test just opening a JPG image in CMYK with ImageFactory and then just saving to check if preserve colours, comparing both original and new it is noticiable difference in colours. Is there a way to preserve the original colours?. Thanks.
I'm afraid not. I'm limited by the System.Drawing decoder. We're working on adding ICC profile support to ImageSharp though.
Most helpful comment
Post the image here and I'll take a look at it.