Skia Progressive Jpeg encode support

[Kristian Santrou]

Hello,

i'm using skiasharp with .net core for image resizing and re-encoding, before uploading them to azure storage as blobs. I've been looking through the documentation as well as the samples and i can't seem to find an option for encoding jpegs as progressive.

Is there something i missed or it not supported?

[Matt Sarett]

It is not supported right now.  Why do you want to encode progressive jpegs?

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Kristian Santrou]

To use on the web (we can not move to webp at the moment).

On Tuesday, March 28, 2017 at 4:23:58 PM UTC+3, Matt Sarett wrote:

It is not supported right now.  Why do you want to encode progressive jpegs?

On Tue, Mar 28, 2017 at 5:44 AM, Kristian Santrou <k.sa...@gmail.com> wrote:

Hello,

i'm using skiasharp with .net core for image resizing and re-encoding, before uploading them to azure storage as blobs. I've been looking through the documentation as well as the samples and i can't seem to find an option for encoding jpegs as progressive.

Is there something i missed or it not supported?

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

[Matt Sarett]

Do you think that progressive jpgs are preferable to sequential jpgs for a particular web use case?

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss+unsubscribe@googlegroups.com.

[Kristian Santrou]

Aren't they? You deliver an image immediately and gradually improve its clarity, instead of loading and displaying it in chunks.

[Matt Sarett]

That's true.

In general, progressive jpegs will result in slower total decode time and much higher decode memory use.  I think you can make an argument for using progressive jpegs if:

(1) You are focused on the "slow network" use case and want to be able to display a "full" image while you are waiting for the rest of the encoded data to arrive (maybe just use webp in this case though - they're smaller so they arrive faster).

(2) You have a really, really large image that will decode slowly regardless of when the data arrives.  You want to display the "full" image before the decode is complete.  I'm not sure if this ever makes sense - the memory use will be pretty terrible.

Typically, I would recommend using sequential jpegs.  In most cases, jpeg decoding is now fast enough that there is no reason to pay for the progressive display.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss+unsubscribe@googlegroups.com.

[Matthew Leibowitz]

I think that "slow network" is sometimes missed when it comes to countries that are not so developed. This is an issue in South Africa for sure, and I believe in other third world/developing countries. Not everyone is in the US.

Also, this does not really deal with the original question. The OP is asking about ENCODING, which may/may not have anything to do with decode memory usage. Using progressive images on the web is good because we can load pages "faster" (no one [the common folk] really cares about memory usage as long as they see stuff) Sure, we want the optimal, but this is often something that UX will lose in favour of UX.

Also, skia is powerful enough for rendering/manipulating images on servers. This is also one of the use cases for SkiaSharp: a fully cross-platform way to process images, without any ties to apps on the device/server. Again, it may be better to use library X on mac, library Y on Windows and library Z on Linux, but sometimes this is not viable for cross platform apps - especially since the image processing may be a minor part of the system.

But, I think this question may pose questions that are not directly related PJPEG. I can see that skia can load a good few formats, as well as has some special features for loading PNG. This is great, but the encode is basically a "format" and "quality" operation. Encoding may be extended to saving multipage/frame images, or encoding flags...

Just my 2 cents...

[Kristian Santrou]

Target audience is Greece so network can not be classified as fast by any stretch of the imagination. Although i checked our blob storage and most images served are quite small (under 100kb) with only few of the full sized originals being up to 2mb, which is generally not important in our use case since they are dynamically loaded upon request.

I'm with you with on the resource part, unfortunately however it is not my decision to make, just as it is not my decision to not use webp.

We ended up using a different library (Magick net) that produces just about the same visual results but larger file size and (even thought i didn't measure it) noticeably slower processing time.