Repository navigation
Does Jpeg format need comment marker support? #2067
Description
Activity
any updates on this? I was looking to use it from ImageSharp (as I do use it for bunch of other stuff)
No changes, happy to accept contributions though!
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 aList<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...
How about a nullable
Memory<char>?I would like to add in here that I feel reading
COMmarkers should be explicitly opt-in. (could be exposed as a new property onJpegDecoderOptions)
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.
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 :)This was added in #2641
Discussed in #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.