Zenn
Open16

Cloudinaryを試してみる

katzumikatzumi

https://cloudinary.com/

サクッとサインインしてみた

試しにファイルをアップロードしてみる

Security設定で Restricted media types で Fetched URL にチェック
Allowed fetch domains に * を指定してみて

https://res.cloudinary.com/{cloud-name}/image/fetch/{fetch-url}

でアップロードされるか？確認してみた。
→　結果駄目だった。401

ワイルドカード指定が駄目なのか？
URL Fetchは別途行ってアップロードしてから加工するのがいいみたい

katzumikatzumi

consoleのUIからは色々なアップロードの方法がある
これ全部APIとかで使えたりしないよね？
URLだけ渡してフェッチしてもらえるだけでもありがたいけれど
Image Search使えたら凄そうだけれどもｗ

katzumikatzumi

ぱらぱらとAPIのドキュメント見た感じだと、URL（http(s),FTP,S3)を直接渡してuploadは可能だが、他のソース？からアップロードするI/Fはなさそう

katzumikatzumi

SDK使えば楽だけれども、今回検討している環境ではSDK使えないので直接API呼び出しを行う方法を調べる

https://cloudinary.com/documentation/upload_images#uploading_with_a_direct_call_to_the_rest_api

こちらがドキュメント

file - The file to upload. Can be the actual data (byte array buffer), the Data URI (Base64 encoded), a remote FTP, HTTP or HTTPS URL of an existing file, or a private storage bucket (S3 or Google Storage) URL of a whitelisted bucket.

直接URLでも大丈夫そう。
ホワイトリストの指定が必要なのはS3バケットのみかな？

アップロードしつつ画像加工って出来るのかな？

katzumikatzumi

画像の変換してもオリジナルの画像は残したままな設計っぽい
オリジナル画像と変換後の画像も含めてストレージ課金対象になる
画像最適化してダウンロード、再アップロードしてオリジナル画像を削除する感じはできなくもなさそう
まあそこまで行うなら、最適化した画像を別途S3に保存したほうが、帯域使わなくて良さそう

katzumikatzumi

upload時に eager しか使ってなかったけれど、transformationがあった。
これが使えるのかな？

katzumikatzumi

API呼び出しできた
2パターンの実装がある

  1. 署名付き（認証)リクエスト
  2. 署名なし（認証なし）リクエスト

署名付きはapi_key, timestamp, signatureが必要
signatureは署名対象のパラメータ(timestamp含む)とAPI secretを使ってSHA1ダイジェストを作る
timestampの１時間以内な有効な署名（リクエスト）になる

詳細は こちら。まあSDKを使えば勝手に署名して貰えるのでほとんどの人は意識しなくても良いｗ

署名なしはapi_keyとか不要。ただしupload_presetが必要になる
管理画面やAPIからUnsignedモードのupload_presetを事前に登録させてそれを指定させる必要がある
アカウント発行直後はUnsignedモードのupload_presetが登録されてないので登録する必要がある
認証がない分制約がある模様。発行されるupload_presetの名前もランダムで生成されている
Webフォームから直接アップロードさせるユースケースを想定しているみたい

レスポンスは以下のような感じ

interface UploadResponse {
  asset_id: string;
  public_id: string;
  version: string;
  version_id: string;
  signature: string;
  width: number;
  height: number;
  format: string;
  resource_type: string;
  created_at: Date;
  tags: string[];
  bytes: number;
  type: string;
  etag: string;
  placeholder: boolean;
  url: string;
  secure_url: string;
  original_filename: string;
  api_key?: string;
}

secure_urlがhttpsでアクセスするURLなので、アップロード後はこちらのURLを使えばよい

katzumikatzumi

画像変換試してみる

どんな変換がざっくりできそうか？こちらの記事がイメージ付きやすい
https://speakerdeck.com/shimizutoshiya/akiba-dot-aws-number-12-cloudinarydehua-xiang-yadong-hua-pei-xin-wozui-shi-hua-siyou-deiripotaruzdefalsecloudinarydao-ru-nixiang-ketefalsejian-zheng-nituite
より詳細に実例をまとめてくれている生地
https://qiita.com/kanaxx/items/d098ef82a19ff1061f46

今回は大きすぎる画像の場合のリサイズ（アスペクト比はいじらず、いい感じのサイズにしたい）とテキスト埋め込み

まずはリサイズは

c_limit,w_400,h_400

で良さそう。
これで縦横400picより大きい場合は、比率が大きい辺をベースに縮小のみしてくれる

API直接呼び出しを行う場合は eager パラメータをつけると良さそう
呼び出すとレスポンスに eager のオブジェクトで変換後のURLのリストが追加される

interface Transformation {
  transformation: string;
  width: number;
  height: number;
  bytes: number;
  format: string;
  url: string;
  secure_url: string;
}

interface UploadResponse {
  asset_id: string;
  public_id: string;
  version: string;
  version_id: string;
  signature: string;
  width: number;
  height: number;
  format: string;
  resource_type: string;
  created_at: Date;
  tags: string[];
  bytes: number;
  type: string;
  etag: string;
  placeholder: boolean;
  url: string;
  secure_url: string;
  original_filename: string;
  eager?: Transformation[];
  api_key?: string;
}

オリジナルのファイルは残る。
ダイナミックにURLにパラメータをつけて変換する場合とURL体系は変わらないっぽい。
あえて eager にしなくても良さそうだけれども事前に変換してくれてすぐにURLアクセス可能な感じになるのかな？
eager パラメータは | 区切りで指定できるっぽいけれど、多分これは複数画像をオーバーレイさせる際にそれぞれtransformさせる場合に使うのだろうと思う（未確認）

katzumikatzumi

eager パラメータは | 区切りで指定

これ一つの画像に対して | 区切りで2つ変換を記載したら2バージョンのURLができた
レスポンスの eager のオブジェクト配列が2つになった

katzumikatzumi

料金体系
https://cloudinary.com/pricing

freeプランだと以下の利用についてクレジット分利用できる（2021/08/12時点）

25 Monthly Credits

25k transformations or
25 GB of managed storage or
25 GB of net viewing bandwidth

詳しくまとめてくれている記事
https://qiita.com/kanaxx/items/36a47faa950659190a1d

変換のみ使いたい場合でも、ストレージと帯域がかかってしまうので何かしらの対応は考えたほうが良さそう

  • 変換後の画像をダウンロードしてcloudinary以外から配信させる。
  • 変換画像をダウンロード後にファイルを削除する

など。

katzumikatzumi

テキストオーバーレイまわり

https://cloudinary.com/documentation/transformation_reference#l_text

基本的な構文は以下の感じ
l_text:<text style>:<text string>

URL上で変換パラメータを指定するのはサイズ変換と同じ。public_idのパスの前で指定する

https://res.cloudinary.com/${CLOUDINARY_CLOUD_NAME}/image/upload/${transformation}/${public_id}.${format}

l_text:Helvetica_70_bold_underline_letter_spacing_30:テキスト

テキストのスタイルは _ でつなげて記載する感じ
いい感じにテキストをパースして意味を汲み取ってくれている。個人的にパーサーが気になって仕方がないｗ
Helveticaはフォント名だが、各種フォントを使える。google fontにあるやつなら使える模様。
なくてもフォントファイルをアップロードしておいてそれを呼び出すこともできるというドキュメントは見かけた（リンク失念）

こちらのドキュメントを見たほうが良い
https://cloudinary.com/documentation/layers#text_overlays

テキストの色を付ける場合はl_textの前に co_rgb:ffff を入れる（区切りはカンマ）
特に色を指定しない場合は黒になった。
テキストの色やフォントサイズを変えて複数テキストを入れる場合

co_rgb:ffff,l_text:Helvetica_70_bold_underline_letter_spacing_30:TITLE/g_center,y_50,co_rgb:0000,l_text:arial_25:description

スラッシュをつけて記述を分けてあげる

スラッシュをつけて多段的に変換が可能
例えば、オーバーレイさせたテキストに影をつけるとか

co_rgb:ffff,l_text:Helvetica_70_bold_underline_letter_spacing_30:TITLE/co_gray,e_shadow,x_5,y_5/fl_layer_apply

これでTITLEという文字に影がつく
注意点として、スラッシュで複数変換処理を行っていった際にどこでレイヤーを統合させるか？というのがある。
多段フィルターっぽく動くので、前の変換処理が後で指定した変換処理にも影響がでてしまう。
それを制御する為にfl_layer_applyをつける必要がある。
ない場合に画像全体に影がついてしまう

katzumikatzumi

fl_layer_applyを使う場合、もう一つ注意

続けて変換処理が書けるけれど、applyした時点でTransformationsのカウント対象になる