Writing only?

[ziriax]

First of all thanks for this great library! This must have been a lot of tedious work.

I'm currently using a modified version of you library to add EXIF metadata to a newly generated JPEG file, so not an existing file.

Would you consider a PR for this?

Or do you thing that first saving a JPEG to a file, and then using your ImageFile to read/modify/write the metadata is the best approach?

I'm currently using a stream proxy to insert metadata on the fly while SkiaSharp is encoding the JPEG, because Skia doesn't have support for embedding metadata.

I wanted to avoid file IO as much as possible so the JPEG file can be transmitted to any stream without intermediate storage or excessive memory buffering.

[oozcitak]

Thank you for the comments. There are already FromStream methods, so you should be able to avoid touching the disk. Isn't this what you are after? Can you describe some more what your modified version does?

[ziriax]

Thanks for the fast reply.

Yes, but you copy the full JPEG to a intermediate MemoryStream, even the SOS and other segments that contain compressed image data.

I'm trying to achieve single pass metadata encoding. We run everything in the cloud, and we process huge JPEG files, so we prefer to avoid using too much RAM or doing redundant file IO.

To allow using the library with any JPEG encoder that writes to a stream, I'm writing a proxy that intercepts the stream data being written. It will replace or insert the metadata segments on the fly.

Maybe such a proxy could be part of this library? It makes writing to the stream a tiny bit slower, but avoids redundant RAM and IO.

[oozcitak]

To allow using the library with any JPEG encoder that writes to a stream, I'm writing a proxy that intercepts the stream data being written. It will replace or insert the metadata segments on the fly.

So you sniff the stream chunks to catch the Exif App1 header and insert your own metadata? That's ingenious. I'm definitely interested in a PR. Thanks in advance.

[ziriax]

Yes, exactly, a stream sniffer :-)

It could be extended to insert/patch any segment, on the fly.

BTW: do you have any good references about the required order of the segments in a JPEG file?

On Wed, 1 Jul 2020, 12:51 Ozgur Ozcitak, notifications@github.com wrote:

To allow using the library with any JPEG encoder that writes to a stream, I'm writing a proxy that intercepts the stream data being written. It will replace or insert the metadata segments on the fly.

So you sniff the stream chunks to catch the Exif App1 header and insert your own metadata? That's ingenious. I'm definitely interested in a PR. Thanks in advance.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/oozcitak/exiflibrary/issues/71#issuecomment-652346744, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASHK33CE44JBYNK2WQ5WXTRZMIJLANCNFSM4ONGKMBA .

[oozcitak]

BTW: do you have any good references about the required order of the segments in a JPEG file?

It is common for the APP1 section to be right after the start-of-image marker. The Exif spec says:

4.5.4 Basic Structure of JPEG Compressed Data Compressed data files are recorded in conformance with the JPEG DCT format specified in ISO/IEC 10918-1, with the Application Market Segment (APP1) inserted. APP1 is recorded immediately after the SOI marker indicating the beginning of the file (see Figure 6). Multiple APP2 may be recorded as necessary, starting immediately after APP1. APPn other than APP1 and APP2 or COM segments are not used by Exif. However Exif readers should be designed skip over unknown APPn and COM.

[ziriax]

Thanks for that. Wikipedia mentions that most software inserts both an APP0 and APP1 segment, directly after the SOI. I guess APP0 should come before APP1?

https://en.m.wikipedia.org/wiki/JPEG_File_Interchange_Format#Compatibility

[oozcitak]

Right, JFIF APP0 should come first.