About libjpeg optimize_coding

[Frank]

Hi,

I read the following article. It's about libjpeg optimize_coding parameter.

https://github.com/bither/bither-android-lib/blob/master/REASON.md

It's a important parameter which effects user experience.

Does Skia have official way to solve the problem? 

If there are no official solution. Is it possible that Skia and APIs based on Skia (such as Android API) provides a option let developer change optimize_coding setting in a further version?

Regards

Frank

[Leon Scroggins]

Thanks for the info. That does look like something worth investigating. FWIW, Skia's JPEG encoder was written almost a decade ago, when Android devices had much slower processors and storage space was much more limited. So at the time it was written, leaving optimize_encoding at its default value was likely a good decision.

Since then, the Skia team has focused on making drawing fast. I cannot speak for all of the Skia or Android teams, but I was unaware there was an issue of quality in JPEG compression. That said, Skia is an open source project, so if you're able to demonstrate the improvement and measure the tradeoffs, we'd be happy to accept a patch. I've filed a bug at skbug.com/3460 tracking this feature.

As for modifying APIs: It would be nice if investigation reveals that optimize_coding is always better and worth the cost. If not, we need to decide how best to present the option to the user. SkImageEncoder already has an integer "quality" the caller uses to determine how we encode images. Perhaps we can decide a certain quality or above means to use optimize_coding. Changing the Android API (or even functionality) tends to be more difficult, since we worry about backwards compatibility. Perhaps we can again piggyback on Bitmap.compress's quality in the same way, but we need to make sure we don't cause any problems for existing apps (e.g. apps with a lot of JPEG images may take more time loading images).

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

--

Leon Scroggins III
scr...@google.com

[Mike Klein]

This optimize_coding flag might want to stand separate from quality, if only because it's designed to reduce file size, which would ordinarily be indicated by setting a _low_ quality flag.

[fya...@gmail.com]

Thank you.

I understand these are problems left over by history, and the default value has been good decision. It's especially hard to fix the public API depends on Skia.

About the patch, I contacted the bither-android-lib team, and got the reply. They will discuss it.

And I'll try to contact Android community, try to find out the way to keep backwards compatibility and improve the user exprience.

You received this message because you are subscribed to a topic in the Google Groups "skia-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/skia-discuss/p0IcyBoU8P0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to skia-discuss...@googlegroups.com.

[fya...@gmail.com]

I agree to you, and believe the optimize_coding flag stands separate from quality.

So it's hard to solve the problem without adjusting the API, right? We should provide an exact method to let developer specify the behavior that app need.

Besides the exact way, lot's public APIs depends on Skia cannot take the advantage without adjusting the API too. Is there a compromise way to adjust the default behavior, which like "Perhaps we can decide a certain quality or above means to use optimize_coding."

i.e. (Just based on my understanding. I have no experience on public API development. So, maybe these are bad idea.)

* The high bit of quality means optimize_coding.

This will cause ordinarily illegal parameters appear. And further new features can use other high bits as new options.

* When quality > certain quality value enable optimize_encoding.

This will cause backwards compatibility. But if we adjust the quality value based on user experience, maybe we can find that it's almost the same behavior that user expect in instinct.

quality low = cpu mem low, time short, size small
quality medium = cpu mem medium, time medium, size medium
quality high = cpu mem high, time long, size big <- with the optimize_encoding enabled, The cpu mem consumed higher and time longer, but size less bigger and quality higher.

Except the case that the application need high quality image processed in specified time, this way seems acceptable too, right?
And if we have stat data, among the cases, we can find out which common case is and which rear case is. Let new API make common cases better.

* Add a global envronment mode variable to let developer choose the behavior.

You received this message because you are subscribed to a topic in the Google Groups "skia-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/skia-discuss/p0IcyBoU8P0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to skia-discuss...@googlegroups.com.

[N. SODA]

So it's hard to solve the problem without adjusting the API, right?

Does this problem really exist?
Original article ( https://github.com/bither/bither-android-lib/blob/master/REASON.md )
says "the file size are 5-10 times bigger", but this should be wrong.
The optimze_coding flag saves only 5-10 percent, and setting the flag requires
much more memory at compresson time.
(As already said, original article is also wrong about the difference of quality, FWIW.)

Is it worth providing such flag?

[vroad]

I agree with N. SODA.

It doesn't make sense to provide such flag unless you want to target extremely old devices.

[vroad]

Well, libjpeg doc says

"In most cases optimal tables save only a few percent of file size compared to the default tables."

Then original article appears to be incorrect about both file size and quality as he said.

So is he saying that preserving old behavior is not so bad thing?