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

Q: in-memory JPEGs #3

Open
akavel opened this issue Mar 21, 2021 · 3 comments
Open

Q: in-memory JPEGs #3

akavel opened this issue Mar 21, 2021 · 3 comments

Comments

@akavel
Copy link
Contributor

akavel commented Mar 21, 2021

Hi! I started using metar as an Exif parser for a hobby project for photo backups management. However, my plan for the project is to support IPFS backups soon. For this, I anticipate needing to support parsing Exif from in-memory buffers with JPEG data, not just from on-disk Files. I'd be ok with trying to add such feature to metar myself, and based on your preferences, trying to upstream it back to you, or just keeping it in a fork. The challenge I'm having, however, is that I'm not really sure how to best add such a feature to metar's library interface and implementation in Nim. Would you by chance have some ideas how you think I might try and approach it best? If you were interested in such a feature (regardless if that is currently true or not), do you think there's some shape you would possibly prefer it to look like?

Thanks,
/M.

@flenniken
Copy link
Owner

Mateusz,

Thanks for your interest in Metar. The IPFS project looks cool and has a lot of potential.

Here is the outline I think you should follow for adding in memory buffer support to metar.

Metar's current public interface in Nim:

  • proc readMetadataJson*(filename: string): string
  • proc readMetadata*(filename: string): string
  • proc keyName*(readerName: string, section: string, key: string): string
  • proc getVersion*(): string

Add the following procedure to the public interface:

  • readMetadataBuffer*(name: string, buffer: openArray[uint8]): string
    Return json metadata found in the memory buffer containing image file bytes. The name parameter is returned in the meta section's "filename" field.

For python, the new public method would be called:

  • read_metadata_buffer(name, bytes)

Private interface changes:

Both the existing readMetadata, readMetadataJson procedures and the new readMetadataBuffer procedure change to call the new readMetadataStream procedure.

  • readMetadataStream(name: string, stream: Stream): string

All low level procedures that take a file parameter change to take a stream parameter.

Steve

@akavel
Copy link
Contributor Author

akavel commented Mar 26, 2021

Steve,

Thank you for the suggestions; in particular, I didn't realize that Stream has a setPosition method - with this existing, at first glance it looks like it should hopefully be fairly easy to do for me!

Now, just regarding the python new public method: I never did this; does it mean just that I'd need to add an {.exportpy: "read_metadata_buffer".} annotation, or is there something more I'd need to do?

edit: Also, starting to work on this, I've realized that in my project, I'm actually using the getMetadata procedure (as it gives me a fully typed, structured object with a really useful set of methods). What would be your suggested approach to changing it? Would you prefer if I tried adding a new getMetadataStream, and modifying getMetadata to be just a thin wrapper over it, or if just didn't care about that and modified getMetadata to take a stream as its argument?

Thanks,
/M.

@flenniken
Copy link
Owner

flenniken commented Mar 27, 2021 via email

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

No branches or pull requests

2 participants