An equivalent to getImageProperties

[boan-jfm]

Hi

Is there an equivalent to ImageMagicks getImageProperties in php-vips?

The motivation is to see the possible fields I can get via the get method; https://github.com/libvips/php-vips/blob/v2.2.0/src/Image.php#L1183.

I have tried the following:
$icc= $libvip_image->get('icc-profile-data');
$exif = $libvip_image->get('exif-data');

But this gives me some kind of binary data, I am not sure which format it is.

Thanks.

[jcupitt]

Hi @boan-jfm,

icc-profile-data and exif-data are binary strings containing those objects. You can write them to a file and open them with tools like ICC Profile Inspector, or exiftool, for example.

You can use vipsheader to see all metadata on an image, perhaps:

$ vipsheader -a k2.jpg
k2.jpg: 1450x2048 uchar, 3 bands, srgb, jpegload
width: 1450
height: 2048
bands: 3
format: uchar
coding: none
interpretation: srgb
xoffset: 0
yoffset: 0
xres: 2.835
yres: 2.835
filename: k2.jpg
vips-loader: jpegload
jpeg-multiscan: 0
jpeg-chroma-subsample: 4:2:0
exif-data: 186 bytes of binary data
resolution-unit: in
exif-ifd0-Orientation: 1 (Top-left, Short, 1 components, 2 bytes)
exif-ifd0-XResolution: 72009/1000 (72.009, Rational, 1 components, 8 bytes)
exif-ifd0-YResolution: 72009/1000 (72.009, Rational, 1 components, 8 bytes)
exif-ifd0-ResolutionUnit: 2 (Inch, Short, 1 components, 2 bytes)
exif-ifd0-YCbCrPositioning: 1 (Centred, Short, 1 components, 2 bytes)
exif-ifd2-ExifVersion: Exif Version 2.1 (Exif Version 2.1, Undefined, 4 components, 4 bytes)
exif-ifd2-ComponentsConfiguration: Y Cb Cr - (Y Cb Cr -, Undefined, 4 components, 4 bytes)
exif-ifd2-FlashpixVersion: FlashPix Version 1.0 (FlashPix Version 1.0, Undefined, 4 components, 4 bytes)
exif-ifd2-ColorSpace: 65535 (Uncalibrated, Short, 1 components, 2 bytes)
exif-ifd2-PixelXDimension: 1450 (1450, Long, 1 components, 4 bytes)
exif-ifd2-PixelYDimension: 2048 (2048, Long, 1 components, 4 bytes)
orientation: 1

There's vips_image_get_fields() to get an array of field names from an image. Other language bindings expose this, we should probably expose it in php-vips as well.

[jcupitt]

I added getFields() to git master php-vips:

97c3fd8

There's an example program here:

https://github.com/libvips/php-vips/blob/master/examples/fields.php

You can run it like this:

john@banana ~/GIT/php-vips/examples (master) $ ./fields.php ~/pics/k2.jpg
/home/john/pics/k2.jpg
width: 1450
height: 2048
bands: 3
format: uchar
coding: none
interpretation: srgb
xoffset: 0
yoffset: 0
xres: 2.835
yres: 2.835
filename: /home/john/pics/k2.jpg
vips-loader: jpegload
jpeg-multiscan: 0
jpeg-chroma-subsample: 4:2:0
exif-data: ExifII�V

Though the binary data obviously doesn't display so well.

[boan-jfm]

Thank you 🙏

Maybe I am holding this wrong, I have created a test JPEG in Windows Paint, and added some metadata (via properties in Windows) - which is showing up fine in the exiftool you mentioned.

Output from exiftool

I would expect the same fields as the exiftool from the getFields, and the same values. Seems like I am holding it wrong?

PHP Code

        $libvips_meta_path = codecept_data_dir("resources/php-vips-meta.jpg");
        $libvips_meta = Image::newFromFile($libvips_meta_path);
        $fields = $libvips_meta->getFields();
        $author = $libvips_meta->get('exif-ifd0-XPAuthor');

Output from the getFields method

Output from get('exif-ifd0-XPAuthor')

Test image with metadata

[boan-jfm]

Okay, maybe I confused my self here, by calling the value the same as the fields. It is the same value, just the part "(Author, Byte, 14 components, 14 bytes)" is added to the value 👍

[boan-jfm]

I added getFields() to git master php-vips:....

@jcupitt Will there be a 2.3.0 release with the new getFields feature, right now it is only on the master branch?

[jcupitt]

I usually let a few features build up. You can just depend on -dev in your composer.json in the meantime, I think.

[boan-jfm]

But if you use this feature in production and set the minimum-stability to "stable packages", you encounter issues. I do not think it is recommended to depend on the 'master' branch. If you run a composer update, you will not have control over major (breaking) or minor (non breaking) versions, which could potentially break your system.

This defines the default behavior for filtering packages by stability. This defaults to stable, so if you rely on a dev package, you should specify it in your file to avoid surprises.
-- https://getcomposer.org/doc/04-schema.md#minimum-stability

You have infinite numbers, why save them? 😊Are there any new features in the pipeline to be released in the near future?

[jcupitt]

Ah true, I just try to avoid very frequent updates, no one likes unnecessary churn.

I'll tag it as 2.3.0.

[jcupitt]

OK, v2.3.0 tagged.

[boan-jfm]

🙏