見出し画像

noteにGIFが貼れない。犯人は容量じゃなかった話

「noteにGIFを貼ろうとしたら、エラーが出て貼れない…」
そんなこと、ありませんか?

こんにちは。Kyosukeです🐸

今日は、私が半日まるごとハマった「noteにGIFが貼れない問題」の話をします。

パソコンの裏側に出てきたエラーの文章を、そのまま信じて。 関係のないところをずーっといじって。 最後の最後で「あ、そこじゃなかったのか」となった。

そういう、間抜けだけど、たぶんnote民の誰かの役に立つお話です。

先に、いちばん持って帰ってほしいところだけ置いておきます。



【結論】 noteの本文に貼るGIFの本当の壁。

noteの本文に貼るGIFの本当の壁は、ファイルの重さ(MB)ではありません。

「画面の大きさ×コマ数」の合計と、「コマ数そのもの」です。

これだけ覚えて帰ってもらえれば、もう同じところで詰まりません。
…と言われても、まだピンとこないですよね。

なので、ひとつだけ、頭の隅に置いてほしいイメージがあります。
GIFは、パラパラ漫画です。

ノートの端っこに絵を描いて、めくると動いて見える、あれです。
この「パラパラ漫画」のイメージさえ持っていれば、今日の話は全部つながります。

では、犯人探しのはじまりです🐸



まず、何が起きたのか

noteの下書きにGIFを入れようとすると、エラーが出て貼れませんでした。

エラー内容

英語で長々と出てくるんですが、ざっくり訳すとこうです。

「別の場所にあるデータを取りに行こうとしたので、ブラウザが安全のために止めました」

CORSエラー

これは「CORS(コルス)エラー」と呼ばれるものです。
むずかしく聞こえますが、要はこういうことです。

CORS = よそからデータを勝手に持ち込ませないための、受付の門番。

知らない相手からの荷物は、いったん「はい、ちょっと待って」と止める。 そういう、まじめな門番だと思ってください。

英語でずらっと出てくる。心臓に悪いやつです。

あばけろ君🐸「じゃあ、その門番が厳しすぎて、GIFを追い返してるってこと?」

私も最初はそう思いました。
思ったんですが。



犯人だと思った門番は、無実だった

念のため、noteの受付に、自分で直接データを届けて確かめてみました。

すると。
門番、普通に受け取ってくれるんです。

3.6MBのそこそこ重いデータを渡しても、ちゃんと「はい、どうぞ」と通してくれる。

つまり、門番(CORS)はちゃんと仕事をしていて、note側は「いいですよ」と言っている。

犯人だと思っていた門番は、無実でした。
ここが今日いちばんの落とし穴です。

エラー画面には「CORS」と書いてあるのに、本当の犯人は別にいる。
うまくいかなかったときの反応が、たまたま門番のせいに見えていただけだったんです。

エラーの文字は、たまに嘘をつきます。

正確には嘘じゃないんですが、「本当の原因」と「画面に出る文字」がズレることがある。 これ、パソコンあるあるです。

…ちなみに私はこのあと小一時間、まったく関係ない容量削りをしていました。

書いてて、ちょっと悲しくなってきました(笑)



本当の犯人を、追い詰める

やり方を変えました。 条件を1個ずつ変えながら、通る・通らないを地道に試していきます。

まず、動かないふつうの静止画(PNG)を入れてみる。 これはすんなり通りました。

ということは、動かない画像はOK。 GIFだけがダメ。GIFの「動く」何かが引っかかっている。

次に、GIFの容量を削ってみました。 色数を減らして、2.5MBまで軽くする。 …それでも、ダメ。

ここで容量(MB)は、犯人リストから外れました。

じゃあ何が効いているんだ、と。 今度は「画面の大きさ」と「コマ数」を1つずつ動かして、記録していきました。

そうして浮かび上がったのが、これです。

通ったGIF: 640×360で316コマ/480×270で330コマ/400×225で330コマ
落ちたGIF: 640×360で330コマ/345コマ/359コマ

よく見てください。

画面が小さいと、コマ数が多くても通っている。 画面が大きいと、同じコマ数でも落ちている。

ここで、ようやくピンときました。

効いていたのは「画面の大きさ×コマ数」だったんです。



パラパラ漫画で考えると、全部つながる

さあ、最初のイメージの出番です。
GIFは、パラパラ漫画でしたよね。

1枚1枚の絵が「コマ」。 これをめくると、動いて見える。
そして1枚の絵は、細かいマス目(ドット)でできています。

1枚のマスの数 = 横のドット数×縦のドット数 パラパラ漫画ぜんぶのマスの数 = 横×縦×コマ数

noteは、この「ぜんぶのマスの数」に上限を置いていました。

私の実測では、7300万マスあたりに壁がありました。
640×360で316コマ(約7280万マス)は通って、330コマ(約7600万マス)で落ちました。
その間のどこかに、線が引かれています。
(7000万マスって想像つかないですよね。私もです。要は「大きい絵を、たくさんの枚数ぶん重ねると、あるところで重すぎになる」くらいの感覚でOKです)
なので狙うなら、6000万マスくらい。壁の少し手前に置いておくと安心です。

しかも、壁はもう1つありました。

「コマ数そのもの」にも上限がありそうで、私の環境では330枚あたりが打ち止めでした。
(ただし330枚より多いコマ数を試したのは640×360だけなので、画面を小さくすればもう少し粘れるかもしれません。他の方の検証では「400枚前後」という話も見かけました)


つまり、通せんぼが2つある。 「ぜんぶのマスの数」と「コマ数」。 どちらか一方でも超えたら、アウトです。

容量(MB)を削っても通らなかった理由も、これで説明がつきます。 色を減らしてファイルを軽くしても、マスの数もコマ数も、まったく減っていなかったんですね。



だから、貼れるGIFはこう作る

私がたどり着いた、実用の目安です。

「横×縦×コマ数」を、だいたい6000万以下に収める。 コマ数は、330枚以下にする。 640×360のサイズなら、なめらかさ(fps)は18〜20くらいまで。


fps(1秒あたりのコマ数)は、多いほど動きがなめらかになります。 でも、多いほどマスの合計も増えてしまう。 なめらかさを取るか、通りやすさを取るか。 ここは、ちょっとしたシーソーです。

そして、いちばん大事なことを、もう一度だけ。

詰まったときに「容量を減らそう」としないでください。

これが今日いちばんの罠です。 ファイルを軽くしても、マスの数とコマ数は変わらないので、やっぱり通りません。

なめらかさを優先したいなら、画面の大きさ(解像度)を少し小さくする。 画面の大きさを守りたいなら、fpsを少し落とす。

削るのは、MBじゃない。 「画面の大きさ」か「コマ数」です。



実はちょっと厄介な真実

上限ギリギリを攻めると、同じ設定でも通ったり落ちたりします。 実際、境界ちょうどのGIFは、一度は通ったのに、作り直したら落ちました。

これはズルい。。。(笑)

なので、ギリギリを狙わない。 少し余裕を持たせて、18〜20fpsあたりの安全地帯に置いておく。 これが、いちばん心穏やかでいられます。



おわりに

ここまで読んでいただき、ありがとうございます。

今日の話、技術の話に見えて、じつは教訓は1個だけです。
エラーの文字を、鵜呑みにしない。

画面に書いてある犯人(CORS)が、本当の犯人とは限らない。 1個ずつ条件を変えて確かめていくと、本当の原因がちゃんと顔を出します。

これ、GIFに限らず、パソコンで詰まったときに丸ごと効く考え方です。

そして今日の犯人は、容量じゃありませんでした。 「画面の大きさ」と「コマ数」です。

「noteにGIFが貼れない」で検索して、いままさに容量を削り続けている人に、これが届いたら嬉しいです。

ちなみに私は、この手のnote用GIFを、自作の画面録画アプリ CaptureApp(買い切り1,980円・Windows・30日返金保証)で作っています。
今回のGIF書き出しの機能を追加したらnote決済版もリリース予定です。
たぶん最初はお得にします。


「録って、隠して、貼る」までを1本で済ませたくて作ったアプリで、容量だけじゃなく、貼りやすい画面サイズまで整えてくれます。

今回の「マス目×コマ数」の考え方も、これから書き出しに活かしていくつもりです。

サクッと動画をGIFにしたいだけなら、ブラウザだけで変換できる無料ツール Movie to GIF も置いてあります。 (動画をサーバーに送らず、自分のパソコンの中だけで変換できます)



不定期で、AIやWebに関する情報や、便利なアプリを紹介しています。 よければLINE公式の登録もお待ちしております✨

クリックして登録


それではまた😌🐸

いいなと思ったら応援しよう!

Kyosuke(みんなのWeb屋さん) よろしければ応援お願いします!いただいたチップは、よりよい記事づくりのために大切に使わせていただきます🐸