Visual artefacts appear when filtering is enabled on a thumbnail sheet

[GoogleCodeExporter]

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

Original issue reported on code.google.com by lee.ston...@gmail.com on 27 Sep 2015 at 3:01

Attachments:

• Artefact_Example.zip

[GoogleCodeExporter]

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.

Original comment by lee.ston...@gmail.com on 27 Sep 2015 at 3:17

[GoogleCodeExporter]

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

Original comment by lee.ston...@gmail.com on 27 Sep 2015 at 3:36

[GoogleCodeExporter]

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

Original comment by pascal.m...@gmail.com on 28 Sep 2015 at 10:06

[GoogleCodeExporter]

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 :)

Original comment by lee.ston...@gmail.com on 29 Sep 2015 at 11:41

[GoogleCodeExporter]

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

Original comment by lee.ston...@gmail.com on 3 Oct 2015 at 1:30

Attachments:

• LargeUniformColourAreas.zip

[GoogleCodeExporter]

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

Original comment by lee.ston...@gmail.com on 10 Oct 2015 at 11:57