今日も微速転進

ここではないどこかへ

macOSとスクリーンショット

備忘録というかメモ。

基本

基本的なやり方

  • 画面全体: Command+Shift+3
  • 画面の選択範囲: Command+Shift+4、カーソルの形が変化したらドラッグ
  • ウィンドウ単体: Command+Shift+4、Spaceキーを押してからウィンドウをクリック
  • Touch Bar: Command+Shift+6

撮影されたスクリーンショットはデスクトップに保存される(El Capitan以降)。

ウィンドウ単体のスクリーンショットを撮る際、escキーでキャンセルできる。

海外のサイトによると、次期macOS Mojaveでは新しいスクリーンショット用のツールが追加されるとのこと(Command+Shift+5)。

標準搭載のグラブ.app(Grap.app)というアプリケーション、QuickTimeを使う方法もある。

クリップボードにダイレクトにコピーしたいとき

スクリーンショットの撮影時にcontrlを同時に押すとクリップボードに画像データが保存される。

  • 画面全体: Command+Shift+3+control
  • ウィンドウ単体: Command+Shift+4+control

他のキーを指で抑えた状態で最後に数字キーを押すとラクに操作できる。

ダイレクトに画像編集ソフトにペーストできて便利。

ウィンドウの影を消す

ウィンドウ単位でスクリーンショットを撮ると、ウィンドウの影のついた画像が保存される。

クリック時にoptionキーを押せば影のない画像が保存される。

マウスカーソルつきのスクリーンショット

グラブというアプリケーションを使えば可能。

  1. グラブを起動(面倒ならCommand+Space、grab.appと入力)
  2. Commad+,で設定画面を開く
  3. スクリーンショットに入れたいカーソルの形状を選ぶ

f:id:atuyosi:20180629100953p:plain

スクリーンショットに関する設定

基本的にTerminal.appなど、コマンドを実行することで設定を変更。

SystemUIServerというバックグラウンドで実行されているプロセスの再起動が必要なケースと、そうでないケースがある。

保存先の変更方法

初期設定ではデスクトップに保存されるので少々不便です。

$ defaults write com.apple.screencapture location <path>
$ killall SystemUIServer

defaultsコマンドで設定をを書き込み、killallコマンドでSystemUIServerプロセスを再起動。

設定したい保存先に合わせてを変更。

Web上の情報では基本的にはピクチャフォルダ(Picture)に保存する人が多い印象。

設定例:

$ defaults write  com.apple.screencapture location ${HOME}/Pictures/

念の為、SystemUIServerを再起動。

$ killall SystemUIServer

環境変数${HOME}がユーザーのホームディレクトリに展開される。

現在の設定はターミナルで以下のようにdefaultsコマンドにreadオプションを指定して実行すると確認可能。

$ defaults read com.apple.screencapture location

保存形式の変更

保存形式を標準のPNGから変更可能。

$ defaults write com.apple.screencapture type jpg

typeの値として保存形式を指定する。他の形式としては bmp、pdf、tiffなど。

試した限りでは設定の変更は即座に反映された。

ファイル名の接頭辞(文字列)の変更

ファイル名のパターンを完全に独自形式にすることはできない。部分的には変更できる。

$ defaults write com.apple.screencapture name 文字列

文字列の部分を自分で設定したいファイル名の接頭辞に変更。

元に戻したい場合は設定値を削除。

$ defaults delete com.apple.screencapture name

ファイル名に日付と時刻を含むかどうか

$ defaults write com.apple.screencapture include-date -bool false

この状態で連続でスクリーンショットを撮ると、ファイル名が「スクリーンショット.jpg」、「スクリーンショット 1.jpg」、 「スクリーンショット 2.jpg」という形式になる。連番の数字の前にスペースが入っているので注意。

元に戻したい場合は設定値の削除(または-bool trueとして上記コマンドを実行)。

$ defaults delete  com.apple.screencapture  include-date

デフォルトを影なしにする設定

いちいち影なし・影ありをoptionキー切り替える必要がない場合は、設定で常時影なしにできる。

$ defaults write com.apple.screencapture disable-shadow -bool true

もとに戻す場合は値をfalseにするか、パラメータ自体を削除する。

$ defaults write com.apple.screencapture disable-shadow -bool false
$ killall SystemUIServer

または、

$ defaults delete  com.apple.screencapture disable-shadow
$ killall SystemUIServer

まとめ

mac関連の雑誌でもoptionキー同時押しで影なしのスクリーンショットが撮れるというTipsは紹介されていなかったと思う。

元ネタは海外のサイトからというケースが多いけど、海外のサイトはどうやってマニュアルにも公式サイトにもない情報を得ているのか不思議。 Apple社員がリークしている?

参考リンク

macOS High Sierra パーフェクトマニュアル

macOS High Sierra パーフェクトマニュアル

今週のふりかえり(2018年6月第4週)

f:id:atuyosi:20180622160715j:plain

雨は売っと惜しいけど、晴れの日に風が吹くといい感じ。

あと一週間で6月もおしまい‥…。

  • 今週の学び
    • 中国語に関して
    • 最近の読めなかった単語など
    • その他・ノウハウなど
    • ソフトウェア開発関連
      • Electron 入門
      • apac
  • 今週の思いつき
  • 今週試したソフトウェア or サービス
  • 読んだ本
  • 気になった本、サイト、etc.
  • 購入したもの
  • アウトプット
  • 今週の気づき&まとめ
続きを読む

「機械学習で男性エンジニアを女性に」という炎上案件について

いまいちコンテキストが理解できないのだけど。

logmi.jp

その場に「いなかった人」がどうも文脈を把握しきれずに騒いでいる感じがする。

これ音声を機械学習で変換しようという技術についての発表ですよね?

女性エンジニアが少ないことと、機械学習何の関係も無いのに女装写真とか変な前振りをつけているっていう。

悪気はなかったんではないかな。

研究の動機の話

男性の声を女性の声に変換するメリットについて、説得力のある説明ができなかったのではないかと思う。

なにか発表しろと言われて、音声の変換というネタはあるんだけど、イントロダクション部分がイマイチだった。 そこでだれかの入れ知恵か、無理にこじつけで「女性エンジニアが少ない」という話題にこじつけたか、笑いを取りに行ったのか。

学会発表向けのスライドだったら前後のロジックに無理がありすぎて普通にストップがかかるはず。

所属がYahooの中の人らしいのでだれか社内で止める人がいなくても不思議ではないのかも。

前フリと発表の対象技術がちぐはぐなのは確か。

アプローチがまずかっただけでは?

コナンくんの蝶ネクタイ型変声機ネタで攻めればよかったのはでは?

女性エンジニアがいないと云々という言い回しが一種のセクハラ加害者的な発想と受け取ららたのかなという理解。

男性が女性の前で格好をつけたがるというのは割とよくある話で、とある企業のリストラの際に、あえて女性秘書を同席させたという話もある*1

「クビ!」論。

「クビ!」論。

確かに女性側からしたら不快なんだろうけど、本人は深い考えはなしに、男子校のノリで笑いを取りに行ったんだろうと思う。

技術的にどこまでのレベルか知らないけど、その場のウケを狙うなら、コナンくんネタで行けば良かったのにと思う。

軽度難聴の観点から

聴力低下の副作用で相手の声質によって極端に聞き取りにくい時がある。聴力低下によるダイナミックレンジの低下が原因なんだろうけど、 この声の変換技術、補聴器に組み込むとかそういう応用が期待できるという気がした。

むしろそういう笑いを取るネタではなく、真面目に実用路線でアピールして欲しかった。

お役人様から予算を引っ張るのに有効だよきっと。

職業名に「女性」という修飾語をつけることに関して

特定の職業において、性別に偏りがある、というのは多様性の問題。そもそも、エンジニアって性別に影響されない職業だと思っていたのですが、違うんですかね?

「女性〇〇」という表記がおかしいんではないでしょうか。

まずマスメディアが好んで使うそういう、「女性〇〇」っていう表記、それ自体が暗黙に普通は女性はこの職業には就かない、という偏見を助長していると思います。

男性看護師といえば違和感に気づくはずです。女性社長とか女性起業家とか、そうやって都合のいいときだけ「女性」を強調するし。

日本は言霊の国()らしいのでそこからちゃんとしないと。

まとめ

不適切な表現があったからと言って、技術の可能性をと切り捨てないでいただきたい。声質変換でググると結構ヒットするので技術的には 実績のあるテーマみたいだし。

音声系の技術は耳の悪い人間のQoLの向上とか、笑いを取る以外の応用を目指してほしい。健常者にはありがたみがわからないんだろうけどね。

やっぱりその場にいなかった人が大騒ぎして、拡散させているのは違和感ある。

音声認識 (機械学習プロフェッショナルシリーズ)

音声認識 (機械学習プロフェッショナルシリーズ)

*1:男性は女性の前でみっともなく泣きわめきづらいという解説が書いてあった

Gimp 2.10.x macOS版について(McGimp 2.10)

f:id:atuyosi:20180624155357p:plain

本格的にロゴ画像作成にトライしようと思ってGimpをダウンロードしようとしたのですが……。

現時点ではmacOSの最新バイナリパッケージはまだ提供されておらず。

Gimpの最新の安定版はバージョン2.10.x系列。

代替手段

おそらく正解は公式パッケージがリリースされるまで旧バージョンを使う、です。

  • MacPorts経由でインストールする
  • 自力でビルドする
  • 非公式バイナリを使う
  • テスト用のパッケージを使う?

公式サイトでの旧バージョンのダウンロードページへのリンクはなくなっているようです。ただ、ファイルはサイト上に残っています。

非公式バイナリとしてMcGimpというものが比較的名前が知られており、安定しているようなので公式パッケージが提供されるまで試験的に使用しています。

なお、Homebrew Caskに旧バージョン及びMcGimp 2.10のパッケージはありますが、Homebrew 本体にgimpという名前のパッケージはありません。

macOSGimp 2.10 (McGimp)

公式開発チームによるパッケージではない点に注意。新機能を試したい人向け。自己責任で。

Partha's Place

下にスクロールすると右側のサイドバーにダウンロード用のリンクがあるのでそこからダウンロードする。

なお、旧バージョンとはパッケージ名が異なるので共存可能です。

Homebrewを使う場合は、Homebrew Caskにmcgimp-stdというパッケージがあります。

メニューは日本語化できるようですが、日本語の入力はできないようです。

McGimpの日本語化

初期状態では英語メニューなので"Interface"というカテゴリから表示言語を変更してGimpを再起動すると日本語になります。

  1. 画面左上のメニューから"Preferences"(またはCmd+,)をクリック
    f:id:atuyosi:20180624101031p:plain

  2. 左側のメニューから"Interface"というメニューを探してクリック
    f:id:atuyosi:20180624101039p:plain:w480

  3. "Language"を"System Language"から”Japanese”に変更
    f:id:atuyosi:20180624101044p:plain:w480
    f:id:atuyosi:20180624101045p:plain:w480
    f:id:atuyosi:20180624101049p:plain:w480

  4. 一度、McGimpを終了して再起動

f:id:atuyosi:20180624101256p:plain:w480

OSの言語を自動認識されないのはちょっと疑問ですが、以前のInkscapeのようなファイルの書き換えは不要です。

そのほか

旧バージョン

公式ページにリンクがないですが、サイト上にファイル自体はあります。2.8.22の、ファイル名の末尾が.dmgになっているファイルです。

Index of /pub/gimp/v2.8/osx

なお、Homebrew Cask でbrew cask install gimpとすると2.8.22がインストールされるようです。

テスト版

ファイルは存在するのでテス中?。おすすめしません。

Index of /pub/gimp/v2.10/osx/testing

興味があればバグトラッカーをチェックするといいかも。

Issues · GNOME / GIMP · GitLab

自力でのビルド

試していませんが、必要なファイルとツールは下記にあります。

samm-git/gimp-osx-package: FIles required to build standalone gimp 2.10 package for osx

github.com

まとめ

InkscapeよりはGimpのほうがmacOS版の扱いは優遇されている印象でしたが現状を見るとどっこいどっこいな印象。

ただ、InkscapeよりはXQuartz不要のGimpのほうがマシかなとは思います。

そもそも、Gimp関連書籍がバージョン2.8系を対象にしているので、旧バージョンを使うほうが無難かも。

できるクリエイター GIMP 2.8独習ナビ Windows&Mac OS X対応 (できるクリエイターシリーズ)

できるクリエイター GIMP 2.8独習ナビ Windows&Mac OS X対応 (できるクリエイターシリーズ)

GIMP 2.8 スーパーリファレンス for Windows&Macintosh

GIMP 2.8 スーパーリファレンス for Windows&Macintosh

財務省の公開した交渉記録PDFをいじる その3(本件終了)

一応切りの良いところまで作業したのでここで終了。

プログラムは汚いので載せてないです。

フォーマットが微妙に違うなどの数々のトラップによりかなりの部分を手作業で治すハメに。自分で作ったページ範囲データの不備のせいでさらに無駄な苦労があったりと、見事に自業自得。

Google Cloud Vision APIOCR機能の、認識ミスのパターンについて知見が深まったのでその点はプラスだったかな、と思っています。

自分で後で振り返るためのメモ的側面が強いのであまり役に立たないかな、と思います。

方針

過去記事の方針のまま。

  1. 目次のPDFから交渉記録(応接記録)を機械可読(Computer Readable)な形式に変換
  2. マスク無しのPDFを画像化、再度PDFに変換して過去記事で紹介したAPIOCR
  3. 目次のページ番号から必要なページを割り出して、OCR結果を分割、どうにして添付資料のページを除去
  4. どうにかしてMarkdown
  5. 静的ページジェネレーターでWebページ化

成果物

Netlifyで公開しています。

財務省交渉記録 (2018/05)

OGPとか検索機能とかそのへんは気が向けばどうにかするかも。

備忘録

あまり再現性のない情報ですが載せておきます。

方式検討

  1. まず交渉記録の個別の文書のタイトルを特定
  2. タイトルより上にある機密文書指定などの補足情報は捨てる
  3. 応接方法として記録されている情報はカテゴリ情報に使う
  4. 極力、インデントなどの情報は残す
  5. ある程度は妥協してエディタで修正する
  6. 80点主義で行く

JSONのパースに関しては過去記事参照。

a244.hateblo.jp

プログラムそのものは微妙な上にバグっていたので自粛。一部の処理のみ。

Markdownの生成

公式ページを参考にして、front matterと呼ばれるメタデータYAML形式でファイル冒頭に記述する。

具体例は下記のとおり。

---
title: 利用要望照会中財産について
date: 2013-06-28 14:15:00
categories: ["応接記録", "来訪"]
tags: ["園長", "籠池", "土壌汚染", "地下埋設物", "大阪航空局", "ティーズレボ", "森友学園", "塚本幼稚園", "大阪府", ""]
---

JSONをパースして値を取り出して、string.Templateで値を埋め込む。Markdwonで書式を再現できない部分はHTMLタグを使う。

HexoのMarkdownは「はてなブログ」のそれとはちがって空白行を保存するタイプなので無駄な空白行は除去する必要あり*1

参考:Pythonで、string.Templateを使う - naritoブログ

各記事のタグに関してははかなり偏ってしまっているのは反省点。要するに途中で力尽きた……。

正規表現関連メモ

なぜかあまり言及されないことが多いが、Python 3.6から正規表現のマッチした結果の文字列に配列のインデックスでアクセスできる。

import re

m = re.match(r"(\w+) (\w+)", "Isaac Newton, physicist")

m[0]       # The entire match
#  'Isaac Newton'

m[1]       # The first parenthesized subgroup.
#  'Isaac'

m[2]       # The second parenthesized subgroup.
#  'Newton'

Python正規表現のパターンとして漢字何文字とかひらがな、かたかなという文字の種類でマッチさせたいときはregexを使う必要がある。

標準の正規表現モジュールではRuby 2.x系のようにユニコード文字プロパティを使えないです。

Rubyとは(残念ながら)違うのですよ‥…。

正規表現での漢字マッチをUnicodeプロパティーを使って綺麗に書く方法 in Python

正規表現まわりはRubyのほうが優位性はあるかなと思います。

Hexoカスタマイズなど

テーマはデフォルトのまま。細々と修正しています。

設定ファイルの修正箇所

タイトルなど基本的な部分は省略。

index_generator:
  path: ''
  per_page: 10
  order_by: dat

default_category: uncategorized
category_map:
  応接記録: reception
  来訪: came
  訪問: visit
  架電: call
  受電: receive
  その他: other
  情報: note

archive_generator:
  per_page: 10
  yearly: true
  monthly: true
  daily: false
  order_by: date

theme_config:
    google_analytics: UA-120720274-1
    show_count: true
    widgets:
        - category
        - tagcloud
        - archive
        - tag
    menu:
      Home: /
      Archives: /archives
      About: /about

ページの表示順を通常と逆順にするため、index_generatorarchive_generatorの両方にorder_byオプションを指定しています。

テーマのカスタマイズ

  • themes/landscape/source/css/_partial/custom.styl
  • themes/landscape/source/css/style.styl
  • themes/landscape/source/css/_variables.styl
  • themes/landscape/layout/_partial/article.ejs

CSSについてはcustom.stylというファイルを新規作成してそこに記述。style.stylから読み込む。末尾の#moreの除去。バナー画像の変更など。

参考にしたサイト:Hexoでトップページに記事の概要を出す方法 | Katsunori Nippo

リスト要素のスクロール

divで囲む必要あり。

横並びにした時に、改行せずにスクロールさせる方法 - Qiita

OCR APIの認識ミスの傾向

頑なに丸囲み数字を認識しないGoogle。①とか④を「の」と認識されても困るんですが……。「〃」も認識してくれないね……。

  • 段落の頭の字下げによる空白を"「"と認識するミスが多数。
  • 行末に不要な"」"や”)"が追加される
  • 単語辞書による補正のせいで変な認識をする時がある -「□(四角)」を「口(くち)」と認識したり、「■」の認識に失敗していた地味に面倒。
  • 「数量等」の「等」が認識されない
  • 「架電」が「書架」+「電」のように認識されるケースあり(辞書補正の弊害か?)
  • 「藪」というを認識できず
  • 「㎡(平方メートル)」は「m」と認識*2
  • 「以 上」の間のスペースが何故か改行(\n)になるケースがある(JSON"detectedBreak"の値がおかしい)

「のの」など「の」が連続している場合、正しい認識結果として「①の」とか「②の」だった可能性を考慮すべし。

目視でチェックして認識されない可能性のある文字、記号類は事前に当たりをつけておく必要がある。ただし、全く認識されないわけでもなく、②や③をそれぞれ、2、3と認識するケースもある。

また、水平方向の罫線があっても、間にスペースが空いていると行の一部とはみなされず、独立した文字の塊という扱いになる。 水平方向より縦方向に隣接した文字の領域があればそちらを優先してブロック扱いする。

交渉記録文書のフォーマットに関して

先方/相手方といった書式の違いだけでなく順序が違ったりとか。「以上」だったり「(以上)」だったり地味にトラップ多し。

特に時刻の表記はかなり厄介で途中で諦めた。

お役所なのに内部文書のフォーマットは意外とフリーダム。ただ、議事録としては外部の人の名前を先(ページの上部)に書く、と教わったのでその辺は大丈夫か、という感じ。

何はともあれ書式は統一していただきたい。

反省点と今後の課題

兎にも角にも前処理重要。それと仕事が遅すぎ > 自分。

  • 認識結果の確かさの数値を参照するように
  • 事前に傾き補正などの前処理をちゃんとやるべき
  • 画像を分割してOCRするのも一つの方法だったか
  • 過去記事のページ範囲リストの不備が数箇所あったり

ちょっとめんどうではあるけど、JSONの時点で認識ミスをピンポイントで補正してもよかったかも。

JSONビューワー件エディタのような治具?というかユーティリティが必要。

結論:横着はダメ

今後の課題

傾き補正、ノイズ除去、領域分割。あとはに印刷文書に手書きでメモが入っているパターンをどうするか。

所感など

もうやだこの連中。不当要求ですよ不当要求。

すぐに思い出すだけでも昼休みに押しかけたり、仕事に愛がない?とか仕事に命をかけろとかと罵詈雑言とか。

もし自分が近畿地方局の人間だったら余裕で退職届書いて精神的苦痛を理由に訴訟ですよ。

売却金額をはじめから公表したりとか、そもそも大阪府が認可しなければ……とか、寄付金の水増しを見抜いていれば、とか まあ思うところはたくさんあります。

公務員だって人間。教育勅語は罵詈雑言を奨励していなかったはずです。

次は陸自イラク日報のような、救いのある公文書にトライしたいところ。

まとめ

ちまちまと作業しているうちに一ヶ月経過していたり、追加で文書が開示されていたりと微妙な展開。

まあPythonに対する習熟度の向上という点ではギリギリ有益だったかと。GoogleOCRエンジンについては画質が悪いので多少の認識ミスは仕方がないのかという印象。

交渉記録に関してはせっかくなので感想文のようなものを書こうかなと思います。

*1:あまり実害はないと思うが、極端に空きが入る

*2:これは仕方ないと思う

広告