JPEG encoder and EXIF orientation

[Peter Verswyvelen]

Skia's JPEG decoder seems to handle the embedded EXIF orientation, but the encoder doesn't have support for writing the orientation. Skia calls this the SkEncodedOrigin.

Is this by design?

[Mike Klein]

Nope, the encoders just don't really get any attention.

On Mon, Jun 29, 2020 at 5:57 PM Peter Verswyvelen <bug...@gmail.com> wrote:

Skia's JPEG decoder seems to handle the embedded EXIF orientation, but the encoder doesn't have support for writing the orientation. Skia calls this the SkEncodedOrigin.

Is this by design?

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/4ea84d85-df2f-42c4-b77a-47a414064fe0o%40googlegroups.com.

[Peter Verswyvelen]

Would a PR be accepted for encoding this and some other JPEG metadata properties?

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAD%3DHvMuVVcojQ_Vvfp_U0xGsQ0jGzyMwEQ%2B_uK09ZDU%3DONr_ww%40mail.gmail.com.

[Brian Osman]

I think so. Even though it's changes to public API, any new options in SkJpegEncoder::Options (with defaults that preserve existing behavior) are pretty low impact.

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAOo4A_9N8pK0n5GG0NUJrqK%3DUnvraPBECZRwmCZ3jMNLr6ryOA%40mail.gmail.com.

[Peter Verswyvelen]

As a first step, what would be very easy to add is a hook that allows parsing any metadata segments encountered during decoding, and an optional byte vector of metadata segments to insert when encoding. It is then up to the developer to deal with this, e.g. using libexif.

Of course that is not developer friendly, but at least it would allow single pass decoding/encoding with metadata. And it allows customizing the metadata handling without changing the Skia source code...

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAMcBjo6EWvfsL%2BNxpHz14x70wDLmprPzfCAO4rZ9vyTMjzSqvA%40mail.gmail.com.

[Leon Scroggins]

What is the use case? It sounds like you want to preserve metadata from a decoded image, and then reencode with the same metadata? The orientation seems unnecessary to me (but I must be missing something!) - you can easily reorient the decoded image. What other metadata do you want to store?

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAOo4A_8jX16rzwj6CaCrGyQz-ZRmGkW3dpJV9h1bgxMggmPnCA%40mail.gmail.com.

--

 •  Leon Scroggins

 •  scr...@google.com

[Peter Verswyvelen]

Orientation is indeed metadata that might not be needed, the orientation is applied when decoding anyway.

The other use cases we have are:

- converting file formats to JPEG , keeping as much metadata as possible, optionally downsampling to a smaller resolution.

- downsampling JPEG photos, while keeping data-taken, camera, flash, application... This is required by a third-party photo enhancement tool that reads these properties, to sort user photo thumbs, ... 

- factory production printer software can require some custom metadata, I can't say exactly what these are right now.

- we use the camera metadata to determine if a photo has been manually enhanced by the user in say Photoshop; in this case, no automatic photo enhancement is performed.

- we use the application name metadata internally to specify the photo enhancement tool arguments that got applied.

Currently we use the Windows Imaging Component, it has an interface for reading/writing metadata, but we are switching to Skia (actually SkiaSharp). We already run most of our infrastructure in Google Cloud, and want to remove the dependency on Windows.

Thanks,

Peter Verswyvelen

https://www.smartphotogroup.com

 

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAGzMmOFtO_ZQJb1BzH4QKPkV-gSVy9%3DNEoyTMD9z9HMrorNAuw%40mail.gmail.com.

[Leon Scroggins]

Thanks for the info! I agree that we would prefer an API that lets the client interpret/handle the details of the metadata, given that the Skia library itself is not interested in it (besides the orientation). Instead of introducing something completely new on the decoding side, it might make sense to repurpose the SkPngChunkReader.

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAOo4A__Wt%2B85KTiAt7yjSdZ69pd3C517gUwEWPxBqgaZqT0%2Bsg%40mail.gmail.com.

--

 •  Leon Scroggins

 •  scr...@google.com

[craste...@gmail.com]

I just want to point out that you don't have to use the skia encoders and decoders.  You can just use the jpeg library yourself and get and set the pixels manually.