「Jpeg」を含む日記 RSS

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

2022-10-06

anond:20221006004359

人間が本気の情熱を込めて描いたのか。

それとも機械の冷たいパターンマッチか。

アンチフェミによるフェミニストなりすまし事件ときにもコメントしたけどさ。

記事タイトルPRって付けとけ、って話と同じなんだよ。

ステルスマーケティングの悪いところは、それを本気で推してるのかが不明になることだ。

熱のこもってない唯のJPEGには誰も感動しない。

・・・それを描いた人の意思にこそ、人は心動かされるんだ。

2022-08-31

anond:20220831233323

知らねーよそんなダサい方法

マジでいたことないし、使いたくもないわ。

たまにスクショくれって言ったとき複数画像Excelに貼り付けてくる人がいるくらいで。

それに、貼り付けるセルをいちいち指定しなきゃいけないからそんな素早く貼れなそうだし。

大体、貼り付けた画像フォーマットはどうなんだよ?jpegpng

2022-02-25

50年後も生きているファイル形式

50年後タイムマシンを掘り返して出てきたファイルで、

一般的デバイスGUI上で「往時と変わりなく読める/再生できる」もの予想

(取り込み方法は置いといて)

JPEG画像

PDF/a(画像+α)

他、よくわからんもの

TXT文章)→日本語文章場合文字コードとかどうなってんだろう

MP3(音声)→WAVよりは…

SVGベクター)→PDFのついでに読まれそう

賢い人たち教えて!

2022-02-18

anond:20220218173011

これは電子書籍リーダーが屑ってだけだがなぜか永遠に改善しない。

jpegzipで固めたファイルを読むアプリなら紙と同じレベルでばーっとめくれるのが10年以上前からあるのだが……。

DRM関係で早くページを捲られたら困るとかあるのか?

2022-01-20

情報系詳しい人なら

そもそもJPEGですら補完してるから本当の情報かどうかは分からないってのを知ってるはず

AI超解像は流石にやり過ぎ感あるけど

真に信用できるのは可逆圧縮のみ

2021-01-22

という理由で、どうしてやってないの?というのに、いやーぼく馬鹿からとなる。めんどくせぇ

あっ

Jpegのこんなところにノイズが あっこんなところに誤字脱字が あっQNGファイル

anond:20210122190207

JpegのS3配信はまだ、安くなるという、効果もあるからやってもいいけど

本文のクロールとなると、なんで俺が金を払ってお前がクロールしてるんだ?というのがあるから

簡単クロールできる仕組みより、クロールされるとサイトが落ちる仕組みのほうがハッキング対策上優れいている

2021-01-03

というかPHPをやる以上

どうしてもJpegPNGは扱うことになるし

そこにウォーターマークプログラムで入れたり

画像は扱うことになる。

PHPプログラマーという段階で

最低限の芸術スキルが求められる。最低限な。

2020-12-14

エイダッチとシマミュール

例えばローマ字表記を他言語の人が読み上げて、その言語での表記をまた別な言語の人が読み上げて…を繰り返すとエイダッキとサイマミュール辺りまで変形するかもしれません。

それでも元の日本語が推測可能であることから、「元データの特徴を失っていなければ」「多少のエラーを含んでいても」高確率で元データに近い信号に復号できるアルゴリズムが構築可能なことを示唆しています

もの凄く大雑把にはJPEGMP3AACH.264/AVCH.265/HEVCといった非可逆圧縮技術はこのような考え方を発展させたロジック実装されていると言えるでしょう。

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-11-16

anond:20201113095622

オタク自分たちキモいものだという視線内面化してるだけだよ。

キモい」は「オタク」の枕詞じゃん。令和になっても「キモオタ」みたいに言われること多いじゃん。

オタクは「キモい」と言われることに慣れているだけ。自分たちが「キモい」と思われていることを知っていて、諦めているだけ。諦めているから向上の努力をしようとしないだけ。

三次元の女より紙とJPEGの女」ってのも、言ってるやつの8~9割は酸っぱい葡萄から。どうせこんな容姿から無理だよ……っていうのが骨の髄まで染み込んでいる。

で、全体的にファッションセンスが壊滅的なので、っていうか女よりファッションに興味がない男の中でも特にファッションセンスがない連中を選りすぐったのが男オタクなので、オタク同士で外見で貶し合いっていうのは基本的に発生しない。

(っていうか、そもそも論として、よほどのことがない限り男同士で外見や服装を品評することはないよな……これはオタクに限らずそうでしょ。そもそも服装に対するジェンダーの差があると思うなぁ。男は服装について色々考えることが嫌いなのです。もちろん先天的というよりは後天的文化的刷り込みだと思うけどね)

それでもって複雑なのは、単に見た目を整える能力が欠如しているから見た目がキモいんじゃなくて、あまりキモいキモいと言われ続けたせいで「見た目がキモい」ことがなんというか男オタク自画像なっちゃってる感があるということだ。

昔、よく戯画化されたオタクで、チェックシャツバンダナ、みたいなのがあったよね。今から思えば差別的目線だけど、でも、あれが「オタク」であり、俺たちはああい存在なんだ、っていうアイデンティティはあるよね。

ニコニコ動画アニメとか見てるとさ、そういうテンプレ的なオタク服装したやつがモブで出てくると、「俺らじゃん」「お前らwww」みたいなコメントが飛び交うし、自分オタク自称して「俺らオタクはさ~」っていうときに、そこで思い描いてる「俺ら」ってのはパリッとしたスーツを着こなしたイケメンじゃなくてチェックシャツバンダナ眼鏡だと思うのよ。

イギリス人にとってのブリタニアとかフランス人にとってのマリアンヌが、俺らにとっての「デュフフwww」とか言っちゃうチェックシャツキモオタなんだよな(実際にはもう秋葉原でもチェックシャツとか着てないやつの方が多数派だけど、まあ多くの日本人日常生活着物着てるわけじゃないし……)

なので、多くの男オタクは、外見がキモいと思われることに(他の趣味を持っている男たちと比べると)頓着しない傾向がある。でもそれは容姿の品評から解放されているからじゃない。まったく逆だ。容姿品評会で敗者であることを自覚し、それに甘んじているからだ。容姿品評会で敗者であることが自己認識の一部になっているからだ。

二次元ジャンルでもジャニーズの界隈でも、オタク容姿が悪いとそれを理由ジャンル中傷されるっていう縛りは感じる。

「あのジャンルってキモい女が推しがちだよねw」って思われるのが怖い。

オタクにとっては、オタク趣味全体が他の男たちや女たちから「あのジャンルってキモい男が推しがちだよねw」って言われる対象だったわけで。

逆にその「キモいジャンル」の内部、つまりオタク趣味の内部ではそんなに服装の縛りはきつくないんだけど、賤民あいだでは平等関係であることを身分差別から解放されてるって言われても困る。

余談。俺のこれまでの経験からすると、オタク趣味走る男の外見、他の趣味に比べて明らかに一歩劣るよね。原因なのか結果なのか偶然なのか観測範囲の偏りなのか俺の思い込みに過ぎないのかは知らんけど。

原因っていうのは、つまりオタク趣味というのはスポーツ吹奏楽とかとは違う周縁的な趣味であって、いじめられっ子の駆け込み寺のような役割果たしている場合もあったからだ。「外見がキモい」がいじめトリガーの1つになることは多いので、駆け込み寺に駆け込んでくるやつらの外見が駆け込む必要のなかったやつらより平均的に劣ってるのは十分ありえる。

結果っていうのは、オタク趣味って運動不足で不健康になりやすいのと、他の趣味と違ってファッションに対する意識があまりにも低いので、結果としてそういう界隈にいるやつらの外見はフットサルやってますとかそういう連中に比べて劣るものになりがちだろう。

でも実際、オタク非オタクのあいだでの容姿の差ってどのくらい統計的に立証できるんだろうね。倫理的にアレだから真面目に研究することは難しそうだけど…

2020-10-28

別に高速フーリエ変換アルゴリズムは知らなくてもいいけど、Web制作者ならPNGJPEGの違いくらい知っててくれ。

2020-10-24

胃の中の写真(紙)もろーた

jpegで、できればRAWで下さいって言えばよかった

2020-09-23

anond:20200923192303

ワープロファイルの読み込みって簡単に言うけど、

お前のメーカー

フォーマット教えろやー

っていうのが安いと思うのなら素敵

ちなみにJpegデコーダ書いて、表示プログラムかけ程度できるプログラマーはいっぱいいる。

学術的なもの簡単

私企業に、フォーマット公開しろというのは、よく考えれば、凄まじいことを言っている

と考えれば、わかりやすい。

2020-08-21

Jpegにすると画像劣化するといわれたのでLoss less jpeg劣化0で使えばいいだろとかえしといた

2020-08-10

フォースのもんもこ力を信じるのだ

Mpegというのは1秒の動画をおおよそ30枚のJpegにわけてパタパタあにめをするようなものだ。

このさいに、メインとなるJpegをIフレーム これは選抜だな

それにたいしてPフレーム Bフレームというのがあり

Pフレームメンバー Bフレーム研究生

努力が違う。

わかったな。Mpegは 偉い選抜Iフレームがたまにいて、全体を修正

普段Pフレームというメンバーがなんとかして

たまにBフレームという研究生がださせてもらえる

 

運営からすると1曲を選抜(I)ばかりで構成すると高い

どうやって研究生(B)を混ぜていくか 使いやすいのはP(メンバー

この配合比率アート

2020-07-08

anond:20200708110546

駆け出しのライター文章ZIPにすると圧縮率が高い。

プロイラストZIPどころかJPEGにもできないくら圧縮が難しい お金をもらうとはこういうこと

2020-06-26

anond:20200626102758

Jpegをな 展開するのも 時間が短いとわりと大変だから説明

2020-06-17

APS-C一眼レフの画質の違いが判らない

JPEG画像を目を皿にしてみたけど、誤差じゃないか

詳しい人の主張するところによると諧調が違うそうだけど、わからない

色覚検査で異常判定されない俺の目をもってしても一眼レフAPS-Cの違いが判らない

2020-06-09

でも、現実的な話だけを見ればユニファイドメモリの方が高速なはずなんだよ グラ1枚 転送しなくていいんだから 高速だろ?ディスクから物理メモリへの展開は考慮するけど、物理メモリからGDDRへの転送時間はあまりメリット体感しない。1枚や2枚のJpegだとスワップアウトしたところで、わからん

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