  |
はてなキーワード: GIMPとは
取引先が「ペーパーレス化への取り組みのためFAXをやめてPDFファイルでのやり取りに…」ってFAXしてきたから
「対応できます！是非！」って食い気味に返したんだけど、話をよく聞くとクラウドで共有リンクとかは検討すらされてなくて
結構な量のファイルをメール添付で送る話を検討してるっぽいのよね。多分PPAPだよなぁ……
専用のメールアドレスで受け取って、シス管がスタンドアロンで開いて…とかするくらいなら、
自動印刷しない複合機で受けてPDF形式でメール転送からのスクリプトでチャットツールに流して……のが楽なんでFAXでお願いしますってなっちゃうんだよなぁ
ただそうすると「照会依頼：該当するチェックボックスに✓を付けて返送してください」みたいな地獄のFAXが無くならないんだなぁ
ちなみにこの手のやつはGIMPでPDFを開いてテキストレイヤー重ねて印刷ダイアログからMicrosoft print to PDFで書き出してPCFAXすると有料ソフトなしで倒せる…が徒労感が凄まじい
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
当時、アイコラと呼ばれるものが問題になったころに、画像加工に興味を持った。
GIMPをダウンロードして作ってみるが、全く満足できるものが出来なかった。
どう見ても不自然なものが出来上がってオカズをどころではなかった。
しかし、当時は性欲の塊だったので、これならいけるかもしれないという淡い期待で一年中1日5枚くらい作っていた。
100枚越したあたりから、なんとなく自然に見えるコツが分かってきた。
500枚こえたあたりから、言語化できてパターン化できるようになった。
そして今もひたすらに試行錯誤を続けている。平均すると毎日3枚を10年間くらいやっている気がする。
だからなんなんだ、という話だが
これは仕方ない面もある話だけどSFMLはIME対応をバッサリやらないとフォーラムだったか作者だったか書いてたよなあ
でもGLFWのIME対応は日本人のプルリクが受け入れられてたはずで、今は日本語が普通に入力できる
アルファベット圏の人たちはほんと多言語対応をあんまりしたがらない
（まあ、最近はちょっと違うかもしれない。あとSFMLは余計なコードを入れずシンプルなままでいたいのだとは思う
なんだったかな、日本人がプルリク出したら却下されたんだけど、中国人が強気で出してやっと採用されたような話があったはず
コミュニケーション能力というか、ゴリ押しもコミュニケーションなんだよなあ
そう考えると、多人数によるプログラミングもコミュニケーションのウェイトが高くなりすぎて駄目になる可能性があるわけで、
当たり前だけど、だったら一人でとぼとぼ書いてる方が気持ちは楽なんだよな、気持ちは
集団やチームワークならではのパワーが発揮されなくなるけど
まあ、でもプログラミングの良い点としては分割されているというのがあると思うし、
論理的思考をしているならば正しく分割、単純化、抽象化されているはずなので、
例えば閉鎖的なコミュニティーとか人種差別とかそういうのが嫌でも、そのライブラリをとりあえず使えばまず最低限動かせる
次にそのモジュールを既存のコードに頼らずに再実装するとか迂回して、それにそげ変えればいい
どっちかというと、こういうのはライセンスの話が多いと思うのだけれど、こういう点がプログラミングの良い所だと思う
あと、GIMP昔はゼロから比較的楽にビルドできた気がするんだけど、今のGIMPは自分でビルドできそうにない
GEGLとかコンセプトはいいんだけど、なんか移行してたり移行してなかったりが混在してたり、ややこしくなった感がある
というか、ほんとBlenderは化けたよなあ
（BlenderはPythonで操作してモデリングできるぐらいPythonなんだけど、Pythonが言語として生き残ったというのもあるなあ
実のところイラストアプリが増える一方で正規のフォトレタッチソフトは減ったように思う
実際にメジャーどころだとGIMPとPaintShopProくらいしかない
というよりPaintShopProに関してはVer6,7以降知ってる人はほぼいないのではないか
それ以外のレタッチ系は何があるだろう
……とこのようにただ単にイラストアプリ紹介になってしまいかねない勢いだ
ローカルアプリでフォトレタッチ用途って本当になくなったなと思う
ちなみにPhotoshop、InDesignあたりはポストスクリプトと印刷業界の都合上なくなったりしないとか需要があるなんて話はツッコミ不要
追記：
トラバ曰くAffinity Photoがフォトレタッチ専用っぽい。ソースネクストらしい……。が、PSPもソースネクスト化してたしな。
家のパソコンにGIMPは入れられなかったので、代わりにPict Bearでめちゃくちゃコラ画像などを作りまくった。楽しかった。
次の単元で動画作りを教わったはずなのだが、そこの記憶は全くない。音声の速度の調節の仕方と、動画のカットの方法を教わったような記憶があるが、具体的には全く思い出せない。
当時の家のパソコンは2010年代にもかかわらずwin98で、YouTubeもニコニコ動画もとても見られるスペックじゃなかったし、動画には興味なかったのだろう。
今のwin10なら多分大丈夫だし、動画編集とかやってみたいなー。ニコ動とか見ていると自分でも上げてみたくなる。
せめて授業で用いていたソフト名が分かればいいのだが、ちっとも思い出せないし当時のテキストは捨ててしまった。
そもそも動画編集ソフトは何があるのか名前すら知らない。AviUtl だけ聞いたことある。
調べるか。
CUI（テキストモード）起動(Linux)できるようになったら・・・それがもたらす事柄。職場でパソコン仕事って何をしているのだろう？
[B! OSS] GIMPの名称問題再発、派生版の「Glimpse」が誕生。 | SlackNote
これか。Twitter上ではGIMPの名前を使えなくなった。 https://twitter.com/expresser_uxm/status/1227981125978488833?s=21
問題のツイートは「@chibialf GIMP! GIMP!」。日本語文字を含まないのでリプで暴言吐いてる英文に見えるかも。英語圏Twitter上ではソフト名より普通名詞・俗語として使われる方が多い感じだし。Togetter→https://togetter.com/li/1468360
英語圏というのは（おそらく）読めもしないリプライによるツリー文脈さえ考慮なしに通報を受け入れていい文化圏なのか？
https://twitter.com/eXpresser_UXM/status/1227980517435305984
https://twitter.com/chibialf/status/1227756718735519744
他のフリソ探すかーーーーーー(ぉ
フリソ＝フリーソフト。
機械翻訳にかけた上でフリソがどこかの有名人知人と重なったのか？
https://twitter.com/eXpresser_UXM/status/1228278800821047299
「さらに審査した結果、Twitterルールには抵触してないようなので、アカウントの停止を解除しました。ご不便をお掛けして申し訳ありません。」という内容でした。
誤解はあったが文脈の勝利。とりあえず今後のGNUのGIMPの第三者としての呼称については気にしなくていいのでは。
