Open GoogleCodeExporter opened 8 years ago
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
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
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
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
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:
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
Original issue reported on code.google.com by
lee.ston...@gmail.com
on 27 Sep 2015 at 3:01Attachments: