Issue 265 in webp: Visual artefacts appear when filtering is enabled on a thumbnail sheet

[we...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 265 by lee.ston...@gmail.com: Visual artefacts appear when
filtering is enabled on a thumbnail sheet
https://code.google.com/p/webp/issues/detail?id=265

What steps will reproduce the problem?

Any options that include filtering for example: cwebp -preset photo.
Specifying -f 0 clears up these artefacts.
Using a higher -q uality value reduces them.
Any value(apart from 0) of -f creates artefacts in the same places.
Any value of -sns can change the location of artefacts for a given -f value.
Any value of -pre can change the location of artefacts for a given -f value.

Using an earlier version for example 0.2.1 does not have the artefacts
detailed here.


What is the expected output?

I would expect there to be no unsightly visual artefacts like when using
version 0.2.1. Unsure upto what version this ceased to be the case, but i
noticed them when 1st trying 0.4.1 from what i remember.
I have provided examples of 0.2.1 for your convenience, the filenames with
021 in them. The q49 file is just to show what it looks like at roughly the
same file size as 0.4.3 just using -preset photo.


What do you see instead?

On the file Sheet_001-043-photo.webp at the edges of the images gw160.png &
gw157.png on the sheet you can see noticeable dark artefacts.


What version of the product are you using? On what operating system?
Tested on Win7 64 host, and WinXP 32 inside a VM.

0.2.1, 0.4.3 and latest source from git.


Please provide any additional information below.

In this example while quite dark, to me they still just jump off the page.
I do imagine this sort of image isn't your target but wanted to log it in
case anything can be done. I am more than happy to stick with 0.2.1 as
these sheets are just for personal use.
I did grab the latest source from git this morning and compiled for win32
and the issue and files produced are identical to 0.4.3, the newer -pre
values just moved the artefacts around a bit. This image is quite tame for
the artefacts but others are more extreme. On this example -picture helps a
fair bit due to -pre 0, apart from on the thumb for gw157.png on other
thumbnail sheets it doesn't do much. On sheets with brighter images these
dark artefacts are really obvious.
These were just a random set of images i rotated to highlight the issue.
I did search and couldn't find anything related to this so i hope it isn't
a duplicate and that i had used bad search terms.

A maybe irrelevant observation:
Changing the text colour can help quite a bit but not eliminate the
artefacts.

Filename format:
[source file]-[webp version used]-[any options specified].webp

Attachments:
Artefact_Example.zip 3.9 MB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[we...@googlecode.com]

Comment #1 on issue 265 by lee.ston...@gmail.com: Visual artefacts appear

when filtering is enabled on a thumbnail sheet
https://code.google.com/p/webp/issues/detail?id=265

If the image width is changed to 1808 so it's a multiple of 16 these
artefacts disappear. This also makes it retain a lot of extra fine detail
it seems.

[we...@googlecode.com]

Comment #2 on issue 265 by lee.ston...@gmail.com: Visual artefacts appear

when filtering is enabled on a thumbnail sheet
https://code.google.com/p/webp/issues/detail?id=265

After testing on other sets of images making sure width and height is a
multiple of 16 instead of 8 artefacts still appear.

[we...@googlecode.com]

Comment #3 on issue 265 by pascal.m...@gmail.com: Visual artefacts appear

when filtering is enabled on a thumbnail sheet
https://code.google.com/p/webp/issues/detail?id=265

The main difference between 0.2.1 and 0.4.3 is that the default filtering
was changed from 'simple' (in 0.2.1) to 'strong' (0.4.3).

Some options in 0.4.3 that you might want to try out:
-nostrong
To switch back to 'simple' filtering
-af
To auto-adjust filtering strength. This is slower than manual setting
with -f option.

(they can be used in combination, too).

Also, for this sort of input, you might want to try to change the number of
segments (-segments option).

One surprising feature of this kind of input is the presence of black
borders and area everywhere. One need to dedicate one segment to it, as
shown by the option '-map 2'. The filter-strength autodetermination algo
might be upset in such situation.
Will have a look...

[we...@googlecode.com]

Comment #4 on issue 265 by lee.ston...@gmail.com: Visual artefacts appear

when filtering is enabled on a thumbnail sheet
https://code.google.com/p/webp/issues/detail?id=265

Hi Pascal,

Using -strong -af gives the best results in a quick test i just did. Using
-strong on it's own does remove the worst of the artefacts but minor ones
still remain in the same places. Using -af on it's own removes all
artefacts(on the 1 test image i just tried) but has some loss of colour on
the edges of each thumb image, i guess where it's trying to blend it in
with the black?

Will investigate further when i should have some more time tomorrow.


Many thanks!

Lee

PS OT but is there any documentation anywhere on how -size works? ie what
parameter's are changed so it can reach it's target, it doesn't seem to be
restricted to -q. I don't really know C/C++ much so doubt i could
understand the source but can try assuming i can find it :)

[we...@googlecode.com]

Comment #5 on issue 265 by lee.ston...@gmail.com: Visual artefacts appear

when filtering is enabled on a thumbnail sheet
https://code.google.com/p/webp/issues/detail?id=265

One thing i forgot to mention is that when there are say half a page of
thumbs leaving large areas of a single colour recent versions seem to
handle them badly(oddly/incorrectly?) compared to 0.2.1.
Usually q 75 in 0.2.1 is equivalent file-size/visual quality to q 82/83
using default settings in 0.4.3. But in the example attached below i had to
use q 90 to get similar results and the same applies to other batches of
images without a full page.

On using -segment, you mentioned that -map 2 showed i should dedicate 1
segment to it, i guess that would be by using -segment 2? i did try that
but found the quality of the parts of the image with content suffered
compared to 3/4 segments. Using just 1 segment actually produced reasonable
images in some ways retaining extra fine details but loosing out in other
areas compared to 3/4.

Maybe the visual quality issues with images with large blank areas and when
using -segment 2 on full thumbnail sheets are related in that it's handling
those blank areas incorrectly? should this be a separate issue on the
tracker?


Regards,

Lee

Attachments:
LargeUniformColourAreas.zip 1.2 MB

[we...@googlecode.com]

Comment #6 on issue 265 by lee.ston...@gmail.com: Visual artefacts appear

when filtering is enabled on a thumbnail sheet
https://code.google.com/p/webp/issues/detail?id=265

I got older webp versions to try and 0.3.1 was the newest version i could
find without this issue and it seems -strong went default with 0.3.0. I
noticed that 0.2.1 didn't have -segment but 0.3.0+ does.

I was also trying out combinations of -q & -segment without -nostrong & -af
and found some oddities. Certain combinations (which were different for
each image sadly) got rid of the horrible black chunks which are eaten out
of the thumbnails at other times. The minor artefacts are only easily
noticeable if you bump the gamma up most of the time. An example:
[-q] [-segment]
85 1
86 1, 4
88 1, 2, 4
89-100 1, 2, 3, 4

Any combinations not listed had the major ones ie all of -q 87. I tested
from -q 70 to 100.

Another example:
[-q] [-segment]
84 3
85 2, 3
86 3
87 4
88 2, 3
89 3, 4
90 2, 3, 4
91 2, 3, 4
92 2, 3, 4
93-100 1, 2, 3, 4