nDiki : 画像

画像 - イメージ、image、picture

2018年5月22日 (火)

今日のさえずり: CHUMS 大好き。ついつい表参道のお店に行っちゃう。

2018年05月22日

[ 5月22日全て ]

2018年5月23日 (水)

Lightroom での現像設定を XMP ファイルか JPEG メタデータ内に保存

rimage:/nDiki/2018/05/23/2018-05-22-204136-nDiki-800x1200.jpg

Adobe Creative Cloudフォトプランを購入したので Adobe Photoshop Lightroom CC mobile の Android 版も使い始めてみました。

Lightroom CC mobile

Lightroom CC mobile 単独としては

  • 当たり前のように無音カメラだったりする(設定すらない)。
  • 3:2 が選べる。
  • と思ったらフレーミングと非破壊切り抜きに設定に反映されているだけで、デバイスで撮れる最大の範囲で裏で撮影されていた。あとで切り抜き直せる。

など「らしい」仕様カメラ機能が内蔵されているのがユニークでした。

編集機能としては「Upright による遠近法の自動補正」がついているのがめちゃくちゃ嬉しいところです。水平が出しにくい DSC-RX0 で撮影したあと外出先で Wi-Fi でスマートフォンへ転送し、ささっと補正して Twitter などに投稿できます。便利!

Lightroom CC mobile での現像設定は?

今のところ PlayMemories Mobile (ソニー)も Camera Connect (キヤノン)のどちらも RAW 画像そのものは Wi-Fi 転送できないので、スマートフォン (Xperia Z5) の Lightroom CC mobile では JPEG ファイルに対する編集のみを使うことになりそうです。

さて外出先でさっとした編集を、あとで最終的にデスクトップ PC 側でどうやって管理すれば良いのでしょうか。

確認したところ Lightroom CC mobile は JPEG ファイルに対する編集はそのファイルのメタデータに直接書き込んでました。なので Lightroom Classic CC 側で同期すれば、そのまま調整済みの JPEG ファイルとして手元に落ちてきます(ライブラリでは画像の調整バッジが表示される)。ちなみに Lightroom Classic CC の設定でも「JPEG、TIFF、PNG、および PSD ファイル内のメタデータに現像設定を含める」が最初からオンになっていました。 JPEG ファイルの編集についての Lightroom の方針を理解。

Lightroom Classic CC の RAW 画像ファイルの現像設定

Lightroom Classic CC では現像設定はカタログに保存されるのですが、調べたところ RAW 画像ファイルと同名で拡張子が xmp の XMP ファイルに保存させることもできるのですね。

個人的に画像ファイルと一緒に現像設定を保存しておきたいので「変更点を XMP に自動的に書き込む」をオンにしました。

自分の中で、現像・編集設定の管理方法がなんとなく固まってきた感じです。

[ 5月23日全て ]

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日全て ]

About Me

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

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

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

follow us in feedly

月別インデックス
Process Time: 0.097111s / load averages: 0.57, 0.47, 0.56
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker