still image encoing progress_hook

[midora]

I'm wondering about the percentage values received in the progress_hook.

Lossless: Only 4 values 1, 5, 90, 100. Not a lot in 1.5 minutes (large image ;-)

Loosy: 1..114, 134, 154, 173 Why are there values > 100

[Yannis Guyon]

The values look incorrect, thank you for the report.
Could you provide the image to reproduce the issue please? The code snippet you used would also be helpful.

[midora]

For sure. Here is the image I used for tests (Preset Photo, Quality 75).

https://ibb.co/ZzrCZs4

In the lossless case it stays at 5% nearly forever.

I created a c# interface. Nothing special...The progress_hook uses a lambda method. The encoding works fine.

            var libwebp = new LIBWEBP();
            LIBWEBP.WebPPicture frame = new LIBWEBP.WebPPicture();
            LIBWEBP.WebPMemoryWriter* memWriter = (LIBWEBP.WebPMemoryWriter*)IntPtr.Zero;
            var webp_data = new LIBWEBP.WebPData();
            var webp_data_assemble = new LIBWEBP.WebPData();
            IntPtr muxer = IntPtr.Zero;
            try
            {
                bool ok;

                // Prepare the WebPPicture
                ok = libwebp.WebPPictureInit(ref frame);
                if (!ok) throw new Exception( "WebPPictureInit: failed");
                ok = SetPictureFromBitmap(libwebp, ref frame, webpFrameList.Frames[0].Image);
                if (!ok) throw new Exception(WebPEncodingErrorToString(frame.error_code));
                Exception EncodeException = null;
                frame.progress_hook = new LIBWEBP.Delegates.WebPProgressHook((int percent, ref LIBWEBP.WebPPicture picture) =>
                {
                    try
                    {
                        progress.Call(percent);
                    }
                    catch (Exception ex)
                    {
                        EncodeException = ex;
                    }
                    return (EncodeException == null);
                });
                memWriter = (LIBWEBP.WebPMemoryWriter*)Marshal.AllocHGlobal(sizeof(LIBWEBP.WebPMemoryWriter));
                libwebp.WebPMemoryWriterInit(memWriter);
                frame.writer = libwebp.WebPMemoryWrite;
                frame.custom_ptr = (IntPtr)memWriter;

                var config = new LIBWEBP.WebPConfig();
                ok = libwebp.WebPConfigPreset(ref config, (LIBWEBP.WebPPreset)webpFrameList.Preset, webpFrameList.Quality);
                if (!ok) throw new Exception("WebPConfigPreset: failed");
                // Tune 'config' as needed.
                config.lossless = webpFrameList.Lossless;

                System.Diagnostics.Trace.WriteLine("AWEBP: Save:   Encode image");
                ok = libwebp.WebPEncode(ref config, ref frame);
                if (!ok)
                {
                    if (EncodeException != null) throw EncodeException;
                    throw new Exception(WebPEncodingErrorToString(frame.error_code));
                }

                ...

[midora]

I used libwebp 1.2.1 x64.

[midora]

BTW: The additional issue with the small amount of percentage values in the lossless case is that typically the UI uses a progress callback to signal a cancel request. But if progress is not called for a minute the user just has to wait.

If it is not possible to provide adequate progress values then maybe a cancel_hook could be added which the encoder could call more often.

In general I would also prefer a float percentage value to allow more than 100 values (or a permille).

[Yannis Guyon]

The lossy progress range should be fixed: https://chromium.googlesource.com/webm/libwebp/+/db25f1b4ed2ef519b6a3fd1d7ebfbcdfe2cc9712

I may take a look at the lossless progress granularity next.

Unfortunately to avoid any API breakage, the progress hook argument will remain an integer percentage.

[midora]

>>> The lossy progress range should be fixed: https://chromium.googlesource.com/webm/libwebp/+/db25f1b4ed2ef519b6a3fd1d7ebfbcdfe2cc9712

Great, I will check this out. Will this be part of 1.2.2?

>>> I may take a look at the lossless progress granularity next.

This would really help. It's strange for the user if the progress reporting seems to stuck.

>>> Unfortunately to avoid any API breakage, the progress hook argument will remain an integer percentage.

For sure. I mentioned it to have the issue in mind for the future (maybe in libwebp2)

As a proposal for what may be an easy change which doesn't break the current API:

Add a method to the API which allows to get/set the top value of the of the progress range (default 100) and scale the current progress value (the internal resolution must be large enough). So if the calling application sets a value of 1000 the reported value would be in the range 0..1000.

[James Zern]

On Wed, Jan 19, 2022 at 2:47 AM midora <martin...@proregia.ch> wrote:

>>> The lossy progress range should be fixed: https://chromium.googlesource.com/webm/libwebp/+/db25f1b4ed2ef519b6a3fd1d7ebfbcdfe2cc9712

Great, I will check this out. Will this be part of 1.2.2?

Yes, I'm pulling that over now:

https://chromium-review.googlesource.com/c/webm/libwebp/+/3401927

 

>>> I may take a look at the lossless progress granularity next.

This would really help. It's strange for the user if the progress reporting seems to stuck.

>>> Unfortunately to avoid any API breakage, the progress hook argument will remain an integer percentage.

For sure. I mentioned it to have the issue in mind for the future (maybe in libwebp2)

As a proposal for what may be an easy change which doesn't break the current API:

Add a method to the API which allows to get/set the top value of the of the progress range (default 100) and scale the current progress value (the internal resolution must be large enough). So if the calling application sets a value of 1000 the reported value would be in the range 0..1000.

Our step size is rather large currently (maybe too large on the lossless size). Without more granularity in the individual steps, which are just an estimate, the extra scale won't help much.

 

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/d71b22f5-f626-4fb7-8e71-7cea54692135n%40webmproject.org.

[midora]

>>> Our step size is rather large currently (maybe too large on the lossless size). Without more granularity in the individual steps, which are just an estimate, the extra scale won't help much. 

Yeah, the granularity is a precondition for scaling of the value. And it may not be easy to implement this part (plus the problem that the progress_hook is used to cancel the whole encoding). The UI I'm supporting starts encoding immediately on a setting change so it's really a requirement to cancel the encoding as soon as possible if the user changes again a setting. In the lossless case this doesn't really work because of the small amount of progress hook calls.

[midora]

In the meantime I updated my software to use libwebp 1.2.2 and there are no longer out of range progress values. It's not as smooth as users may expect but I know how difficult it is to implement this for this kind of data and encoding. Thanks.

Hope to get more progress values for the lossless case in the future.

[Yannis Guyon]

The lossless encoding progress granularity was increased in https://chromium.googlesource.com/webm/libwebp/+/ec178f2c7febe0e2edc8a2f4e874d84ccb896709

[midora]

Merged main branch with my WebPAnimEncoderGetMuxer extension and tested lossless encoding. Progress report and user cancel works OK now. Thanks.

[Yannis Guyon]

Glad to hear that. Thanks for the feedback!