Tech

はじめに IIIF（International Image Interoperability Framework）ビューアとして広く使われているMiradorで、以下の要件を満たす実装を行いました： URLパラメータで指定したキャンバス（ページ）を初期表示する 指定したキャンバス内の検索語をハイライト表示する 本記事では、この要件を実現するためのアプローチと実装方法を共有します。 アプローチの検討 defaultSearchQueryオプション Mirador 4では、ウィンドウ設定に defaultSearchQuery オプションを指定することで、初期化時に自動的に検索を実行できます： c } o ) n w } ; s i ] t n m c d , d a a e m o n n f i w i v a r s f a u a : e s l d s I t o [ t d S r { I : e V d a i : c r e a c w m n h e a v Q r n a u i s e = f I r e d y M s , : i t r U ' a r 検 d l 索 o , 語 r ' . , v i e w e r ( { このオプションは検索を自動実行する便利な機能ですが、今回の要件では以下の点を考慮する必要がありました： ...

はじめに データ可視化ツール RAWGraphs を日本語化し、公開しました。 https://rawgraphs-ja.vercel.app/ RAWGraphsは、複雑なデータを美しいビジュアライゼーションに変換できるオープンソースのWebアプリケーションです。コーディング不要で、CSVやJSONデータをドラッグ＆ドロップするだけで、様々なチャートを作成できます。 RAWGraphsとは RAWGraphsは、イタリアのDensityDesign Research Labが開発したデータ可視化ツールです。 https://www.rawgraphs.io/ 主な特徴： コーディング不要 : ブラウザ上でデータをペーストするだけ 多様なチャート : Alluvial Diagram、Treemap、Voronoi Tessellationなど30種類以上 SVGエクスポート : 作成したチャートをSVGやPNG形式でダウンロード可能 プライバシー保護 : データはサーバーに送信されず、ブラウザ内で処理 使用ライブラリ { } " " i r 1 e 8 a n c e t x - t i " 1 : 8 n " e ^ x 2 t 1 " . : 1 0 " . ^ 0 1 " 1 , . 1 8 . 6 " ! ...

Next.js App Router と next-intl を使用した多言語対応アプリケーションで、リロードなしの言語切り替えを実装する方法をまとめます。 環境 Next.js 16 (App Router) next-intl TypeScript 設定概要 localePrefix: ‘as-needed’ とは next-intl の localePrefix: 'as-needed' 設定を使用すると、デフォルト言語ではURLにプレフィックスが付かず、その他の言語のみプレフィックスが付きます。 例（デフォルト言語が日本語の場合）: 日本語: /, /gallery, /viewer 英語: /en, /en/gallery, /en/viewer 実装手順 1. Middleware設定（重要） next-intl は middleware を使用してロケールのルーティングを処理します。静的ファイルが middleware によってリダイレクトされないよう、matcher の設定が重要です。 i i e e } m m x x p p p p m m o o o a i r r r r t d t t t t S c d k h l c { d c i e e r e o p r w e r f n : a a o a s m r t u u t i [ e e t l d ' . M i t c d / t i n o l ( s d g c n e ( d r f w ? l } e i a ! e a g r a w f t e p a r e = i r o M f | e m i { o _ d r n f d e r l s x o / e t t m s w a | r a t . ' c r i * n / e c \ e i ( \ x 1 r f . t 8 o i . - n u l * i / t e ) n r i s . t o n * l u g a ) / t ) n ' m i d ] i n d g A d ' P l I e w r a o r u e t ' e s 注意 : .*\\..* は「ドットを含むパス」を除外します。これにより /og-image.png などの静的ファイルがmiddlewareをスキップし、正常にアクセスできるようになります。 ...

はじめに 高解像度画像をWeb上で快適に閲覧するためには、ピラミダル構造（複数解像度）とタイル分割が不可欠です。本記事では、vipsを使用してJPEG2000画像からピラミダルタイルTIFFを作成し、各圧縮方式のファイルサイズを比較検証しました。 検証環境 vips 8.17.3 macOS (darwin) 元画像: 764029-1.jp2 (274MB) 出典: 国立公文書館デジタルアーカイブ vipsコマンド JPEG圧縮（非可逆） # v # v # v i i i 品 p 品 p 品 p 質 s 質 s 質 s 1 7 2 0 t 5 t 5 t 0 i （ i （ i （ f バ f 高 f ほ f ラ f 圧 f ぼ s ン s 縮 s 無 a ス a ） a 劣 v 型 v v 化 e ） e e ） i i i n n n p p p u u u t t t . . . j j j p p p 2 2 2 o o o u u u t t t p p p u u u t t t _ _ _ q q q 1 7 2 0 5 5 0 . . . t t t i i i f f f - - - t t t i i i l l l e e e - - - p p p y y y r r r a a a m m m i i i d d d - - - c c c o o o m m m p p p r r r e e e s s s s s s i i i o o o n n n = = = j j j p p p e e e g g g - - - Q Q Q = = = 7 2 1 5 5 0 0 ロスレス圧縮 # v # v # v i i i D p L p 無 p e s Z s 圧 s f W 縮 l t 圧 t （ t a i 縮 i 4 i t f f G f e f f B f 圧 s s 超 s 縮 a a の a （ v v 場 v z e e 合 e l は i i i B i b n n i n ） p p g p u u T u t t I t . . F . j j F j p p 形 p 2 2 式 2 が o o 必 o u u 要 u t t ） t p p p u u u t t t _ _ _ d l n e z o f w n l . e a t . t i t e f i . f t i - f t - i t l i - e l t e i l - e p - y p r y - a r p m a y i m r d i a d m i - d c - o c m o - p m c r p o e r m s e p s s r i s e o i s n o s = n i l = o z n n w o = n d e e f l - a b t i e g t i f f 検証結果 ファイル 圧縮方式 サイズ 元ファイル比 備考 元ファイル JPEG2000 274MB - 入力 q25.tif JPEG Q=25 57MB 0.21x 非可逆・高圧縮 q75.tif JPEG Q=75 167MB 0.61x 非可逆・バランス q100.tif JPEG Q=100 2.4GB 8.8x 非可逆・高品質 deflate.tif Deflate 2.8GB 10.2x ロスレス lzw.tif LZW 3.2GB 11.7x ロスレス none.tif 無圧縮 4.3GB 15.7x ロスレス 画質比較 JPEG圧縮の品質による違いを視覚的に比較しました（左から Q=25, Q=75, Q=100）。 ...

概要 3Dビューワーでアノテーションが多数ある場合、背面判定（Raycast）処理がパフォーマンスのボトルネックになります。本ドキュメントでは、採用した改善手法について説明します。 問題 アノテーションの背面判定には、各アノテーションに対してRaycast（光線とメッシュの衝突判定）を実行する必要があります。この処理は以下の理由で重くなります： メッシュの全頂点との衝突判定が必要 アノテーション数に比例して計算量が増加 毎フレーム実行すると60FPSの維持が困難 解決策: Idle時のみRaycast実行 カメラが停止した時のみRaycast処理を実行 する方式を採用しました。 動作フロー カ カ 3 1 次 メ メ 0 回 に ラ ラ フ だ カ 移 停 レ け メ 動 ↓ 止 ↓ ー ↓ R ↓ ラ 中 検 ム a が 出 待 y 動 → 機 c く （ a ま R 約 s で a 0 t 再 y . 実 計 c 5 行 算 a 秒 し s 、 な t 安 い 処 定 理 化 を ） ス キ ッ プ （ 軽 量 ） 実装詳細 c c u } o o s ) n n e c p i } i i i n ; パ s s F o r f d f f e フ t t r n e i n r l e ォ a カ s v ( d e e カ e 停 ( ( R d ー C I m メ t C c l e t メ F 止 ! i a s マ A D e ラ a a カ e d u ラ r 後 n d y R ン M L ( の c m m メ F s r が a 、 e l c a ス E E ( 移 a e e ラ r R n 停 m 一 e e a y R 設 R _ ) 動 m r r が a a ; 止 e 定 d F s c a 定 A F 量 e a a 動 m y し C フ s r t a y _ R = を r P M い e c て o レ R a 実 s c M A > チ a o o て C a い u ー a m 行 t a O M ェ M s v い o s る n ム y e （ R s V E { ッ o i e る u t R t 待 c C 1 e t E S ク v t d 間 n R a R っ a o 回 f 処 _ _ e i ) は t e y e て s u の . 理 T B d o カ R f c f か t n み c H E n { ウ e . a . ら R t ） u R F = . ン f c s c R e R r E O c タ . u t u a f e r S R c o を c r 処 r y . f e H E a p リ u r 理 r c c . n O _ m y セ r e を e a u c t L R e ( ッ r n ス n s r u D A r c ト e t キ t t r r = Y a a n ッ + 実 e r = C . m t = プ + 行 n e f A p e ; （ t n a 0 S o r = t 1 ) t l . T s a r 回 s 0 i . 0 u の r < e 1 = t p ; e み e ; ; i o ; ） t I 3 o s u D 0 n i r L ; . t n E d i ; _ カ i o F メ s n R ラ t ) A 移 停 a ; M 動 止 n E の 後 c S 閾 こ e _ 値 の T B （ フ o E ス レ ( F ク ー p O ロ ム r R ー 数 e E ル 待 v _ 時 っ C R の て a A 微 か m Y 小 ら e C な R r A 動 a a S き y P T を c o ) 無 a s 視 s i r ） t t e （ i t 約 o u 0 n r . ) n 5 ; 秒 > @ C A 6 M 0 E f R p A s _ ） M O V E _ T H R E S H O L D ; 2段階の判定処理 Raycast処理自体も最適化しています： ...

はじめに 古地図や古文書には、様々な方向に傾いた文字が含まれています。本ツールでは、多角形（ポリゴン）アノテーションを使用して傾いた文字を正確にマークアップし、その傾き情報を活用してIIIF Image APIで回転補正された画像を取得できます。 傾き計算の仕組み 頂点の順序ルール 多角形アノテーションを作成する際、以下の順序で頂点を指定します： 左上 → 2. 左下 → 3. 右下 → 4. 右上 この反時計回りの順序を守ることで、傾き角度を一意に計算できます。 左 左 上 下 ( ( 1 │ │ │ 2 ) ) ─ ─ ─ ─ ─ ─ ─ 文 ─ ─ 字 ─ ─ 領 ─ ─ 域 ─ ─ ─ ─ ─ ─ ─ ─ ─ 右 右 上 │ 下 ( ( 4 3 ) ) │ │ 以下のデモ動画も参考にしてください。 ...

Amazon Elasticsearch Service から別の OpenSearch クラスタへデータを移行する方法を解説します。本記事では、Scroll API と Bulk API を使用したシンプルかつ確実な移行手法を紹介します。 背景 クラウドサービスの移行やコスト最適化のため、Elasticsearch/OpenSearch クラスタ間でデータを移行する必要が生じることがあります。今回は以下の環境間での移行を行いました。 移行元 : Amazon Elasticsearch Service (AWS) 移行先 : セルフホスト OpenSearch 移行の流れ 移行元・移行先のインデックス確認 マッピング情報の取得と調整 移行先にインデックスを作成 Scroll API + Bulk API でデータ移行 移行結果の確認 事前準備：インデックスの確認 まず、移行元と移行先のインデックス一覧を確認します。 # c # c u u 移 r 移 r 行 l 行 l 元 先 の - の - イ u イ u ン ン デ " デ " ッ u ッ u ク s ク s ス e ス e 一 r 一 r 覧 : 覧 : p p a a s s s s w w o o r r d d " " " " h h t t t t p p s s : : / / / / s d o e u s r t c - e c - l c u l s u t s e t r e / r _ / c _ a c t a / t i / n i d n i d c i e c s e ? s v ? & v s & = s i = n i d n e d x e " x " Step 1: マッピング情報の取得 移行元からマッピング情報を取得します。 ...

このドキュメントでは、Docker コンテナを GitHub Actions で自動デプロイする設定手順を説明します。 目次 Docker 設定 GitHub Actions 設定 サーバー側の設定 トラブルシューティング Docker 設定 Dockerfile（静的サイト + nginx） 静的 HTML を生成し、nginx で配信します。 F W C R C R # F # # C C E C R O O U O U R O O X M O R P N P N 静 O N N P P P D M K Y Y 的 M u u Y Y O D n n フ x x S [ n I p p . p ァ n t t n E " o R a m m イ g - g n d c ル i 3 2 f i 8 g e / k i r 配 n r n 0 i : a a n u 信 x の の o x n 2 p g s n 用 : 場 場 m . x 2 p e t の a 合 合 = c " - * a g n l : : b o , a . l e g p u n l j l n i i d i f " p s e n n o i l - i o r x e u s d / g n n a t t e e " e t p r t , e u c A t / / " S / a n d p p g a b u p i e u b / n m i l . x o l i o / n d c u c e t o o r p n f u f f t . ; d " p / ] u d b e l f i a c u l / t u . s c r n s f h a r e / n g i n x / h t m l nginx.conf（SPA 用設定） SPA では動的ルート（/item/:id など）を index.html にフォールバックさせる必要があります。 ...

Insta360などで撮影した360度コンテンツ（equirectangular形式）から、自然な見た目のサムネイル画像を作成する方法を紹介します。 課題：そのままリサイズすると歪む 360度動画や写真はequirectangular（正距円筒図法）形式で保存されています。この形式は球体を平面に展開したもので、特に上下の端に近いほど横方向に引き伸ばされています。 そのまま単純にリサイズしてサムネイルを作成すると、歪んだ不自然な画像になってしまいます。 # f f 単 m 純 p な e リ g サ イ - ズ i （ 歪 3 ん 6 だ 0 サ v ム i ネ d イ e ル o に . な m る p ） 4 - s s 0 0 : 0 0 : 0 5 v f r a m e s 1 v f " s c a l e = 6 4 0 : - 1 " t h u m b . j p g 解決策：v360フィルターでflat projectionに変換 ffmpegのv360フィルターを使用して、equirectangular形式からflat（rectilinear/透視投影）形式に変換することで、人間の目で見たような自然な画像を切り出せます。 ...

Insta360で撮影した360度動画ファイル（.insv）にGPS情報が含まれているかどうかを、コマンドラインから機械的に確認する方法を紹介します。 背景 Insta360カメラで撮影した動画には、GPS機能が有効な場合に位置情報が埋め込まれます。しかし、撮影時の設定やGPS信号の受信状況によって、GPS情報が含まれるファイルと含まれないファイルが混在することがあります。 大量のファイルを整理する際、GPS情報の有無でファイルを分類したいケースがあります。 使用ツール exiftool を使用します。macOSの場合、Homebrewでインストールできます。 b r e w i n s t a l l e x i f t o o l ポイント：-ee オプションが必須 Insta360の.insvファイルは、GPS情報を標準的なEXIFタグではなく、MP4コンテナ内の独自トラックに埋め込んでいます。 そのため、通常のexiftoolコマンドではGPS情報を読み取れません。 # e # x こ i （ れ f 出 で t 力 は o な G o し P l ） S 情 - 報 G が P 見 S つ P か o ら s な i い t i o n v i d e o . i n s v -ee（extractEmbedded）オプションを使用することで、埋め込まれたメタデータトラックからGPS情報を抽出できます。 ...

はじめに Webサイト上で高解像度画像をスムーズにズーム表示するために使用されるDeep Zoom技術。Microsoft Deep Zoom Composerなどで生成されたタイル化された画像データから、元の高解像度画像を復元する必要に迫られることがあります。 本記事では、Deep Zoom形式で公開されている画像データから、元の高解像度TIFF画像を復元する技術について解説します。 Deep Zoom画像の仕組み タイル構造 Deep Zoom画像は、1枚の大きな画像を複数の小さなタイル画像に分割し、ピラミッド構造で保存します： レベル0 : 最も低解像度（通常1タイル） レベルN : 最高解像度（元画像の解像度に相当） 各レベルで解像度が2倍になる ファイル構成 d d z z c c ├ │ ├ │ │ └ _ _ ─ ─ ─ o o ─ ─ ─ u u t t 0 └ 1 ├ └ 1 ├ ├ └ p p / ─ / ─ ─ 6 ─ ─ ─ u u ─ ─ ─ / ─ ─ ─ t t . _ 0 0 0 0 x f _ _ _ _ m i 0 0 0 1 l l . . . . e j j j j s p p p p / g g g g # # # # レ メ ベ 最 数 タ ル 高 万 デ 0 レ 枚 ー の ベ の タ 唯 ル タ 一 イ の ル タ イ ル 実装の課題と解決策 課題1: XMLメタデータの名前空間の違い Deep Zoomには複数のバージョンがあり、XMLの名前空間が異なります： ...

はじめに チベット語写本のデジタル化は、デジタル人文学における重要な課題の一つです。貴重な仏教経典や歴史文書が世界中の図書館に保管されていますが、その多くはまだテキストデータ化されていません。手作業での文字起こしには膨大な時間とコストがかかり、専門知識を持つ研究者も限られています。 本記事では、BDRC Tibetan OCR を紹介します。このツールは、Buddhist Digital Resource Center (BDRC) によって開発されたオープンソースのチベット語OCRシステムです。 また、チベット語写本カンギュール114点 をデジタル化するプロジェクトでの実装事例も紹介します。 BDRC Tibetan OCRとは BDRC Tibetan OCR は、チベット語の画像からテキストを自動抽出する無料のオープンソースツールです。 主要な特徴 1. デスクトップアプリケーション Windows、macOS（Intel/M1,M2）で動作するGUIアプリケーションです。 インストール方法: リリースページから各OS用のZIPファイルをダウンロード 解凍して実行ファイルを起動するだけ 2. 複数の出力形式 プレーンテキスト : 抽出されたUnicodeチベット文字 PageXML : 座標情報付きXML（Transkribusと互換） Wylie : ローマ字転写形式 3. 画像補正機能 歪み補正（Dewarping） : ページの湾曲を補正 回転補正 : 自動的にページの傾きを検出・補正 行検出 : 行分割機能 4. バッチ処理対応 複数の画像ファイルを一括処理 PDFファイルからの直接OCR IIIF（International Image Interoperability Framework）マニフェストからの自動取得・処理 4つの専門OCRモデル BDRC Tibetan OCRの特徴の一つは、書体や資料の種類に応じて最適化された4つの専門モデル を提供している点です。 1. ウチェン（Uchen）モデル - 現代印刷用 用 デ 特 適 途 ー 徴 用 : タ : 例 セ : 印 ッ チ 刷 ト ベ コ さ : ッ ン れ ト ピ た 4 語 ュ 経 4 で ー 典 0 最 タ 、 万 も ー 現 サ 標 フ 代 ン 準 ォ の プ 的 ン 出 ル な ト 版 の 書 で 物 統 体 印 一 刷 ウ さ チ れ ェ た ン テ モ キ デ ス ル ト 、 木 版 印 刷 ウチェンは「正書体」を意味し、チベット語で最も標準的な書体です。現代の印刷物やデジタルフォントで使用されます。 ...

問題の概要 Cesium.js 1.135.0を使用したReactアプリケーションにおいて、CLAMP_TO_GROUND設定を使用したビルボードマーカーの位置が、カメラの移動やズーム操作後に不正確になる現象が確認された。 環境 Cesium.js : 1.135.0（問題発生）→ 1.134.0（問題解消） フレームワーク : Next.js 16.0.1 + React 19.2.0 地形データ : Cesium World Terrain (Cesium.Terrain.fromWorldTerrain()) マーカー設定 : clampToGround: true heightReference: Cesium.HeightReference.CLAMP_TO_GROUND 症状 特定のマーカーをクリックしてズーム（拡大） カメラの視点を変更（回転・パン） 遠くにあるマーカーを確認すると、地形から浮いているか、不正確な位置に表示される この問題は、カメラが近距離に移動した際に読み込まれる高解像度の地形データ（LOD: Level of Detail）と、遠方のマーカーが参照する低解像度の地形データとの不整合によって発生すると考えられる。 調査プロセス 試行1: カメラ制御の明示化 マーカークリック時にsampleTerrainMostDetailedを使用して地形高度を取得し、明示的にカメラを移動させる実装を試みたが、問題は解消されなかった。 試行2: heightReferenceの変更 heightReferenceをCLAMP_TO_GROUNDからNONEに変更し、disableDepthTestDistanceを使用する実装を試みたが、この場合はマーカーが地形に正しく配置されず、別の問題が発生した。 試行3: バージョン比較 動作確認用のHTMLファイル（Cesium 1.110.0使用）では同様の問題が発生しないことを確認。Cesiumのバージョンが問題の原因である可能性を特定。 解決策 Cesium.jsを1.135.0から1.134.0にダウングレードすることで問題が解消された。 n p m i n s t a l l c e s i u m @ 1 . 1 3 4 . 0 技術的背景 CLAMP_TO_GROUNDの動作 CesiumのCLAMP_TO_GROUND設定は、エンティティを地形の表面に固定する機能を提供する。この機能は地形タイルのLOD（Level of Detail）に依存しており、カメラの位置によって異なる解像度の地形データが使用される。 ...

現代のインターネットは高速で洗練されていますが、かつての「インターネット黎明期」の雰囲気を懐かしく思う方も多いのではないでしょうか。Protowebは、そんな1990年代のインターネット体験を現代に蘇らせる、コミュニティ主導の公共サービスです。 Protowebとは？ Protowebは、インターネット黎明期のウェブサイトをホスティングし、当時のブラウジング体験を再現するプロキシサーバーサービスです。歴史的なウェブサイトを保存・復元することで、1995年頃のインターネットの姿をそのまま体験できる環境を提供しています。 主な特徴 歴史的なウェブサイトの復元 ：天気予報、ニュース、音楽、ゲーム、ダウンロードサイトなど、多様なコンテンツが利用可能 プロキシサーバー方式 ：ブラウザの設定を変更するだけで、すぐに体験できる 登録不要 ：アカウント作成やサインアップは必要なし 日々更新 ：新しいクラシックウェブサイトが継続的に追加されている プロキシサーバーとは？初心者向け解説 Protowebを使うには「プロキシサーバー」の理解が必要です。初めて聞く方にもわかりやすく説明します。 プロキシサーバーの基本 プロキシサーバー とは、あなたのパソコンとインターネットの間に立って、通信を「中継」してくれるコンピュータのことです。 通常のインターネット接続 あ な た の パ ソ コ ン → 直 接 → ウ ェ ブ サ イ ト プロキシサーバーを使う場合 あ な た の パ ソ コ ン → プ ロ キ シ サ ー バ ー → ウ ェ ブ サ イ ト なぜProtowebにはプロキシ設定が必要なの？ 重要：プロキシサーバーの設定をしないと、Protowebにアクセスできません。 ...

はじめに デジタルデータの長期保存は、図書館、アーカイブ、研究機関にとって重要な課題です。データ形式の変化、ソフトウェアの陳腐化、ストレージ技術の進化など、様々な要因がデジタル情報の持続可能性を脅かしています。 本記事では、この課題に対する解決策の一つである**OCFL（Oxford Common File Layout）**について、その概念、意義、そして実装例を紹介します。 OCFLとは OCFL（Oxford Common File Layout） は、デジタル情報を構造化され、透明で、予測可能な方法で保存するための仕様です。オックスフォード大学のボドリアン図書館とスタンフォード大学図書館を中心に開発され、現在はコミュニティ主導のオープンスタンダードとして発展しています。 OCFLの公式定義 “OCFLは、アプリケーション非依存のアプローチでデジタル情報を保存するための仕様であり、長期保存とデータの完全性を保証します。” OCFLの5つの主要原則 完全性（Completeness） - リポジトリをストレージファイルから完全に再構築可能 解析可能性（Parsability） - 人間と機械の両方が理解できる構造 堅牢性（Robustness） - エラーや破損に対する耐性 バージョン管理（Versioning） - オブジェクトの変更履歴を保持 ストレージの多様性（Storage Diversity） - 様々なストレージインフラに対応 なぜOCFLが必要なのか デジタル保存の課題 従来のデジタル保存には、以下のような課題があります： ベンダーロックイン - 特定のシステムやソフトウェアに依存してしまう 移行の困難さ - システム更新時のデータ移行が複雑 透明性の欠如 - データがどのように保存されているか不明瞭 長期的な可読性 - 数十年後もデータを読み取れる保証がない OCFLによる解決 OCFLは、以下のアプローチでこれらの課題を解決します： シンプルなファイル構造 - 標準的なファイルシステムを使用 JSONによるメタデータ - 人間が読める形式で管理情報を保存 ハッシュによる完全性検証 - データの破損を検出可能 透明なバージョニング - すべての変更履歴が追跡可能 OCFLの基本構造 OCFLリポジトリは、以下のような階層構造を持ちます： o ├ ├ └ c ─ ─ ─ f ─ ─ ─ l _ 0 o o ├ ├ ├ └ r = c b ─ ─ ─ ─ o o f j ─ ─ ─ ─ o c l e t f _ c 0 i i v ├ ├ └ / l l t = n n 1 ─ ─ ─ _ a - o v v / ─ ─ ─ 1 y 0 c e e . o 0 f n n i i c └ 1 u 1 l t t n n o ─ t _ o o v v n ─ . o r r e e t j b y y n n e s s j . . t t n a o e j j o o t m n c s s r r / p t o o y y l _ n n . . e 1 . j j . . s s s t 1 h o o x a n n t 5 . 1 s 2 h a 5 1 2 # # # # # # # # # O レ O オ オ イ バ こ 実 C イ C ブ ブ ン ー の 際 F ア F ジ ジ ベ ジ バ の L ウ L ェ ェ ン ョ ー コ 仕 ト オ ク ク ト ン ジ ン 様 情 ブ ト ト リ 1 ョ テ バ 報 ジ バ の の ン ン ー ェ ー 完 チ ま ツ ジ ク ジ 全 ェ で ョ ト ョ な ッ の ン ン 履 ク 履 を マ 歴 サ 歴 示 ー ム す カ マ ー ー カ ー inventory.json - OCFLの心臓部 inventory.jsonはOCFLオブジェクトの最も重要な要素で、以下の情報を含みます： ...

はじめに iPRES（International Conference on Digital Preservation）のワークショップに参加した際、デジタル保存の実践的な演習でHexエディタ「HxD」が使用されました。バイナリファイルの構造解析やファイルフォーマットの確認など、デジタルアーカイブの現場では欠かせないツールです。 しかし、HxDはWindowsのみ対応 で、Macでは使用できません。ワークショップ後、Mac環境で同様の作業を行うための代替ツールを探した結果、Web版のHexエディタを見つけました。 そこで本記事では、Macユーザー向けに**Web版Hexエディタ「HexEd.it」**の使い方を詳しく紹介します。iPRESワークショップで学んだHxDの使い方を、HexEd.itでも実践できるようガイドします。 HxDとは？なぜMacで使えないのか HxD Hex Editorは、Windows向けの高機能なHexエディタです。無料で使えて動作が軽快なため、多くの開発者やセキュリティ研究者に使用されています。 HxDの主な特徴 高速な動作 大容量ファイル対応 RAM編集機能 ディスクエディタ機能 チェックサム計算 しかし、HxDはWindows専用アプリケーション として開発されており、macOSには対応していません。仮想環境やWineを使えば動作させることも可能ですが、手間がかかります。 HexEd.it - ブラウザで使える代替ツール Mac環境で使用できる代替ツールとしてHexEd.it （https://hexed.it/）があります。 HexEd.itの特徴 ✅ クロスプラットフォーム対応 Windows、Mac、Linux、どのOSでもブラウザがあれば使える インストール不要で即座に使える ✅ プライバシー重視 ファイルはブラウザ内で処理され、サーバーにアップロードされない オフラインでも動作可能 ✅ 豊富な機能 Hex/ASCII同時表示 バイト編集 検索・置換 ファイルの比較 データ型変換（int, float等） エクスポート機能 ✅ 無料で使える 基本機能は完全無料 HexEd.itの使い方 1. ファイルを開く ブラウザで https://hexed.it/ にアクセス 「Open file」ボタンをクリック 編集したいファイルを選択 または、ファイルを画面にドラッグ&ドロップすることもできます。 2. インターフェースの見方 HexEd.itの画面は主に3つのエリアに分かれています： ┌ │ ├ │ │ │ └ ─ ─ ─ ─ オ ─ 0 0 0 ─ ─ フ ─ 0 0 0 ─ ─ セ ─ 0 0 0 ─ ─ ッ ─ 0 0 0 ─ ─ ト ─ 0 0 0 ─ ─ ─ 0 0 0 ─ ─ ─ 0 1 2 ─ ─ │ ─ 0 0 0 ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ H ─ ─ ┬ e ┼ │ │ │ ┴ ─ x ─ ─ ─ 表 ─ 5 0 E ─ ─ 示 ─ 0 8 F ─ ─ エ ─ ─ ─ リ ─ 4 0 0 ─ ─ ア ─ B 0 1 ─ ─ ─ ─ ─ ─ 0 0 2 ─ ─ ─ 3 0 3 ─ ─ ─ ─ ─ ─ 0 0 4 ─ ─ ─ 4 0 5 ─ ─ ─ ─ ─ ─ 1 2 6 ─ ─ ─ 4 1 7 ─ ─ ─ ─ ─ │ ─ 0 0 8 ─ ─ ─ 0 0 9 ─ ─ ─ ─ ─ A ─ 0 A A ─ ─ S ─ 0 B B ─ ─ C ─ ─ ─ I ─ 0 C C ─ ─ I ─ 0 D D ─ ─ 表 ─ ─ ─ 示 ─ ─ ┬ ┼ │ │ │ ┴ ─ ─ ─ ─ ─ P ─ ─ │ ─ K . ─ ─ ─ . # ─ ─ ─ . . E ─ ─ ─ . ! g ─ ─ ─ . . . ─ ─ ─ . . . ─ ─ ─ . . . ─ ─ ─ . . . ─ ─ ─ . . . ─ ─ ─ . . . ─ ─ ─ . . . ─ ─ ─ │ │ │ ─ ┐ ┤ ┘ オフセット（左側） ...

デジタルアーカイブや長期保存を担当している方なら、「このファイル、本当に拡張子通りの形式なのか？」と疑問に思ったことがあるはずです。今回は、そんな疑問を解決してくれる強力なツール「DROID」について、実際の分析結果を交えながら紹介します。 DROIDとは？ DROID（Digital Record Object Identification）は、英国国立公文書館（The National Archives）が開発したファイル形式識別ツールです。ファイルの拡張子だけでなく、ファイルの内部構造（シグネチャ）を分析 して、真の形式を特定します。 DROIDの主な機能 バイナリシグネチャによる識別 ：ファイルの内容を直接分析 PRONOMレジストリとの連携 ：15,000以上のファイル形式データベースを活用 一括処理 ：フォルダ単位での大量ファイル分析 拡張子ミスマッチの検出 ：拡張子と実際の形式の不一致を発見 CSV出力 ：分析結果をデータとして活用可能 なぜDROIDが必要なのか？ デジタルファイルには、以下のような問題がよくあります： 意図的な拡張子変更 ：ファイル形式を隠すため 誤った拡張子の付与 ：人為的ミスやシステムエラー 形式変換時の拡張子未更新 ：変換後に拡張子が古いまま 拡張子のない/不明なファイル ：古いシステムからの移行時など これらの問題は、長期保存計画や移行戦略に深刻な影響 を与える可能性があります。 実例で見るDROIDの威力 実際にDROIDで分析したデジタル保存ワークショップのサンプルファイルから、興味深い問題が複数見つかりました。 🚨 発見された主な問題 1. 音声ファイルが画像ファイルを装っている フ 拡 実 P M 状 ァ 張 際 U I 態 イ 子 の I M : ル : 形 D E 名 式 : E : . : T X t f y T 4 i W m p E 1 f a t e N 2 （ v / : S 0 T e 1 I 1 I f 4 a O 6 F o 1 u N _ F r d _ _ 画 m i M s 像 o I k 形 A / S y 式 u x M m を d - A a 示 i w T r 唆 o a C y ） v H _ ( _ P = c C a M t t W r - A u p V e u E r F r O i R n M g A - T a ) n d - m e o w . t i f 問題点 ：画像として扱われる可能性があり、適切な音声再生ツールでアクセスできない恐れがあります。 ...

概要 今回開発したエディタは、IIIF対応の高解像度画像上で任意の座標を記録・管理するためのWebベースのツールです。URLパラメータで画像を指定でき、様々な研究プロジェクトで利用可能な汎用的な座標記録ツールとして設計されています。 https://youtu.be/UqPo5Xrkin8 主要技術スタック OpenSeadragon : IIIF画像ビューアライブラリ (v4.1) SVGオーバーレイ : マーカー表示用 localStorage : データの永続化 Vanilla JavaScript : フレームワークレス実装 技術的特徴 1. URLパラメータによる画像指定 ツールの最大の特徴は、URLパラメータで任意のIIIF画像を指定できることです: f } c u o n n c s t c c i } r t i o o f e o n n t i n s s ( D u m t t u t } } e r a g r r f n g e u u l y c a e t r r P a u ' U I l l a { r t c a l h r m P P r e c o l t t l a a a a t h n e t g r r m u s r i p = e a a ) r ( o t m s U m m n e l ( a : g r s { ) e ' g / e l = d . U e / t F = e { e R i I r u c r L U m m o n r o r パ R g a m e l d o ラ L . g Q w P e r メ t e u a U ( ー o U e U r R ' タ y r r R a I E の o l y L m C r デ b F ( S s o r コ u r ) e . m o ー n o a g p r ド k m { r e o に o Q c t n d 失 - u h ( e e 敗 l e P ' n c し a r a u t o ま b y r ' ( d し . ( a ) u i た j ) m ; r n 。 p ; s l g デ / ( P フ i w a U ォ i i r R ル i n a L ト f d m 画 / o ) p 像 p w ; a を r . r 使 e l a 用 m o m し o c e ま d a t す e t e 。 r i r ' n o : ) _ n ' ; c . , h s i e e n a ) e r ; s c e h / ) s ; u i k e i c h u z u / S u i k e i c h u u z u _ g r i d _ l . t i f ' ; 使用例: ...

はじめに Odeuropaは、ヨーロッパの香りの歴史を研究するプロジェクトで、絵画、文学、その他の歴史的資料に描かれた香りの表現を収集・分析しています。本記事では、OdeuropaのSPARQLエンドポイントを活用し、SKOS（Simple Knowledge Organization System）語彙体系に基づいた香りデータの可視化Webアプリケーションの実装について紹介します。 https://odeuropa-seven.vercel.app/ja/ プロジェクト概要 技術スタック フロントエンド : Next.js 15 (App Router) UI : Material-UI v5 国際化 : next-intl データ取得 : SPARQLクエリ (Odeuropa SPARQLエンドポイント) 言語 : TypeScript ホスティング : 静的サイト生成（SSG） 主な機能 1. 香り検索 (/odeuropa-sources) アプリケーションの中核となる機能で、Odeuropaプロジェクトが収集した香りの知覚イベント（smell perception events）を検索・閲覧できます。 主な特徴： 複雑なSPARQLクエリによるデータ取得 香り放出イベント（emission）、香りオブジェクト、ソース（絵画・文学作品など）、テキスト断片を結合 CRMベースのオントロジー（ecrm:P67_refers_to, od:F1_generatedなど）を活用 多軸フィルタリング SKOS語彙による香りの源でフィルタ（?xパラメータ） ソースタイプフィルタ（視覚的アイテム E36_Visual_Item / 言語オブジェクト E33_Linguistic_Object） リッチな情報表示 香りのラベル、ソース情報（タイトル、画像、URI） テキスト断片の引用 嗅覚体験の質的情報（Olfactory Experience） ページネーション - 20件ずつの効率的な表示 SPARQLクエリ例： S W } E H L E E R C E ? ? # { } } T e e { m m ソ U D i i ー N I s s ス ? ? ? I ? S s s と f f s O s T i i の r r o N o I o o 関 a a u u N n n 連 g g r { r C （ m m c c T o o フ e e e e d d ラ n n ? ? : : グ t t e e s e F F メ c c o m 3 1 ン e r r r u i _ _ ト c d m m r s h g 経 r f : : c s a e 由 m : P P e i d n ま : v 1 6 o _ e た P a 6 7 ? n s r は 6 l 5 _ s o a 直 7 u _ r o ? u t 接 _ e i e u s r e ） r n f r m c d e ? c e c e e f f o r e l ? e r r s _ l ? s r a p _ t x m s g o t i ? e _ m r o t s . l t e a l m l o n t ? e e t e e l . ? _ s m ? l e v i f _ m a ? s r l i l f s a a s u r i g b s e a o m e i g n e l o . m n n e . t ? n s . t ? o f u . r r a c g e m _ e i n m t a _ g v e a l u e 2. 香り詳細ページ (/odeuropa-sources/item) 個別の香りに関する詳細情報を表示するページです。 ...

はじめに 美術館や図書館のデジタルアーカイブでよく見られる課題として、「作品と作者の関係を適切に管理したい」というニーズがあります。特に、一人の作者が複数の作品を制作している場合や、複数の作者が共同で一つの作品を制作している場合、その関係性を明確に表現し、検索可能にすることが重要です。 この記事では、Omeka Sで作者データベースを独立して構築し、作品とリンクさせる方法について解説します。 課題の要点 独立した作者データベースの構築 : 作品データベースとは別に、作者（執筆者）のデータベースを作成し、両者をリンクさせることは可能か？ 複数作者への対応 : 一つの論文やデザインに複数の作者がいる場合、どのように表現すればよいか？ 解決方法 1. 作者を独立したアイテムとして登録する Omeka Sでは、作者を独立した「アイテム」として登録することで、作者データベースを構築できます。 手順： ステップ1: 作者用のアイテムセットを作成 「アイテムセット」から「新規アイテムセット」を作成 タイトルを「作者一覧」などとする このアイテムセットに全ての作者アイテムを収納 ステップ2: 作者アイテムを登録 「アイテム」→「新規アイテム」 クラスは foaf:Person を選択（推奨） 作者情報を入力： dcterms:title（作者名） foaf:firstName（名） foaf:familyName（姓） dcterms:description（経歴や専門分野） その他、所属機関など必要な情報 作成した「作者一覧」アイテムセットに追加 2. 作品から作者へリンクを設定する 作品アイテムの dcterms:creator（作成者）プロパティで、作者アイテムへの参照を設定します。 手順： ステップ1: 作品アイテムを編集 作品アイテムの編集画面を開く dcterms:creatorプロパティを見つける 「値を追加」→「Omekaリソース」を選択 ステップ2: 作者アイテムをリンク 「選択リソース無し」ボタンをクリック サイドバーが開き、アイテム検索が可能になる 作成済みの作者アイテムを検索 該当する作者を選択して「追加」 これにより、作品アイテムと作者アイテムが関連付けられます。 3. 複数作者への対応 Omeka Sでは、同一プロパティに複数の値を追加できます。 手順： 作品アイテムの dcterms:creator フィールドで、「値を追加」ボタンを再度クリック 2人目、3人目の作者アイテムを同様に選択して追加 必要な人数分だけ繰り返す 重要なポイント： Dublin Coreの dcterms:creator は、複数の値を持つことが想定されています 同じプロパティに複数の作者アイテムをリンクすることで、共著論文やコラボレーション作品を適切に表現できます 4. 作者の作品一覧を表示する 作者アイテムのページから、その作者が制作した全作品を一覧表示できます。 ...