SixLabors
Does Jpeg format need comment marker support?
Discussed in https://github.com/SixLabors/ImageSharp/discussions/2061
Originally posted by br3aker March 13, 2022 Current jpeg implementation lacks of COM marker support, does it need to support it? Should be easy to implement as this marker is just an array of bytes - itu spec leaves 'interpretation to the application', decoding API should not try to decode it as it can be anything from literal byte array to some weird text encoding.
So it can be a 'good first issue' or I can work on it a bit later.
any updates on this? I was looking to use it from ImageSharp (as I do use it for bunch of other stuff)
I think this place is better for a small guide than that discussion @prabhavmehra.
First of all, COM marker is already hooked up in the decoding loop here
The only thing left to do is to actually parse given stream which is skipped right now using this line: stream.Skip(markerContentByteSize);.
And the final question is where to store parsed results. Results should be saved into JpegMetadata class. AFAIR we decided to implement it as an ICollection<char[]> property backed by a List<char[]>.
The only thing that bothers me is what should we do if there are no COM markers in given JPEG, leave new property as null or an empty ICollection...
I would like to add in here that I feel reading COM markers should be explicitly opt-in. (could be exposed as a new property on JpegDecoderOptions)
The writing side of things however can be left as implicitly opt-in by the fact we have the metadata set or not.
I feel it needs to be opt-in for a couple of reasons.
- It feels like the usage would be relatively niche for our general users.
- We don't want to be penalizing general users/usage having to keep hold of more memory when most users would never want it.
- It would now cause larger file outputs as we would start currying the data in & then out for those users that don't even know this thing exists.
How about a nullable Memory
?
Jpeg can have many COM markers so either List<Memory<char>> or List<char[]> but what's the profit using Memory<T> here? :)
@tocsoft extra configuration seems fair.
Mostly API consistency, we use that type for color pallet pallet metadata.
Mostly API consistency, we use that type for color pallet pallet metadata.
Fair enough, I have nothing against nullable ICollection<Memory<char>> then :)