Media: expose image_strip_meta and image_max_bit_depth in the REST API index for client-side media processing

[adamsilverstein]

When client-side media processing is active, image decoding, scaling, and encoding happen in the browser, so no server-side WP_Image_Editor is ever instantiated. A hooks audit (​Gutenberg #80210) found that several server-side image-processing filters therefore never influence generated images. Two of them can be reconciled by exporting their filtered values to the client:

• image_strip_meta — plugins use this to keep metadata on resized images. On the client path, generated sub-sizes currently always strip everything except color profiles, ignoring the filter.
• image_max_bit_depth — plugins use this to cap the bit depth of generated images, relevant for 10/12-bit HDR AVIF sub-sizes. On the client path the source bit depth is always preserved, ignoring the filter.

The proposed change exposes the filtered values of both hooks on the REST API index inside the existing client-side media processing block in WP_REST_Server::get_index(), alongside the already-exported image_size_threshold:

• image_strip_meta (boolean, default true)
• image_max_bit_depth (integer, default 16)

Because the server never decodes the image on this path, image_max_bit_depth is applied with 16 (the maximum depth the client encoder can produce) as both the value and the current depth; plugins lowering the cap (e.g. to 8) still take effect on client-generated images.

The client-side consumption of these values (settings plumbing and the wasm-vips encoder honoring them) ships via the Gutenberg package updates in ​Gutenberg PR #80218.

Related hooks that cannot be reconciled (wp_image_editors, image_memory_limit, image_make_intermediate_size) are being handled as documentation in the client-side media docs (​Gutenberg #80216).

PR: ​wordpress-develop PR #12508

Core backport of the server-side changes in ​https://github.com/WordPress/gutenberg/pull/80218.

On the client-side media processing path no server-side WP_Image_Editor is instantiated, so the image_strip_meta and image_max_bit_depth filters never influence generated images (see the hooks audit in ​https://github.com/WordPress/gutenberg/issues/80210 and follow-up ​https://github.com/WordPress/gutenberg/issues/80216).

This exposes the filtered values of both hooks on the REST API index inside the existing client-side media processing block in WP_REST_Server::get_index() (alongside image_size_threshold), so the client encoder can honor them:

• image_strip_meta (bool): when a plugin disables stripping, the client keeps all metadata on generated sub-sizes instead of stripping everything except color profiles.
• image_max_bit_depth (int): caps the bit depth of client-generated images (relevant for 10/12-bit HDR AVIF sub-sizes). Since the server never decodes the image on this path, the filter is applied with 16 as both the value and the current depth; plugins lowering the cap still take effect.

The client-side consumption of these values ships via the Gutenberg package updates (@wordpress/vips, @wordpress/upload-media, editor settings plumbing) in ​https://github.com/WordPress/gutenberg/pull/80218.

[soyebsalar01]

I reviewed and tested the patch. The changes worked as expected, and the REST API now exposes the required values correctly for client-side media processing. I also didn't encounter any issues while testing, and everything appears to be functioning as intended. This looks like a good improvement. Thanks for the patch!

Upstream PR has merged, this should be ready.

[adamsilverstein]

Thanks for reviewing @soyebsalar01!

[fatimatd]

Manual Test Report

I tested PR #12508 using WordPress Playground.

Test Environment

• WordPress: trunk with PR #12508
• Environment: WordPress Playground
• Browser: Google Chrome
• Operating system: Windows

Test Method

I checked the REST API index using wp.apiFetch().

I also used a temporary test plugin to modify the following filters:

• image_strip_meta
• image_max_bit_depth

Before the Patch

On an unpatched WordPress trunk Playground, the REST API index returned:

image_strip_meta: undefined
image_max_bit_depth: undefined

This confirmed that the two properties were not exposed before the proposed change.

After the Patch

On the Playground generated from PR #12508, the default REST API index values were:

image_strip_meta: true
image_max_bit_depth: 16

After applying custom filter values, the REST API index returned:

image_strip_meta: false
image_max_bit_depth: 8

Result

The PR works as expected in my manual testing.

The new REST API index properties are present with their expected default values, and both properties correctly respect values supplied through their corresponding filters.

[fatimatd]

Manual Test Report

I tested PR #12508 using WordPress Playground.

Test Environment

• WordPress: trunk with PR #12508
• Environment: WordPress Playground
• Browser: Google Chrome
• Operating system: Windows

Test Method

I checked the REST API index using wp.apiFetch().

I also used a temporary test plugin to modify the following filters:

• image_strip_meta
• image_max_bit_depth

Before the Patch

On an unpatched WordPress trunk Playground, the REST API index returned:

image_strip_meta: undefined
image_max_bit_depth: undefined

This confirmed that the two properties were not exposed before the proposed change.

After the Patch

On the Playground generated from PR #12508, the default REST API index values were:

image_strip_meta: true
image_max_bit_depth: 16

After applying custom filter values, the REST API index returned:

image_strip_meta: false
image_max_bit_depth: 8

Result

The PR works as expected in my manual testing.

The new REST API index properties are present with their expected default values, and both properties correctly respect values supplied through their corresponding filters.

[adamsilverstein]

In 62806:

Media: Expose image_strip_meta and image_max_bit_depth in the REST index.

When client-side media processing is active, image decoding, scaling, and encoding happen in the browser, so no server-side WP_Image_Editor is instantiated. As a result the image_strip_meta and image_max_bit_depth filters never influence generated images, and plugins relying on them have no effect on client-generated sub-sizes.

Expose the filtered values of both hooks on the REST API index inside the existing client-side media processing block in WP_REST_Server::get_index(), alongside the already-exported image_size_threshold, so the client encoder can honor them. The client-side consumption of these values ships via the Gutenberg package updates in ​https://github.com/WordPress/gutenberg/pull/80218.

Props westonruter, soyebsalar01.
Fixes #65623.