WooCommerce ships its own image-size controls under Customize, WooCommerce, Product Images : a catalog image size (324 × 324 pixels by default) used on shop and category archive pages, and a single product image size (800 × 800 pixels by default) used on the product gallery. These settings feed WooCommerce's own image-size registration, which WordPress then uses to generate a matching thumbnail file at upload time, the same static, upload-time mechanism WordPress core uses more generally.
Once ImagePipe presets are active on a given placement, that mechanism no longer determines what the visitor actually sees. A preset such as product_card for the catalog grid or product_page for the gallery already carries its own dimensions, resize mode and quality settings, applied at request time regardless of the size WordPress registered for that image slot. Changing the Customizer's 324 × 324 value has no effect on a covered placement, because the image actually served never passes through that registered size.
The setting is not disabled by ImagePipe, which is precisely what makes it a trap : it stays visible and editable, still applies wherever the theme has not routed through a preset, and can mislead a store owner into believing a size change there will resize the catalog, when only the uncovered placements actually react.
Check first, in the ImagePipe settings, which placements are actually covered by a preset, since that determines whether a given Customizer field still does anything. Check next whether the catalog or gallery images already look correctly sized once a preset is enabled, rather than adjusting the Customizer values to compensate. Leave the native WooCommerce fields at their defaults on covered placements, and reserve them for the parts of the theme a preset does not touch.