<p>The methods check if either ImageMagick and/or GD are installed and have been compiled with support for the respective format. If they return true, you can create transforms using these formats safely.</p>
<p>You can access the <code>craft\web\Application</code> instance through the <code>craft</code> variable available to all Twig templates. <code>craft.app</code> in Twig is equivalent to <code>\Craft::$app</code> in PHP. From there you can just use the handle mentioned for this component in the <a href="https://docs.craftcms.com/api/v3/craft-services-images.html" rel="nofollow noreferrer">API reference</a>:</p>
<pre class="lang-twig prettyprint-override"><code>{% if craft.app.images.getSupportsAvif() %}
    &lt;source srcset=&quot;{{ asset.getUrl({ format : 'avif' }) }}&quot; type=&quot;image/avif&quot; /&gt;
{% endif %}
</code></pre>
<hr />
<p>On a broader note, instead of checks like this, it's better to make sure your production environment is identical with your dev environment. This way, you avoid headaches debugging error coming from small differences between environments. You can even encode server requirements for your project in your version control to enforce those constraints; for example, you can <a href="https://getcomposer.org/doc/01-basic-usage.md#platform-packages" rel="nofollow noreferrer">list required PHP extensions</a> in your <code>composer.json</code> to make sure either GD or ImageMagick are installed. You could even use a <a href="https://getcomposer.org/doc/articles/scripts.md" rel="nofollow noreferrer">pre-install script</a> that checks for AVIF support in the installed GD/ImageMagick extensions and throws an error if it's missing.</p>
<p>Of course, this advice doesn't apply if you're building a plugin that needs to work in different environments.</p>

CC BY-SA 4.0
2022-02-01T13:34:38.640Z
Thank you sir! Not exactly a plugin, but a utility we use on a regular basis for generating picture elements with various formats. Not all of our sites are hosted on our servers where we can control which extensions are installed, and since image format support varies by browser it's not a "requirement" per se that all environments be consistent in this aspect.
jrrdnx
CC BY-SA 4.0
2022-02-01T12:23:19.307Z
2022-02-01T12:23:19.307Z
MoritzLost
<p>Before attempting to perform an asset transform to an AVIF or WEBP format, I'd like to use <a href="https://docs.craftcms.com/api/v3/craft-services-images.html" rel="nofollow noreferrer">Craft's Images service</a> to determine if the server actually supports either of those formats like so:</p>
<pre><code>&lt;picture&gt;
    {# Attempt ONLY if craft\services\Images-&gt;getSupportsAvif() #}
    &lt;source srcset=&quot;{{ asset.getUrl({ format : 'avif' }) }} type=&quot;image/avif&quot; /&gt;

    {# Attempt ONLY if craft\services\Images-&gt;getSupportsWebP() #}
    &lt;source srcset=&quot;{{ asset.getUrl({ format : 'webp' }) }} type=&quot;image/webp&quot; /&gt;

    &lt;img src=&quot;{{ asset.getUrl() }}&quot; /&gt;
&lt;/picture&gt;
</code></pre>
<p>Attempting to perform either of those transforms when the server doesn't have the appropriate plugins/packages installed results in <code>AssetTransformException: Failed to generate transform</code>.</p>
<p>Unless I'm misunderstanding those methods and they're only returning whether or not Craft and/or the Images service supports those formats, and not the server itself. If this is the case, is there another way to determine support programmatically?</p>

<templating><services>
Is it possible to access a Craft service directly from a Twig template?
# Is it possible to access a Craft service directly from a Twig template?

(Asked by: username_0 on 2022-02-01)

Before attempting to perform an asset transform to an AVIF or WEBP format, I'd like to use Craft's Images service to determine if the server actually supports either of those formats like so:

    {# Attempt ONLY if craft\services\Images->getSupportsAvif() #}
    

    {# Attempt ONLY if craft\services\Images->getSupportsWebP() #}
    

    


Attempting to perform either of those transforms when the server doesn't have the appropriate plugins/packages installed results in AssetTransformException: Failed to generate transform.
Unless I'm misunderstanding those methods and they're only returning whether or not Craft and/or the Images service supports those formats, and not the server itself. If this is the case, is there another way to determine support programmatically?

**Tags:** templating, services


---

## 1 answers

### Answer by username_1 on 2022-02-01. Score: 3 | Accepted answer

The methods check if either ImageMagick and/or GD are installed and have been compiled with support for the respective format. If they return true, you can create transforms using these formats safely.
You can access the craft\web\Application instance through the craft variable available to all Twig templates. craft.app in Twig is equivalent to \Craft::$app in PHP. From there you can just use the handle mentioned for this component in the API reference:
{% if craft.app.images.getSupportsAvif() %}
    
{% endif %}


On a broader note, instead of checks like this, it's better to make sure your production environment is identical with your dev environment. This way, you avoid headaches debugging error coming from small differences between environments. You can even encode server requirements for your project in your version control to enforce those constraints; for example, you can list required PHP extensions in your composer.json to make sure either GD or ImageMagick are installed. You could even use a pre-install script that checks for AVIF support in the installed GD/ImageMagick extensions and throws an error if it's missing.
Of course, this advice doesn't apply if you're building a plugin that needs to work in different environments.

> **Comments:**
> **username_0**: Thank you sir! Not exactly a plugin, but a utility we use on a regular basis for generating picture elements with various formats. Not all of our sites are hosted on our servers where we can control which extensions are installed, and since image format support varies by browser it's not a "requirement" per se that all environments be consistent in this aspect.  

---

