Thoughts on WebP derived from pos/neg film & digitized captures

[Michael Quentin Angelo Sidors]

All,

I'm writing to share my recent experiences with WebP conversion. Source
formats comprised of positive/negative film scans, B&W film scans,
low/high key imagery, grainy/grainier imagery, digitized/film grain and
digitized sources.

I'm not subscribed. Please CC or reply direct if replies are required.

Any feedback/advice based upon my experiences and commentary from your
own WebP experiences are welcome, especially concerning automation tips
yielding near visually identical WebP equivalents covering a broad range
of source file captures. I've not yet read over the list.

Sincerely,
Mike.
https://photistic.org/

--

*A I M S*

My intention was to compile a set of WebP equivalents with smaller file
size compared to their JPEG counterparts, whilst simultaneously
retaining visual quality. I judged solely from visual display output
with minimal regard to technical jargon, though the latter does interest
me where improvements could be seen. I've got pretty good eyesight,
don't wear glasses and don't /think/ I need them.

*A P P A R A T U S*

1500 pixel width JPEG files derived from 48 Bit TIFF, saved at Photoshop
quality 10, subsequently transformed to optimized, progressive DCT
Huffman coding.

WebP files derived from 48 Bit TIFF. Cwebp 0.6.0 20 January 2017.

Most 135 film scans from a Nikon Cool Scan 4000. Most medium/large
format film scans from an Imacon Flextight. Digitized captures from
various DSLR cameras. N.B. The original 48 Bit raw film scans were
always scaled down, most likely in steps of ~1500 pixels for
preservation and most likely using /bicubic sharper/ re sampling,
however Photoshop defines that.

--

After a few tests, I read through the cwebp manual and settled on some
base switches, then altered only the compression factor, selecting 85
and 90-95 inclusive.

Omitting q, I settled on:


-alpha_filter best -m 6 -sns 100 -hint photo -pre 2


I then had a resultant image set comprising 7 variations.

*M E T H O D O L O G Y*

I visually compared low, mid-grey and high-key areas, acutance and
colour consistency. Some q=85 images did show slight colouration
difference, but rarely above q=90.

In addition to the visual tests, I kept in mind the corresponding JPEG
file size so as not to select a larger WebP. On the rare occasion, some
WebP files that were q=95 were larger than the corresponding JPEG. From
memory 95 was the upper threshold limit. I'm not sure what source image
characteristics would lead to consistently producing a WebP of q=95
larger than its JPEG counterpart, but that was a rarity.

.
.
.

Eventually, I compiled a set of WebP files to accompany the JPEG files.

--

*R E S U L T S*

My 3 largest galleries by total file size were reduced by approximately
two-thirds, in other words a substantial reduction assuming I had good
dietary guidelines in the first instance. Specifically:

Urbanity - 67% reduction.

JPEG - 23.6M
WebP - 15.7M

India - 62% reduction.

JPEG - 19.5M
WebP - 12.1M

Sudamérica - 69% reduction.

JPEG - 20.9M
WebP - 14.4M

--

*C O N C L U S I O N S*

*Is there a magic bullet for automated WebP conversion as an
instantaneous, drop-in replacement for JPEG with multiple source file
formats? I don't know. For me it required critical, visual evaluation of
each image; so from my experiences, no. This is somewhat time consuming
given that a JPEG of quality 10 is in my opinion always going to be
visually acceptable for web display below 2k pixel width. If there is a
magic bullet, one-shot solution, I'd be pleased to know.

*I found that grainy images, particularly low-key and high ISO positive
film scans were such that at least a 93-95 WebP was required for its
respective JPEG counterpart.

Example. /Swarthy Scape/ from Urbanity. Q=95.

*Interestingly, I found that regardless of the source capture, minute
hair-line detail suffered in all the WebP equivalents and required a
q=95 to achieve equivalence; sometimes this still wasn't enough such
that the WebP file size exceed the JPEG. From my experience with a JPEG
of Photoshop quality 10, minute hairlines are rendered well but WebP
suffered in this regard. I'd be keen to hear how to tackle this in future.

Example. /Blue Blood/ from Urbanity. Hair-line suit detail. Q=93.

*In general, I found most brighter or highish-key images, regardless of
source capture, would be fine with q=90/91. I found these images the
easiest to visually judge. By contrast, the opposite held true for
low-key images.

*In general, both B&W & colour negative scans exhibited substantial file
size savings, generally requiring no more than q=85. This may be
different for darker, low-key imagery. B&W WebP files were derived from
desaturated RGB files, not grey scale, and included print scans. In all
huge savings were made from negative film and B&W print scans.

Example. /Portrait of Sikh Warrior/ from India. Q=85.
JPEG: 832KiB.
WebP: 399KiB.

*Some large format positive film scans with little tonality exhibited
poorer WebP equivalents than their JPEG counterparts. Shadow detail with
little tonality appeared choppy in the WebP and sometimes no WebP
equivalent was available up to q=95. I didn't bother with a larger q
value as it defeated the purpose of file size reduction.

Example. /Tidal Sublimation/ from Lunambulism. Q=95.

*For everything else, I'd usually settle between 90-93 with a trade-off
between file size comparison and visual inspection.

--

*F U R T H E R A N A L Y S I S*

Some unanswered questions remain, such as how the multitude of
combinatory images could be automated into visually identical WebP
output workflows. For example how would WebP render blurry _and_ grainy
imagery? And how about soft focus imagery? How could I increase acutance
of minute hair-line detail? Is there a magic bullet?

[Jyrki Alakuijala]

Thanks for posting the analysis. Such detailed analysis is very nice to read!

Butteraugli has a detector for hair-line details, and consequently they tend to be well preserved. Guetzli and PIK are the main Butteraugli-based image compressors. Have you tried Guetzli at quality setting 94, or the 'PIK' codec at quality 1.0? They may be better suited for high quality image compression (q > 90) whereas WebP may be better suited for low quality (q < 75).

No one has built a Butteraugli-optimizer for WebP yet, we only have it for JPEG (guetzli) and for the PIK image format -- built into the reference PIK encoder itself.

PIK and Guetzli don't have magical capabilities against film grain -- one gets maximum benefits from its advanced modeling when there is not a lot of film grain in the images.

--
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+unsubscribe@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Pascal Massimino]

Mike,

thanks for the report!

On Mon, Sep 18, 2017 at 7:45 AM, 'Michael Quentin Angelo Sidors' via WebP Discussion <webp-d...@webmproject.org> wrote:

All,

I'm writing to share my recent experiences with WebP conversion. Source
formats comprised of positive/negative film scans, B&W film scans,
low/high key imagery, grainy/grainier imagery, digitized/film grain and
digitized sources.

I'm not subscribed. Please CC or reply direct if replies are required.

Any feedback/advice based upon my experiences and commentary from your
own WebP experiences are welcome, especially concerning automation tips
yielding near visually identical WebP equivalents covering a broad range
of source file captures. I've not yet read over the list.

Here are few flags you might want to try with cwebp:

  -sharp_yuv

     this will try to better preserve details during YUV upsampling (hairline problem)

  -jpeg_like

    this flag tries to make WebP quality factor behave more like JPEG's one

  -psnr <some-acceptable-pnsr-value-like-42>

    This will tell cwebp to aim at a certain degradation threshold. You could review

    the encoding you already have, measure the PSNR distortion, and make it the

    target for your new encoding.

And it's indeed true that starting around q=95, WebP files can start being larger

than the JPEG source, whose artifacts WebP is struggling with and spending a

lot of bits reproducing! It all depends on the initial JPEG quality, for sure. One

can't go over past it, least of inventing details that are already gone from the source!

hope it helps,

skal/

 

[Jyrki Alakuijala]

Just to check:

Do you see the hair-line problem on black-and-white images, too? Or is it only for some color features?

[Michael Quentin Angelo Sidors]

Pascal & jyrki,

Much appreciative for the Guetzli tip; I have not tested it and
certainly will.

Re hair-line detail in B&W. No, generally a WebP of q=85 was sufficient
and no hair-line detail was compromised. Though I don't have many B&W
examples to report on.

Pascal Massimino:

> Mike,
>
> thanks for the report!
>
> On Mon, Sep 18, 2017 at 7:45 AM, 'Michael Quentin Angelo Sidors' via
> WebP Discussion <webp-d...@webmproject.org

> <mailto:webp-d...@webmproject.org>> wrote:
.
.
.> Here are few flags you might want to try with cwebp:

>   -sharp_yuv
>      this will try to better preserve details during YUV upsampling
> (hairline problem)

This produced some interesting variations and thanks for that tip.

2 other images I experimented with contained in/out of focus
compositions; 1 portrait and a tele crop of water reflections. Both used
a different DSLR and lens combination.

What I found interesting was that though both images have in/out of
focus elements, only 1 jumped markedly in file size with -sharp_yuv.
Only 1 image benefited from -sharp_yuv and the results weren't consistent.

/QUANTUM INSERT/ from Lunambulism.
Both visual acutance and file size jumped markedly with -sharp_yuv.

I then tried reducing Q to 90 with -sharp_yuv. File size was then
similar to my original WebP of q=93 without -sharp_yuv.

/Señora/ from Sudamérica.
No difference to visual acutance with -sharp_yuv but markedly different
colour renditions with it.

Surprised that a q=85 image sufficed initially, -sharp_yuv increased
colour luminosity in intricate hair-line detail areas that were in focus
only for reds/pinks. It didn't look like a saturation increase.

File sizes remained virtually unchanged - I suppose because of a lack of
increase in visual acutance.

Perhaps this an example of an image that already has good acutance not
requiring nor benefiting from -sharp_yuv.


/QUANTUM INSERT/ from Lunambulism.
JPEG: 325KiB. Website version.
WebP: 272KiB. Q=93. 47dB. Website version.
WebP: 280KiB. Q=90. -sharp_yuv. 44.6dB. Better acutance than q=93.
WebP: 372KiB. Q=93. -sharp_yuv. 46.4dB. Better acutance but > JPEG size.


/Señora/ from Sudamérica.
JPEG: 614KiB. Website version.
WebP: 335KiB. Q=85. 42dB. Website version.
WebP: 345KiB. Q=85. -sharp_yuv. 41.6dB. Red/pink luminosity change.
WebP: 506KiB. Q=93. 45.8dB.
WebP: 521KiB. Q=93. -sharp_yuv. 45.3dB. Red/pink luminosity change.

Moral to the story?
No magic bullet [yet] ...