webpsave doesn't have a profile parameter

[jfcalvo]

Hi,

Any reason why the webpsave operator doesn't have a --profile option like pngsave and jpegsave so we can embed ICC profiles?

I have been checking the docs of the webp format and looks like is something supported: https://developers.google.com/speed/webp/docs/riff_container#color_profile

[jcupitt]

Hello @jfcalvo,

Yes, libvips can read and write EXIF, ICC and XMP chunks to and from webp files. Try eg.:

john@kiwi:~/pics$ python3
Python 3.8.2 (default, Apr 27 2020, 15:53:34) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyvips
>>> x = pyvips.Image.new_from_file("k2.jpg")
>>> x = x.copy()
>>> with open("/usr/share/color/icc/colord/AdobeRGB1998.icc", mode='rb') as f:
...    profile = f.read()
... 
>>> len(profile)
16340
>>> x.set_type(pyvips.GValue.blob_type, "icc-profile-data", profile)
>>> x.write_to_file("x.webp")
>>> 
[1]+  Stopped                 python3
john@kiwi:~/pics$ vipsheader -a x.webp | grep icc
icc-profile-data: 16340 bytes of binary data

[jfcalvo]

Thanks @jcupitt but I'm using the command line at the moment (version vips-8.9.2-Tue Apr 21 09:26:11 UTC 2020). This is the output that I see and looks like that profile option is missing:

$ vips webpsave
save image to webp file
usage:
   webpsave in filename [--option-name option-value ...]
where:
   in           - Image to save, input VipsImage
   filename     - Filename to save to, input gchararray
optional arguments:
   Q            - Q factor, input gint
			default: 75
			min: 0, max: 100
   lossless     - enable lossless compression, input gboolean
			default: false
   preset       - Preset for lossy compression, input VipsForeignWebpPreset
			default: default
			allowed: default, picture, photo, drawing, icon, text
   smart-subsample - Enable high quality chroma subsampling, input gboolean
			default: false
   near-lossless - Enable preprocessing in lossless mode (uses Q), input gboolean
			default: false
   alpha-q      - Change alpha plane fidelity for lossy compression, input gint
			default: 100
			min: 0, max: 100
   min-size     - Optimise for minium size, input gboolean
			default: false
   kmin         - Minimum number of frames between key frames, input gint
			default: 2147483646
			min: 0, max: 2147483647
   kmax         - Maximum number of frames between key frames, input gint
			default: 2147483647
			min: 0, max: 2147483647
   reduction-effort - Level of CPU effort to reduce file size, input gint
			default: 4
			min: 0, max: 6
   strip        - Strip all metadata from image, input gboolean
			default: false
   background   - Background value, input VipsArrayDouble
   page-height  - Set page height for multipage save, input gint
			default: 0
			min: 0, max: 10000000
operation flags: sequential nocache

Maybe it's an option that could be added?

[jcupitt]

You can set the profile with:

john@kiwi:~/pics$ vips icc_transform k2.jpg x.webp /usr/share/color/icc/colord/AdobeRGB1998.icc
john@kiwi:~/pics$ vipsheader -a x.webp | grep icc
icc-profile-data: 16340 bytes of binary data

You're right, we could add a profile= option to webp save, but it's a bit dangerous -- it's easy to attach a profile that's not correct. TIFF, JPG and PNG have this parameter, but they probably should not.

What's the use case?

[jfcalvo]

What's the use case?

Adding one ICC profile (from a limited and defined set of them), by default I set the profile to sRGB 2.1 1996 (as recommended by web browsers in general), but it's also possible to add Adobe RGB 1998 if required (but setting only one is allowed).

Do you recommend to use icc_transform for pngsave and jpegsave too instead of using the --profile option? What's the benefit of using icc_transform?

[jcupitt]

The problem with the profile= option is that you can get the wrong profile attached.

Suppose you have an sRGB image and save with profile=Adobe98.icm. The pixels are still sRGB, but will be displayed as if they are Adobe98, so your image will look very oversaturated.

The icc_transform operation imports the image to PCS using any profile attached to the image, then exports again to device space using the output profile. You'll get an image which will have Adobe98 pixels and will be tagged as Adobe98.

[jcupitt]

For example:

john@kiwi:~/pics$ vips copy Gugg_coloured.jpg x.jpg[profile=/usr/share/color/icc/colord/sRGB.icc]
john@kiwi:~/pics$ vips copy Gugg_coloured.jpg y.jpg[profile=/usr/share/color/icc/colord/AdobeRGB1998.icc]

Gives:

[jcupitt]

The bottom JPG has the wrong profile and looks very oversaturated.

[jcupitt]

Ah, are users uploading Adobe98 images with no profiles? I can see that would be a problem.

[jcupitt]

.... in which case you'd need:

$ vips icc_transform k2.jpg x.webp /usr/share/color/icc/colord/AdobeRGB1998.icc \
    --input-profile /usr/share/color/icc/colord/AdobeRGB1998.icc

ie. transform with a98 as both input and output.

[jfcalvo]

The bottom JPG has the wrong profile and looks very oversaturated.

Understood. You are only adding the profile without touching pixels (from a sRGB image) and that's causing the oversaturation in the one with Adobe RGB.

Ah, are users uploading Adobe98 images with no profiles? I can see that would be a problem.

I need to work in the logic a little bit more but you're right that's a possibility. I will use your suggested snippet.

I have an additional question. It's possible to use your snippet with the output to vips format instead of webp and later use the webpsave or pngsave respecting the ICC profile? (That's in the case that I need to do more transformations later)

Thank you very much John.

[jcupitt]

Yes, vips format will keep all the metadata.

Personally, I would use python / ruby / php / lua / C# etc. rather than the CLI -- you'll save a huge amount of disc IO and CPU. Of course that's a separate issue.

[jfcalvo]

Yes, vips format will keep all the metadata.

Cool, thanks for the clarification.

Personally, I would use python / ruby / php / lua / C# etc. rather than the CLI -- you'll save a huge amount of disc IO and CPU. Of course that's a separate issue.

You're totally right. I'm using Elixir, and sadly there is not a vips NIF library for the language. I'm working in one (still in a super early state). In the meantime I want to have a prototype where I can learn about the library and If I can do all that I need with it.

Thanks again.

[jcupitt]

Ah, gotcha. Good luck with the binding -- I guess you saw the notes in the docs?

https://github.com/libvips/libvips/blob/master/doc/binding.md

The jekyll version is truncated, for some reason.

[jfcalvo]

Ah, gotcha. Good luck with the binding -- I guess you saw the notes in the docs?

Not yet, thank you for the link. I'm still playing with the compiler and how NIFs are compiled and integrated into the language. I have been thinking into integrate Lua scripts too as alternative but still not sure.

[jcupitt]

Yes, luajit is pretty fantastic. It's really nice having FFI built in -- it avoids a lot of complication with separate compile steps and linking. If only arrays didn't index from one :(

[jcupitt]

If you're going to be doing image resize, you should probably read the libvips wiki page, it's surprisingly complex:

https://github.com/libvips/libvips/wiki/HOWTO----Image-shrinking

Or just use thumbnail operation, which does all that for you.

[jfcalvo]

I'm using thumbnail a lot. I have some unexpected results for upscaling images. I will probably create a new issue for that.

I have another question. I'm not sure if it's possible using the vips command line. I would like to know if it's possible to remove the ICC profile from a image.

[jcupitt]

All savers have a strip option to remove all metadata.

You can change fields on vips images with vipsedit. You'd need to extract the XML metadata, remove the icc-profile-data node, and reattach.

[jfcalvo]

All savers have a strip option to remove all metadata.

Yes, I have been using it, but it remove everything as expected (including EXIF data).

You can change fields on vips images with vipsedit. You'd need to extract the XML metadata, remove the icc-profile-data node, and reattach.

I found it like two days ago but I wasn't sure of the purpose of it. I will try to explore that.

Thanks!.

[jfcalvo]

@jcupitt I have been playing too extracting the ICC profile for the images with vipsheader (for testing purposes). I don't have much problems except for some specific formats like gif and jp2.

For example I can't detect or extract the profile from this gif image even when MacOS preview show Adobe RGB (1998) as expected.

This is the output that I get (not icc-profile-data present):

$ vipsheader -a example.gif
example.gif: 1000x667 uchar, 3 bands, srgb, gifload
width: 1000
height: 667
bands: 3
format: uchar
coding: none
interpretation: srgb
xoffset: 0
yoffset: 0
xres: 1
yres: 1
filename: example.gif
vips-loader: gifload
n-pages: 1
loop: 1
delay: 0

If I try to get the icc-profile-data field I get an error:

$ vipsheader -f icc-profile-data example.gif
vipsheader: vips_image_get: field "icc-profile-data" not found

I have used the following to generate the image:

$ vips icc_transform example.jpeg example.vips adobergb1998.icc --input-profile srgb.icc
$ vips magicksave example.vips example.gif --format gif

For jp2 format is even worst because looks like is not attaching the profile (is not present on MacOS preview and the same is happening with vipsheader). I'm using something similar to generate the image:

vips icc_transform example.jpeg example.vips adobergb1998.icc --input-profile srgb.icc
vips magicksave example.vips example.jp2 --format jp2 --quality 100

I can't upload the jp2 image because is not supported by GitHub.

So looks like we are talking about two different problems:

1. With gif format looks like vipsheader is not capable of detect or extract the profile (the generation of the gif file is fine and the profile is correctly attached, the colors looks fine too and MacOS preview correctly shows Adobe RGB (1998)).
2. With jp2 format looks like the magicksave operation is not taking the profile into account or something similar.

What do you think can be happening for these two issues?

[jcupitt]

I added a profile option to webpsave.

I had no idea GIF supported ICC profiles, but you're right, that temple seems to have one. I wonder how they encode it? magicksave is obviously adding one somehow.

libvips has its own gif loader and it does not support ICC profiles because giflib and libnsgif do not support ICC profiles (as far as I know).

I've no idea about jp2: that's handled by magickload / magicksave, so any ICC support is up to them.

[jcupitt]

Huh looks like there are extension chunks for ICC and XMP:

https://chromium.googlesource.com/webm/libwebp/+/v0.3.0-rc6/examples/gif2webp.c#387

libvips supports the NETSCAPE and ANIM chunks, but not the other two. An enhancement for the next libvips perhaps.

Could you open a new issue for this? It'll get forgotten otherwise.

[jfcalvo]

I added a profile option to webpsave.

Cool, I think in order to be more homogenous with the other save operators it's a good idea.

Could you open a new issue for this? It'll get forgotten otherwise.

It's not totally clear to me what you want to accomplish in that issue but I will write one and you can edit it if necessary.

Done here: #1726

[pomirleanu]

Any idea on how to resize animated webp?
I get an error while trying to resize or copy using "video.webp[n=-1]" => webp: bad image dimensions

[jcupitt]

Hello @pomirleanu, please open a new issue and upload a sample image.