nDiki : 画像

画像 - イメージ、image、picture

2018年6月8日 (金)

今日のさえずり: *scratch* という名前の Google スプレッドシートを作ってブックマークした

2018年06月08日

[ 6月8日全て ]

2018年6月15日 (金)

東京都写真美術館 TOPコレクション たのしむ、まなぶ「イントゥ・ザ・ピクチャーズ」展

image:/nDiki/2018/06/15/2018-06-15-121446-nDiki-800x1200.jpg

次回の検査の予約病院に行くために今日は有給休暇を取ったので、時間のある午前中に久しぶりに東京都写真美術館に行くことしました。現在開催されている3つの写真展のうち、ロベール・ドアノーの写真「ピカソのパン」がトップ画像になっていた

を鑑賞することにしました。以前ロベール・ドアノーの写真展を観て好きになったんですよね。また写真展で観たいなと(本展はTOPコレクションということで所蔵作品の中からチョイスされたものの展示なのでロベール・ドアノーの写真は2作品のみですけど)。

写真の中に入り込んでいろいろ感じる

「美術館」という場における学びは、学校や書物による学びとは異なる体験をもたらします。美術館の空間の空気感、壁に並ぶ作品のリズム感、実際の作品の大きさによる存在感などを全身で感じたりすることからの学びは美術館特有のものです。また、ただ作品を時代の資料として見て情報を得るというだけではなく、自分の興味にそって作品の中に写っているものをじっくり見ることで、それまで気づかなかった作品の別の一面に気づいたり、あるいは「わからないこと」を発見しその「わからなさ」をたのしんだり、ということも美術館での「まなび」です。 -- TOPコレクション たのしむ、まなぶ「イントゥ・ザ・ピクチャーズ」より。

というのがこの展示のテーマ。

あえて作家名・作品名・解説を掲示しない展示に、全力で作品に向き合うことになりました。写真中の人物の視線の先、フレームの中に写っているもの・フレームの外にあるもの、写された瞬間とその前とその後。全てを想像しつくすというの、とても勉強になりました。写真の中に入り込んでいろいろ感じ考えてみるという意識を持つことにとても面白みを感じました。

一方感じるだけでなく、いろいろ考えを巡らせために頭の中で言語化をしていく自分に「こんなにわかりやすく言葉に置き換えてしまっていいのかな」という思いを抱きました。それから、写っているその情景はある瞬間を切り取ったものなのか、それとも意図的にそのようなポーズをとってもらったのか、そういうところも今まで以上に気になるようになりました。

いやー、非常に集中したエネルギーを使った写真展でした。

8月11日から2期の

もあるのでこれもぜひ観に行きたいです。

[ 6月15日全て ]

2018年6月25日 (月)

今日のさえずり: Pixave っていう画像管理 Mac アプリケーションのトライアル版を入れてみたけれど iThoughtsX のファイルをうまく読み込んでくれず

2018年06月25日

[ 6月25日全て ]

2018年8月23日 (木)

違反投稿分類自動化と学習データを作れなくなる問題

ユーザー投稿ができるネットサービスの多くは違反投稿の対応が必須である。ここ数年機械学習を用いてテキストや画像を分類する環境が整ってきたため、違反投稿の判別にも適用が進んできている。人の負担が減ることはとても良いことだと思っているのだが、自動化を進めることで違反投稿対応スタッフを過度に削減することになるリスクも心の奥で感じている。

人力チェックから自動化へと切り替えるタイミングでは、教育されたスタッフによって分類された良質な学習データが使える。だが自動化のあとにスタッフを削減しすぎてしまうと、組織として違反投稿かどうかの判断する力が弱くなってしまい、将来判断基準を変更したり新しい基準での学習データを用意したりすることが難しくなってしまう。ノウハウが失われてしまうリスクが隠れているのである。

[ opinion ]

[ 8月23日全て ]

2018年9月26日 (水)

DSC-RX0 を 1:1 で使う

image:/nDiki/2018/09/26/2018-09-26-093337-nDiki-1200x1200.jpg

DSC-RX0 は焦点距離 24mm 相当(35mm 判換算)でちょっと広く余計なものが写らないようにするのがなかなか難しい。フォーマットは変わるけれど 1:1 だと 30.7mm 相当(同)になるのでこれでちょっと使ってみようかなと思う。さっと変更できるようにFn(ファンクション)ボタンのファンクション下段5をピクチャープロファイルから横縦比に変更してみた。

1:1 に設定すると写真表示が背面モニタの一部だけになるので、ただでさえ小さいのにさらにちっちゃくてフレーミングには難儀しそう。

ちなみに 1:1 で撮っても RAW 画像は 3:2 で保存されていてメタデータとして 1:1 でクロッピングされているのね。RAW だからそう言われればそうだなと。(JPEG 画像は 1:1 で保存されている)。

1:1 なので縦横ないのに、被写体が縦っぽいなーと思うと無意識にカメラを縦位置にして撮っていて、あっ 1:1 だから意味なことしているなー自分でもおかしくなった。DSC-RX0 は縦横のセンサーが入っておらず表示時に自動回転されないので、1:1 なら常にカメラ横位置で撮っていた方が手間ないのにね。

[ 9月26日全て ]

2018年9月28日 (金)

今日のさえずり: 森永チョコフレーク生産終了ってマジかー。かわりに「ぬ〜ぼ〜」と「ドーナッチョ」復活お願い!

2018年09月28日

[ 9月28日全て ]

2018年10月13日 (土)

Ulysses で TextBundle を使うのどうなのか調べてみた

Markdown 形式ファイルと、そこから参照されている画像ファイルを1つにまとめて管理する形式として TextBundle がある。ライティングアプリ Ulysses が対応しているのでちょっといじってみた。

TextBundle は package format と compressed format がある。 package format は macOS のパッケージの形になっていて、 textbundle という拡張子をつけたディレクトリの中に info.json と text.* (Markdown なら text.md)、それからテキストファイルから参照しているファイルを asserts/ サブディレクトリに置くという仕様である。macOS の Finder からは1つのファイルのように表示される。

TextBundle を使うメリット

メリットは以下。

  • テキストファイルと参照されている画像ファイルを一緒に管理できる(ばらけないで移動したりできる)。
  • TextBundle に対応していないテキストエディタでも text.md を簡単に開いて編集できる。

TextBundle を使うデメリット

非対応アプリケーションから使う場合にデメリットを感じる。

  • 非対応アプリからみると TextBundle 毎にディレクトリがあることになるので、ディレクトリだらけな感じになる。ドキュメント毎にディレクトリを開いて中のテキストファイルにアクセスする必要がある。
  • Markdown ファイル名が text.md 固定なので、ファイル名だけでは区別できなくなる。

Ulysses for Mac の場合

Ulysses は TextBundle に対応しているので通常の Markdown ファイルと同様1つのシートとして自然に扱える。

普段 Ulysses for Mac では Dropbox の中のディレクトリを外部フォルダとして指定して使っているので以下、外部フォルダの時の話し。

Ulysses の外部フォルダ上の Markdown ファイルに貼った画像エディタ上でプレビューできるのは現状 TextBundle だけ。エクスポート時も TextBundle 内の画像ファイルは書き出されれるけれど、(相対パス・絶対パス問わず)ファイル名で参照しているものは書き出されない(http/https な URL で指定した画像HTML でエクスポートする際は画像が貼られる形になるが PDF ではだめ)。Ulysses だけを使って画像を扱いたいなら TextBundle を使う以外選択がない感じだ。

Ulysses 上で TextBundle なシートを保存するたびに参照されている画像ファイルを残して他は assets/ から消されてしまう。なので assets/ の下に画像作成に使ったソース・ファイル(マインドマップファイル)を一緒に置いておくおような管理はできない。そもそもテキスト編集で間違えて画像参照を消して保存実行してしまうと、画像ファイルだって消えてしまうので、画像ファイルだってオリジナルを別で保存しておく必要がある。

TextBundle は使うのは控えた方が良さそうだ。

[ 10月13日全て ]

2018年10月14日 (日)

Marked 2 で Markdownレビュー時に自動的に画像を探すようにした

image:/nDiki/2018/10/14/Marked-2-1200x900.png

ライティングアプリ Ulysses for Mac では画像ファイルのプレビューがいい感じじゃなかったので、 Markdownレビューアの Marked 2 を使うことにした。

Marked 2 は相対パス指定・絶対パス指定のローカルの画像ファイルや URL で指定したネットワーク上の画像もきちんと扱ってくれるので便利だ。

画像ファイルをどこにおいておくか

さて Markdown ファイルから参照している画像ファイルをどこに置いておくか。Markedown ファイルと同じディレクトリに置くのが素朴だが以下の点で却下。

  • Markdown ファイルを別のディレクトリに移動する時に参照している画像ファイルを一緒に動かすのが面倒。
  • Markdown で書いた日別のノートファイルがたくさんあるようなディレクトリでは画像ファイルが邪魔。

別のところにまとめて置いておくのがよさそうだけれど、そうするとパス指定の問題が出てくる。ファイル移動時の参照書き換えをするは面倒なので嫌。

どうしようかなと思っていたら、 Marked 2 のプリプロセッサ機能で画像のパスを書き換える例を発見。その記事ではローカルホストでのプレビュー時とサイト公開時とでパスが違うことの解決に利用していたんだけれど、ローカルホスト上でも応用できるな。

パス指定はプリプロセッサにやらせてしまえばいいじゃない。画像ファイル名をユニークにしておき(もともとそうしている) Markdown ファイル上ではそのファイル名だけで画像参照として書く。プレビュー時に画像ファイルをローカルホスト上で検索して見つかったパスで書き換えてやれば良いなと。

さっそく Perl プログラムとしてプリプロセッサを作成。 Markdown ファイル中の画像参照があったら、Markdown ファイルのあるディレクトリレクトリ以下および指定したパス以下のディレクトリから File:Find::find で探し、見つかればそのパスに書き換えるようにしてみた。

あ、これ便利。

画像ファイルをいちいち Markdown ファイルの近くにエクスポートするとか、一緒に移動させるとかする必要なくてめちゃくちゃいいわ。

[ 10月14日全て ]

2018年11月10日 (土)

ついにデジタル音楽配信サービス Spotify 登録

image:/nDiki/2018/11/10/Overview.png

6月に Google Home Mini を買った時にそのうち Spotify を使ってみようと思っていたのだけれど、一人でSpotifyアカウントを複数登録できるか利用規約を確認してからと思っている間に5カ月弱経ってしまった。

そんなところ Bluetooth スピーカーとしての利用も考えて今月買ったパナソニックのコンパクトステレオシステム SC-HC2000 が、 Chromecast built-in 搭載で直接ストリーミング再生できるということなので、対応している Spotify にようやく登録して使ってみることにした。

Google Home Mini を買った際にちょっとチェックした際はジャンルを指定して流すぐらいのものなのかなと思っていたのだけれど、無料の Spotify Free でもアプリや Web 版からきちんとアーティスト・アルバムやプレイリスト、それから特定の曲を指定して再生できるんだね。邦楽も結構あるし良いじゃないですか。

今回ステレオシステムを買い換える際、音楽配信については Amazonプライム(契約中)の Prime Music を Mac / iPad から Bluetooth 経由で再生かなと思っていたのだけれど、 使った感じ Spotify の方がずっと良さそう。 Prime Music では家の共用端末に Amazon アカウントでログインしたままにしておくのもなという問題があったのだけれど、Spotify だとそういう心配もないしね。

MaciPadGoogle Home Mini からコントロールできるように設定しておいた。音楽の QOL 大幅アップだ。

(画像は Media Kit https://newsroom.spotify.com/mediakit/product/ より。)

[ ネットサービス ]

[ 11月10日全て ]

2018年11月14日 (水)

トピックとリンクによる構造が特徴のサービス Trickle

丸山@h13i32maru 氏が開発された Trickle というサービスがとても面白そうなので、サインアップして触ってみた。

より気兼ねなくアクティビティを投稿できるためのトピックという構造

Trickle は Twitter を使っていて

「自分が主体でありたい、自分への影響をコントロールしたい。でも一人は寂しい」

という自分も「そうそう!」と共感できるインサイトから、トピックというアイデア取り入れて作られた(ソーシャルメディア)サービスだそう。トピックという構造を1つ入れることで投稿する側は書き分けられるし、読む側は特定のトピックだけサブスクライブすることで読み分けられるというお互いにハッピーという仕組みだ。

投稿単位であるアクティビティはオプショナルな「ノート」「画像」「リンク」を持つ。「いいね」と名付けたトピックに他のアクティビティへのリンク付きアクティビティを投稿することで、ユーザーは「いいね」機能を「実装」できてしまうわけだ。非常に面白い!

また書き留めるサービスという観点から、アクティビティを再編集したり別のトピックに移して整理しなおせるというのも理に適った仕様だと思う。

一個人として自分はトピックを使い分けられるだろか?

19年 Web 日記を書き 11年 Tweet している身として「日常生活の中で使える時間は有限。メディアやアカウントをテーマ別に使い分けてどれも充実させていくというのは時間的にもネタ的にもかなり大変である。そもそも興味のあるテーマもどんどん変わっていく。なのでテーマ別に分けない方が良い」だと自分自身については思っている。

それからソーシャルメディアの投稿を読むという立場で考えてみてると「何のテーマの投稿か?」以上に「誰の投稿か?」を自分は重視しているなと。やはりトピックではなく人をフォローしたいのだ。うん。

1日使っただけで Trickle のサービスやモデルの良否は語れるものではないので、以上あくまでもファーストインプレッションということで。

知っている人がどんどん使い始めたら、もっと便利さが感じられるのかもしれない。……あ、やはり人をフォローしたいんだな。

[ 11月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.085037s / load averages: 0.44, 0.49, 0.53
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker