You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Does Jpeg format need comment marker support? #2067
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.
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.
Activity
prabhavmehra commentedon Oct 24, 2023
any updates on this? I was looking to use it from ImageSharp (as I do use it for bunch of other stuff)
JimBobSquarePants commentedon Oct 25, 2023
No changes, happy to accept contributions though!
br3aker commentedon Oct 25, 2023
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...
JimBobSquarePants commentedon Oct 25, 2023
How about a nullable
Memory<char>?tocsoft commentedon Oct 25, 2023
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.
br3aker commentedon Oct 26, 2023
Jpeg can have many COM markers so either
List<Memory<char>>orList<char[]>but what's the profit usingMemory<T>here? :)@tocsoft extra configuration seems fair.
JimBobSquarePants commentedon Oct 26, 2023
Mostly API consistency, we use that type for color pallet pallet metadata.
br3aker commentedon Oct 26, 2023
Fair enough, I have nothing against nullable
ICollection<Memory<char>>then :)JimBobSquarePants commentedon Jul 31, 2024
This was added in #2641