「WebP」を含む日記 RSS

はてなキーワード: WebPとは

2024-05-26

anond:20240524180729

え?ネット上の画像はどんどんwebpやavifに置き換わってる気がするけど

これから時代が逆戻りすることはないのでは

2024-03-02

anond:20240301171143

WebP の 1/10 で済むみたいな話しならみんな熱心に研究したでしょうけど、

WebPとは異なるアーティファクトがでる上に、ちょっとしかサイズが変わらないのでは、

実用性が低すぎるわ

2023-10-20

じふぎふ戦争webpが終わらせた

未だにR,G,B255とか再生紙のチラシかよw32bit浮動小数使えw

2023-07-20

webp形式対応してくれ!

はてなブログは未だに優れた画像形式であるwebp対応していない。

主要ブラウザは全て対応している。画像が軽くなるのでサーバー負担の軽減にもなるだろうに

2022-02-20

毎日新聞漫画 桜田です!がwebpになってた

ちょっと前はjpgだったのに。

時代の流れを感じる。

2021-06-11

webp うざい

webp うざい

webp うざい

webp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざいwebp うざい

2021-06-01

ぼく氏「IE11がついにサポート終了となる。これでWebPを心置きなく使えるようになるのだ」

彼ら「macOS CatalinaまでのSafariではまだWebP対応してない」

ぼく氏「!?

その日、人類は思い出した

まだ「Safari」が残っている恐怖を

2020-12-02

IT(?)に立ち向かうための心構えとか考え方

anond:20201130214610

いろいろ面白かったので、適当に回答する。

> 1.具体的な事が分からない

プログラミングで主にやる事は下記の2つ。

①IFでAかBを選択させてどっちかの設定を実行

②Whileで決められた回数分繰り返す

これでやりたいことは分かる。分かるけれどこれでどうやって動画音楽エンコードをしたり

画像処理をしたりするソフトウェアになるのかというのがよく分からない。

とてつもなく複雑で冗長な処理によって実行されている。

複雑すぎて人間直感理解することは不可能だ。

わかりやすいので画像処理でいうと、数十万から数百万の画素(RGBAの24bitで表される数値)を小さなブロックに分解し、数学的に周波数の重なりとして計算して変換、含まれる頻出パターンテーブルにして圧縮伸張を行なう。みたいなことが瞬間的に行われている。

まさかそんな事できるわけないだろ」というレベルの処理が実際に行われており、これまた直感的でない。

適当リンクを挙げる。

からそれをどう書くんだよ。という答えはコレ。有名なjpeg実装だ。


フレームワークだとかよく分からないものを持ってきて使ってくださいってなっている。

libjpeg というライブラリを書くことはできるだろうか?画像圧縮理論から考え始めることはできるか?

正直無理だ。自分プログラマだがそんなに数学が得意ではなく、頑張ったとしても下手するとコレを作るのがライフワークになってしまい、他のことができなくなる。

例えばブラウザを0から作るとして、jpegの処理以外にも画像だけでpngとかgifとかwebpとか、その他もろもろとてつもない作業必要になる。

「とてつもなくて想像もできないので流石に無理だろう?」

いや、でも、実際動いてるのよ。ここ何十年、コツコツと積み重ねて実現している。

「積み重ね」とはライブラリであったりフレームワークであったりOSであったりする。

からそのフレームワークがどういう風になっているのかって説明からして欲しいって思う。

「どういう風になっているのか」

多くの場合、內部の実装に関しては詳しく知る必要はない。

外部に向けたインターフェイスがどうなっているのかは理解する必要がある。「使う」ために必要からだ。

この2つは分けて考えなければならない。

これでどうやってゲームを作ったり、検索エンジンを作ったりするんだとなってくる。

ちなみに、たとえばChromeのコアであるChromiumはのコードはコレだ。


まり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず

プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。

これがもう滅茶苦茶イライラする。

「これで判定と繰り返しという基礎ができます」というのが基本的理論定理的なもの)で、その他に必然的だが唯一無二ではないベストプラクティスというものがある(法則的なもの)。

後者をうまく説明する入門書出会っていないんだろうな。という印象。イライラはやめよう。つかれる。

ベストプラクティスはいろいろあるのだが「層の構造にする・レイヤーに分ける」というのは重要アイデアだ。

libjpegというのはjpegの処理を行う「ライブラリ」だ。他のアプリケーション...たとえばブラウザはこのライブラリを「使う」。

ブラウザではjpeg画像圧縮展開というとてつもなく難しい処理を「libjpegの使い方」の理解までで済ませ、過去の蓄積であるlibjpegコードを利用することで真の意味で0から実装しないようにしている。

この場合、libjpegが「低レベル・低レイヤー」の存在であり、中身については「使い方」つまり仕様」の理解までしか行わないことで、実際に作りたいものを作れるようにしているわけだ。

巨人肩に乗る」とよく言われる。

まり完成しているプログラムを参考にしようと思っているにも関わらずそれがないのでよく分からない。

完成しているプログラムは二例ほど挙げたがどうですかね?

複雑なことをする、特にレイヤーコードはとてつもなく難しい。

でも、とりあえずこんな感じのコードなら解るよね?

こういうレベルから理解して、ちょっとずつ難しい処理を学んでいくしかない。

から木材を渡されてこれで家を作れと言われるくらいハードルが高い。

ハードルは高いんですよ。実際。

なので、木材からだと難しいかプレハブのキット的なものを探すとか、ログハウスカタログを読むとか、あるいは100人乗れる物置を買うのがいいかもしれない。そういうところから始める。

それらがフレームワークであったりライブラリであったりする。目的に合うものを探して、自分がやりたいことをどう実現するかとにかく考える。

「テキシコーhttps://www.nhk.or.jp/school/sougou/texico/ で言われる通り、「小さく分けて考える」「手順の組み合わせを考える」「パターンを見つける」「大事ものだけ抜き出して考える」「頭の中で手順をたどる」をひたすら実行する。

ゲーム作りにはそういうアプリを使えば楽だからそれを使えという人もいる。Unity?だっけ。

でもそれはそれ。そうじゃなくてプログラミングでどうやってそれが作られているのかが分からない。

unityコードが公開されているので、本当に読みたいなら。。


なぜそこでオブジェクト指向になるのかが分からない。

オブジェクト指向は内部構造を知らなくても直感的に利用できる素晴らしいものだとは思う。

オブジェクト指向は一旦忘れよう。

オブジェクト指向の「隠蔽」というのは層の構造が持っている重要な要素ではあるけど、「低いレイヤーについて考えない」のが基本的作戦だという理解の方が重要だ。

が、プログラミングでは、その内部構造を作らなきゃいけないのだからそれを知る必要がある。

前述の通り「できる限り作らない」んですよ。「使う」だけ。知るべきことを最小化する。

巨人肩に乗り、車輪の再発明基本的に避ける。

そして本当に作るべきものに関しては、利用する下のレイヤーライブラリなりを探して・仕様理解して、どう組み合わせてfor, if, あるいは計算させれば実現できるのかをひたすら考える。

じゃあ具体的に何を作りたいのかというと、英語フリーソフト言語表示を日本語翻訳するソフト

単に翻訳がしたいのか?表示に割り込む方法を知りたい?日本語翻訳するのは実行時なのか開発時なのか?

要求される表示エリア言語によって異なるために、デザイン調整が必要になる問題をどうするか?

解決したい問題もっと分解したほうがいい。

分解が甘いので何をしたらいいか調べることができないんだと思う。

たまに便利なフリーソフト海外版の時があるんだけれど、日本語化が出来ない事があるので、自分自由

日本語化できるようにできれば凄くストレスが減る。だからやりたいのだけれどそういうのがよく分からない。

ちなみに、アプリ内の文言というのはアプリの外部から変更できないように実装されている事が多いので、利用者が上書きする仕組みはかなり難しい。

AndroidなりiOS仕様にもそのへんに割り込める機能はないはずなので、OSの開発に入っていく必要がある。結構大変だとおもう。

アプリ開発者が、そういう機能を備えた多言語化のためのライブラリを使うようになれば実現可能ではあるので、そっちの方向で頑張るのがおすすめだが、英語圏の開発者には多言語化のモチベーションが低いという基本的問題はあるのよね。

この辺の「できる・できない・むずかしい」の判断は、いろいろな勉強をすると常識としてある程度みえてくる...気がする。

ついでに。ウェブサイトウェブサービス翻訳だとこういうサービスがあったりする。

ブラウザはページの描画処理のなかに割り込む余地が大きく取ってあるので、ブラウザのExtensionとかならできることがいくらかあるかもしれない。

> 2.説明が出来ても説明が出来ない

個人的に気に入らない話はOSアップデートは使いやすくなるからとてもいい事だからすぐにやった方がいいと宣伝されている事。

セキュリティが高まりますというのが宣伝文句だけれど、これで大体老人たちやIT知識に疎い人は躓く。

まあ、半分は嘘だよね。古いものが残っていると先に進めないんだよ...。

現在クライアントOSは、巨大なプラットフォームのパーツの一部として理解したほうが正しくて、古いパーツが残っているとツライんですよ。

そして「サービスを受けるための道具であって、あなたが何でも好きにできる機械ではないです」みたいな世界になりつつあって、ちょっと問題と言われてもいる。

これはかなり困った傾向なんだけど、全体としての流れはあんまり変わりそうにない。

たここでオブジェクト指向が出てくる。

オブジェクト指向好きですな...。ここではオブジェクト指向特に気にしなくていいですよ。

からパソコンはたまに不具合を引き起こすんですという説明が着地点になる。

とてつもなく複雑なことをやっているために、すべてのバグを潰すことはコストが高すぎてできないんですよね。

それよりバグ未来を先取りするコストと考えて、本質的価値のある機能を増やしていくというのが基本的な方向になっている。

からパソコンはたまに不具合を引き起こすんです。しゃーない。

しか中途半端理解している老人などは、そんなことじゃ分からん自分に分かるように説明しろと言い出す。

説明は出来る。しか相手イライラするし理解されない。よって説明をしてはいけないという状況に追い込まれる。

ここでどうすればいいのだと理解不能に陥る。

まあ、説明って得てして難しいよ。しゃーない。

何故なら自分OSアップデート不具合の原因というのが分からいから。

Microsoftが、Appleが、Googleがそうしているんですとしか言えない。

そのとおりです。

プログラムソースコードのどこかにエラーがあるのだろうけれど、どこにあるのかなんて当然知らない。

そもそもソースコードを調べるのは違法なのでやれないし。

オープンソースプロダクトなら原理的には調べられるけどね。Androidとかはオープンになってる。


だけどみんなそんなものを使っているし自分も使っている。正直こんなんでいいのか人類と思う事がある。

それを許容することで先に進んできているという事実は受け入れたほうがいいと思う。

「把握・理解可能範囲」に留めていたら、数十年前のコンピュータ世界から抜け出せなかった。

deep learning世界ではそれがより一層進むかも。この辺は詳しくないけど。

当然仕組みを理解している人はいるし、そんな人にとってみれば当然のことであっても、全ての中身を知っているわけではない。

どれだけ知っていても知らない事があるのがIT理解しがたい。理解が出来ない。

ここでの「理解」についてはそのとおり。これはもう諦めるしかない。

> 3.自分頭が悪い

これが常にある。IT関連は常に新しい情報が出てくるのでそれに送れると無知になってしまう。

なんでこんなことも分からないんだとか言われ放題で、IT系の企業に努めている人は常に新しい知識を入れられる

面倒くさがらない人が向いている。

「面倒くさがり」の方が問題に気づいて「頑張って面倒じゃなくする」ことができるので、プログラマにとっては美徳なんて言われますけどね。

同時にくじけないとか諦めない、しつこいみたいな素養必要かも。

表計算ならいけるんじゃないかと思ったときがあるのだけれど「射影」とかいきなり意味不明な言葉が出てきて、

勉強しろ

それから受験していない。だから持っているのはITパスポートだけ。情けない。

応用まではとろうな。がんばれ。

> 4.最後

USB-TypeCをTypeAに変換してはいけないとか最近まで知らなかった。

このへん自分も知らんですよ。べつに全部知っている必要はない。

面白いからたまに調べたりもするけど。

追記: はてな記法引用すらもさっきまで知らなかったしな!そんなもん)

更にレガシー、すなわち過去遺産なるものについても理解ができない。古い物がずっと使われ続けているIT環境

もう誰もメンテナンスが出来ないものが延々と使われているという事実

層の構造をとっているということと関係があるんですが、仕様が変わると、その上に乗っているものを全部なおさないといけないんですよね。

なので「互換性」というのが非常に重要なのです。

でも革新のために互換性を捨てなければいけないケースも多い。このへんはハードでもソフトでも同じ。

そして、メンテコストが上がっても使い続けたほうがトータルで安上がりという場合は、古いものが残ってしまう。

あるいは「(多少の問題はあっても)動いているものは変えるな」という経験則から意図的に残す場合もある。

西暦2020年にもなって、プログラミング簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。

というかプログラミング言語自体多すぎる。ソフトウェアデファクトスタンダードのモノ程度は知っているが、

いまは原始時代にいると思ってもらって構わないと思いますよ。

ぜんぜん完成していない荒っぽいものを目にしているのだと理解したほうが的確。

それなのに毎日理解のできないパソコンスマートフォンを使っている。

オブジェクト指向のおかげ様だがオブジェクト指向に対して無性に腹が立つ。

自分の全く知らない場所いけしゃあしゃあ演算を行い、そして結果を出す。それも大半が正しい結果で

利便性が抜群だ。些細なミス(バグなど)はあるが圧倒的に利便性が勝っている。

そんな道具に踊らされている自分が滑稽だ。理解できない愚かな自分は正に機械奴隷のようだ。

本当に理解できない。辛い。

勘違いしてはいけないのは、それらはすべて先人の努力の蓄積によって成り立っているということ。

「よくわからないけど存在している道具」ではなくて、信じられないほど複雑だけど、多くの人々の行動によってなんとかかんとか実現した道具なんですよ。

オブジェクト指向のおかげ様」じゃないんです。(もちろんオブジェクト指向というのも大きな発明の一つですが)

そしてブラックボックスとして使うのは多くの場合正しいです。そこは諦めましょう。

でもエンジニアとしての立場からは、その裏に隠れているとてつもない技術思考の蓄積に感動してほしいなと思う。

なので、ちょっとずつがんばって勉強してください。

人類がこんなもん作れたのって、かなりすごいよ?

2020-09-17

anond:20200917151622

Googleさん主導の謎規格とかそれこそ毎度ゴミ撒き散らしまくりじゃん。AMPしかWebPしかりDaydreamしかり。そうやって出来たものの上で広告出したいだけだしさあいつら。

2020-06-11

はてなブログってクソすぎない?

画像うpしようとしたら

webp対応してません!だって

何世紀前のサービスだよ

 
ログイン ユーザー登録
ようこそ ゲスト さん