パスワードを忘れた? アカウント作成
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
2023年3月19日の記事一覧(全6件)
16536072 story
グラフィック

ブラウザーの実行ファイル名によって最適化を行う AMD の GPU ドライバー 46

ストーリー by headless
最適 部門より
Yandex のエンジニアが Yandex Browser のパフォーマンスと安定性の問題を調べていたところ、AMD の GPU ドライバーの挙動がブラウザーの実行ファイル名によって変わることを発見したそうだ (Neowin の記事Habr の記事)。

発見のきっかけとなったのは、Lenovo のノート PC に搭載されたタッチパッドでウェブページをスクロールする際、Yandex Browser ではひどくカクカクした動作になるのに対し、Google Chrome や Microsoft Edge では滑らかな動作がみられたことだ。Chrome も Yandex も Chromium ベースであり、タッチパッドイベントの処理もオープンソースの Chromium と違いはみられないという。そのため、何か他の部分に問題があると考えて調査を進め、実行ファイル名を「browser.exe」から「chrome.exe」に変えると問題が解消することを発見する。

ゲームアプリでは実行ファイル名によって GPU ドライバーが最適化を行うことが知られているが、Yandex は AMD の GPU ドライバーがブラウザーアプリでも実行ファイル名によって最適化を行うという仮説を立てて実験。Chromium のサンドボックス機能を利用して「GetModuleFilenameA/GetModuleFilenameW」関数と「GetModuleFilenameExA/GetModuleFilenameExW」関数が返す実行ファイル名をbrowser.exe」から「chrome.exe」に変更してテストを実行したところ、GPU プロセスのクラッシュ回数は 5.5 分の 1 に減り、メモリ使用量は 8% 減少したという。ウェブページの読み込みやユーザーインターフェイスの反応もわずかに向上したそうだ。

この結果を受けて Yandex は AMD に「browser.exe」を最適化対象の実行ファイル名リストに加えるよう要請する一方、Windows 版の Yandex Browser バージョン 22.9.0 以降では GPU プロセスで「chrome.exe」のふりをするよう変更したとのことだ。
16536146 story
人工知能

米著作権局、AI を用いた作品の著作権登録に関するガイダンスを公開 32

ストーリー by headless
人間 部門より
米著作権局は 16 日、人工知能 (AI) 技術の急速な進化による著作権法や政策の問題を調査するイニシアチブを開始するとともに、AI を用いた作品の著作権登録に関するガイダンスを公開した (著作権局のニュース記事ガイダンス: PDFVentureBeat の記事Ars Technica の記事)。

米著作権局では AI が生成した画像の著作権登録を 3 回にわたって拒絶しており、いったん著作権登録したコミックブックについて、AI による生成が後日判明したアートワークを登録から除外している。新しいガイダンスでは AI をツールとして使用した著作物の著作権登録が可能であることを明確にする一方で、著作権が保護されるのは人間が著作者である場合に限られるという方針に変更はない。

たとえば、人間が送ったプロンプトのみから AI がコンテンツを生成した場合、プロンプトを送る行為は (人間の) アーティストに作品の制作を注文する行為と同様だという。プロンプトを送った人間や注文者が著作者になることはなく、注文を受けて制作された作品はアーティストの著作物として著作権保護の対象になるが、AI が生成したコンテンツは著作権保護の対象にならない。一方、AI の生成物を人間が十分創造的に選択・配置したり、改変したりすれば人間が著作者として認められ、著作権保護の対象になる。

そのため、AI の生成物を用いた著作物の著作権登録申請にあたっては、「著作者」の項に記載する人間がどのように創造的な役割を果たしたのかを記載する必要がある。使用した AI 技術や提供企業を著作者や共同著作者として記載すべきではない。また、僅少でない量の AI 生成コンテンツは申請書で明確に除外する必要がある。既に申請済みの著作物が上述の内容に該当する場合、修正申請を行わないと著作権登録が無効になる可能性もあるようだ。
16536185 story
Google

Google Pixelのマークアップツールで編集前の画像が復元できる脆弱性、エクスプロイトが公開 12

ストーリー by headless
復元 部門より
Google は Pixel の「マークアップ」ツールで発見された脆弱性 (CVE-2023-21036) を 3 月のアップデートで修正したが、これを利用するエクスプロイト「aCropalypse」が公開されている (エクスプロイト作者のブログ記事9to5Google の記事Android Police の記事Simon Aarons 氏のツイート)。

マークアップはスクリーンショット撮影時に表示され、画像のクロップや書き込み・塗りつぶし等を可能にする。CVE-2023-21036 では編集の結果を保存する際にファイルサイズを切り詰めずに新しい画像データを上書きするため、元のデータが一部残されてしまう。具体的な処理を知ることは難しいが、エクスプロイト作者の David Buchanan 氏は Android 10 以降で 2021 年に修正された ParcelFileDescriptor.parseMode のバグとみているようだ。

脆弱性が修正されても既に保存したファイルが更新されるわけではない。このような画像をソーシャルメディアアプリやメッセージングアプリなどで送信する場合、読み取れない元の画像データはメタデータとともに削除されるが、Discord では 1 月までこのような処理が行われていなかったという。そのため、それ以前にアップロードしたスクリーンショットでは、隠したつもりの部分が復元されてしまう可能性がある。

エクスプロイトの作者が過去に使用していた Pixel 3XL のスクリーンショットを Discord からダウンロードして復元処理を行ってみたところ、eBay の確認メールのスクリーンショットから自宅住所全体が復元されたそうだ。なお、復元処理はすべてローカルで行われるとのことだ。
16536286 story
ビジネス

Virgin Orbit、資金繰り悪化で 21 日まで事業停止 22

ストーリー by headless
停止 部門より
あるAnonymous Coward 曰く、

米宇宙ベンチャーのVirgin Orbit が資金繰りの悪化により、3月21日まで一時的に事業を停止すると米証券取引委員会に届け出ている (Form 8-Kロイターの記事, CNBC の記事)。

報道によれば、業務停止は新たな投資計画がまとまるまで時間を稼ぐのが目的で、ほぼ全ての従業員が対象だという。資金調達に向けた交渉では戦略的な選択肢を検討しているとのこと。同社の株価は 30% 急落している。

同社は 2021 年に空中発射ロケット「LauncherOne」の打ち上げに成功したものの、今年 1 月の打ち上げは失敗した。LauncherOne は日本の大分空港からの打ち上げも計画しており、宇宙ベンチャーの中では日本と関係が深いかもしれない。親会社のヴァージングループは大企業であるが、コロナ禍でグループ内の航空会社なども倒産している。

16536342 story
月

Samsung 曰く、ぼやけた月でも月と認識できればくっきり明るい月の写真になる 89

ストーリー by headless
i-thank-thee-moon-for-shining-now-so-bright 部門より
Galaxy シリーズの「スペースズーム」機能による月の写真が偽物だと再び話題になったことを受け、Samsung が解説記事を公開している (Samsung Mobile Press の記事The Verge の記事Ars Technica の記事)。

Samsung に限らず、スマートフォンで撮影した月の写真が合成ではないかとの疑惑はこれまでにも話題となっている。この記事自体も新しいものではなく、Samsung が昨年 10 月に韓国版サイトで公開した記事を英訳したもののようだ。記事によれば、Galaxy シリーズがくっきりした月の写真を撮影できるのは超解像技術とシーン最適化技術の組み合わせによるものだという。超解像は 25 倍以上のズーム倍率で撮影する際、10 点以上の写真を 1 枚の写真に合成することでノイズを除きつつ細部を強調する。さらにシーン最適化を有効にすると、AI 深層学習により認識した被写体に合わせた細部の強調や明るさの調整を行う。これにより、故意にぼやけた画像になるよう編集した月の写真を撮影しても、月であると認識しさえすれば明るくはっきりした月の写真が得られるようだ。シーン最適化を使いたくなければ、カメラの設定で無効化することも可能とのことだ。
16536355 story
プログラミング

ソースコードの中で罵倒してる? 147

ストーリー by headless
罵倒 部門より
カールスルーエ工科大学の学生、Jan Strehmel 氏が C 言語で書かれたオープンソースコードを調べたところ、罵倒語を含むソースコードがコーディング標準により準拠していたそうだ (論文: PDFArs Technica の記事)。

調査は GitHub で公開されている C 言語のオープンソースコードを用い、Strehmel 氏の所属する研究グループが開発したオープンソースのコーディング標準準拠チェックツール「SoftWipe」で 10 点が満点となる評価を行っている。対象は 300 個以上の英語の罵倒語のうち少なくとも 1 個含む 3,800 件以上のリポジトリと、罵倒語を含まない 7,600 件以上のリポジトリとなっている。

SoftWipe による評価は罵倒語を含まないリポジトリで中央値 5.41 (信頼区間 5.38-5.45、標準誤差 0.02)、罵倒語を含むリポジトリで中央値 5.87 (信頼区間 5.81-5.93、標準誤差 0.01) となり、罵倒語を含む方が 0.5 点ほど高くなっている。普段から自分の各ソースコードでしばしば罵倒語を使う指導教授の Alexandros Stamatakis 氏はこの結果を聞き、「cool」と思ったそうだ (残念)。

Strehmel 氏は同じ研究室のメンバーから Linux のソースコードに多数の罵倒語が含まれるというグラフを見せられて今回の研究を思いついたという。Linux 開発者の Linus Torvalds 氏は罵倒表現でも知られるが、Linux のソースコードでは 2018 年の Code of Conduct 更新を境に「fuck」が急減したようだ。スラドの皆さんはソースコード内で罵倒しているだろうか。
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...