「さようなら ImageMagick」の考察 - Qiita
はじめに サイボウズさんの ImageMagick の利用をやめる記事について少し思う所を書きます。否定というよりアシストのつもりです。(2018年08月26日投稿) さようなら ImageMagick 自分のスタンスを3行でまとめると、 policy.xml で読み書き出来るファイル形式を絞れば、いうほど怖くはない ただ、ImageMagick に限らずサーバサイドで動かすのは手間と覚悟が要る Yahoobleed の件でコード品質が信用ならないと言われたら、ごめんなさい 「ImageMagick を外した理由」 サイボウズさんのブログでは、2017年の ImageMagick 脆弱性報告数が多いので駄目との事です。 脆弱性 ImageMagick には脆弱性が大量に存在します。 2017 年に報告された ImageMagick の脆弱性は 236 件 でした。 大量にある上にリモートコ
ImageMagickのピクセルキャッシュとリソース制限 - クックパッド開発者ブログ
こんにちは、成田（@mirakui）です。今日はみんな大好き ImageMagick チューニングのお話です。 2016/5/13 に公開された、いわゆる ImageTragick と呼ばれる脆弱性では、 policy.xml というファイルを更新するという workaround が紹介されていたのは記憶に新しいと思います。 この policy.xml は、今回の workaround のようにファイルタイプを制限するだけではなく、画像の縦横ピクセル数、利用するメモリやディスクのサイズなどを制限することができます。 Web サービスなどでユーザのアップロードした画像を ImageMagick で変換する場合、このようなリソース制限を適切に行うべきでしょう。 そこで今回は policy.xml によるリソース制限方法を紹介します。 前提 特に明記しない限り、2016/05/14 現在の 6
ImageMagickの脆弱性(CVE-2016-3714他)についてまとめてみた 2016-05-04 - piyolog
画像処理ソフトImageMagickに複数の脆弱性が存在するとして2016年5月3日頃、CVE-2016-3714他の脆弱性情報が公開されました。ここでは関連情報をまとめます。 ImageMagick 開発チームの情報 2016年5月3日 ImageMagick Security Issue 脆弱性情報 対象 ImageMagick CVE CVE-2016-3714 CVE-2016-3715 CVE-2016-3716 CVE-2016-3717 CVE-2016-3718 影響 RCE 重要度 CVE-2016-3714：Important(Redhat)/緊急(JPCERT/CC) PoC PoC公開あり。 in the wildとの情報もあり。 CVSS(v2) CVE-2016-3714：6.8(Redhat)/9.3(CERT/CC) 発見者 Nikolay Ermishki
rubyのconfigureで不要な拡張モジュールを無効にする - jarp,
■ iftttでPocketからDiigoへ Pocketで既読になったアイテムをiftttを使うとDiigoへ送れるとわかったので、 しばらく試してみた。その前段階としてはHototでRead Laterするというのがあるんだけど、 これはtwitterでリンクのあるtweetをPocketへ送るという連携。 bitlyとか使っていればそのまま短いままのURLがPocketへ登録される。 Pocketでそのリンクを踏めば既読になるので30分のポーリングでDiigoに送られる。 このときはちゃんと展開して長いURLになるようだ。 つまり最終的にDiigoには本来のURLが登録される。 その後DiigoのDelicious連携でdeliciousへ送られる。 長いな。 Hotot->Pocoket->iftttを介してDiigo->Deliciousというわけだが、 iftttにはDelic
Just another Ruby porter, 2012-6-a
■ Fedora 16から17へyumでupgrade 例によって Upgrading Fedora using yumに従って進める。 % sudo yum update yum % sudo yum clean all % sudo rpm --import https://fedoraproject.org/static/1ACA3465.txt % sudo yum --releasever=17 distro-sync boost-serializationがcompizで依存エラーを起こした。使ってないので % sudo yum remove boost-serialization で削除。再度distro-sync % sudo yum --releasever=17 distro-sync ERROR You need to update rpm to handle: rp
Origamiを使ってPDF中の画像を調整する
ScanSnapで検索可能なPDFにしたとする。このとき、せっかくだから検索可能なまま画像の調整をしたくなる。だが、その種のことができるツールというのをどうもうまく探せない。いかにも何かありそうなものなのだけど。 それなら作ればよい。PDFを扱うライブラリはたくさんある。最終的にできるかどうかはともかくとして、ちょっと試すくらいならやりようがあるだろう。 そう思ってあれこれやっていたのが2010年12月くらいのこと。その当時の環境ではこれが意外にめんどうで途中までやりかけたものの放ってしまっていた。その時使っていたライブラリのバージョンが上がってリリース版が出たというのを先日知って、もう一度やってみることにした。すると意外にもこれが結構簡単にできてしまった。 当時でもPDFを扱うライブラリは簡単にいくつも見付かった。代表的なのはPDF::WriterやPrawn。その他のいくつかのライブラ
ScanSnapした画像のレベル調整
昨日の記事はブックマークのつもり書き始めた。しかし脱線していって自分でやってみたことのほうが多くなってしまったので記事を分けることにした。 きっかけは以下のページ。 Desire for wealth : ScanSnap の自炊 pdf を自動で美白化（レベル補正）する convert -density 150x150 -type GrayScale \ -linear-stretch 10%x35% \ -geometry 512x -compress jpeg -quality 80 a.pdf b.pdf このページや他のページで解説されているのはconvertの-linear-stretchの使い方である。だが、似たようなオプションに-levelというのがあって、これらの関係がよくわからない。そこでいろいろと試してみた。 結果を言うと-levelもこの目的では同じように利用できる
ScanSnap後の画像処理
スキャンした画像を読み易くするための後処理が世の中でどのように行われているか調べてみた。自分用のブックマークでもある。 jarp,より 150 dpiでスキャンするより300 dpiでスキャンして16階調にしたほうがサイズが小さい - jarp, convert in.png -deskew 40% -level 30%,100% -sharpen 5 \ -density 150x150 -colorspace gray -resize 514x751! -depth 4 out.png -deskewにより傾き補正をかける。その際にぼけるため-sharpen 5でぼけ補正もしておく。 スキャンは横向きで - jarp, r=90 for i in .png;do convert $i -rotate $[r=-1] r90-$i; done 縦長の紙面を横向きでScanSnapにかける
スキャンした書籍や書類の余白をImageMagickで除去する | anobota
スキャンした書籍や書類の余白をImageMagickで除去する -trim, -fuzz そういう都合のいいオプションはないものかと調べてみると、 -trim というのが見つかりました。 convert -trim a.png a-out.png a.png a-out.png ただし、 -trim オプションは「角のピクセルと同じ色」を除去するようで、 紙の色ムラ・染みなどノイズが混じっていると上手く除去できません。 convert -trim b.png b-out.png b.png b-out.png convert -trim c.png c-out.png c.png c-out.png そこらへんも適当にうまいことやってくれよーと思うわけですが、 なんと大変都合の良いことに -fuzz というオプションがあるんですね。 -trim に添えて -fuzz 50% などと指定して
複数のzipファイルをunzipする - Just another Ruby porter, 2012-1-c
■ 複数のzipファイルをunzipする forを使えばまあいいんだけど、unzipにはなぜかwildcard処理が内蔵されている。 % unzip '*.zip' とすれば全zipが展開される。 % ls a.zip b.zip c.zip % unzip *.zip Archive: a.zip caution: filename not matched: b.zip caution: filename not matched: c.zip quoteしないと引数として渡るので、 unzip a.zip b.zip c.zipと実行したのと同じ。 a.zipの中のb.zipとc.zipを展開せよという意味になりエラーになる。 ■ 重複チェック 例の1.1から2.0で四則演算で最大化問題を解いてて、1.8がダブってしまったのでチェックしようぜという話。 実際に勘違いしたのはこんな式なわけ
ssvncのtsvnc - jarp,
■ 自炊といえばまな板 今まではカッティングシートを使わずに適当に読んだ雑誌とかを下に敷いてたけど、 切るとだんだんぼろぼろになるし、そこから切りくずも出るしで、ダイソーで探してみた。 A4以上の大き目がいいよなとまずは「工作マット」を買った。 さらにもっと大きいのはなにかないかといろいろ見て回ってたら、まな板シートがあった。 やはり自炊といえばまな板。ほぼB4サイズとまさにうってつけの大きさ。 しかも元々刃物を当てて使うためのものだし、完璧だ。 ■ convert -cropでの挙動 画像のある範囲だけを切り出したいときはImageMagickのconvertで-cropを使うが、 % convert in.png -crop 200x300 out.png という感じで実行すると、200x300で分割したout-*.png画像を作ってしまう。 本当に左上の200x300の画像だけが欲し
convertを使った赤チャンネル・グレースケール化
黄ばんだ本をスキャンする場合、後で画像処理によって白くしやすくるするためには赤チャンネルだけをひろってグレースケール化するとよいそうだ(自炊技術Wiki 加工-第3の一(二)や自炊プロセス v1.2.07[R2])。 他の処理と合わせてGIMPでやるかなと考えていたのだけど、ImageMagickでもできるんじゃないかということに気付いた。やってみたら簡単だった。 convert -channel Red -separate original-image.jpg grayscale-image.jpg これだけ。-channelオプションの引数にどんなものが指定できるかはここに説明がある。もともとの紙の色合いによっては赤チャンネル以外からグレースケール化したほうがよいこともあるとのことなので、それに応じてGreenやBlueを与えるとよいのだろう。 かなり黄ばんだ画像については赤チャンネル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
