Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does Jpeg format need comment marker support? #2067

Open
JimBobSquarePants opened this issue Mar 17, 2022 Discussed in #2061 · 8 comments
Open

Does Jpeg format need comment marker support? #2067

JimBobSquarePants opened this issue Mar 17, 2022 Discussed in #2061 · 8 comments

Comments

@JimBobSquarePants
Copy link
Member

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.

@prabhavmehra
Copy link

prabhavmehra commented 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
Copy link
Member Author

No changes, happy to accept contributions though!

@br3aker
Copy link
Contributor

br3aker commented 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 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...

@JimBobSquarePants
Copy link
Member Author

How about a nullable Memory<char>?

@tocsoft
Copy link
Member

tocsoft commented Oct 25, 2023

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.

  1. It feels like the usage would be relatively niche for our general users.
  2. We don't want to be penalizing general users/usage having to keep hold of more memory when most users would never want it.
  3. 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.

@br3aker
Copy link
Contributor

br3aker commented Oct 26, 2023

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.

@JimBobSquarePants
Copy link
Member Author

Mostly API consistency, we use that type for color pallet pallet metadata.

@br3aker
Copy link
Contributor

br3aker commented Oct 26, 2023

Mostly API consistency, we use that type for color pallet pallet metadata.

Fair enough, I have nothing against nullable ICollection<Memory<char>> then :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants