Boost.GIL IO & Toolbox拡張が採択されました

Boost.GIL IO and Toolbox extensions have been ACCEPTED into Boost


bmp, pnmフォーマット、およびHSL, HSV, L*a*b, XYZ色空間のサポートを導入するBoost.GILの拡張に関するレビューが行われ、長い議論の末、採択が決まりました。


今回のレビューでは、これらの拡張に関するものだけではなく、Boost.GILで以前から問題視されていた部分の改良についても議論されていました。Boostに正式リリースされる前に、以下の点を修正すべき、という結果になりました:

  • ドキュメンテーションは適切だが、多くの誤字の修正とクリーンアップが必要。
  • 現在テストされていないエラーとしてlongjmpの結果として生じるケースのテストを追加するべきである。Boostで公式サポートされる全てのプラットフォームで。
  • テスト画像がライセンスフリーであることを確認すること。ライセンス状態がわからない場合は、ライセンスフリーの画像に差し替えること。
  • 新たなファイルフォーマット/バックエンドを追加するための要件を明示すること。これは、ファイルフォーマットreader/writerのためにコンセプトを定義するためのモデルを提供することを意味する。
  • 未知のフォーマット画像を読むためのコンパイル時サポート。これは、ファイルフォーマット/バックエンドを登録する機能を含み、与えられた拡張に関連付けを行い、適切なものを呼び出す。
  • 同じ画像フォーマットのための異なるバックエンドサポート。これが単にファイルフォーマットの拡張と同じ方法でもたらすことができるように思える。つまり、「png_libpng」や「png_lodepng」といったタグを持たせる。
  • 大きすぎてメモリに入らないような画像の一部分を読み書きする効果的なサポート。このための2つの方法がある:ひとつは、シーケンシャルアクセスを強化する入出力イテレータを持たせること。もうひとつは、パフォーマンスを犠牲にしてユーザーによるアクセスを可能にすること。


さらに、品質を高めるための改良案もいくつかでた:

  • デバイスモデルが、read_int8, read_int16, read_int32, write_int8のような名前の関数が符合あり整数を受ける/返すことができるようにすることを提案する。しかしそれらは符合なし整数を受ける/返す・・・名前が変更されるかもしれない。
  • 最も一般的なフォーマットにプロファイリングとパフォーマンス最適化を行い、テストケースを追加する。
  • テストケースが完全なカバレッジを提供することを確認すること。たとえば、あらゆるswitchと分岐にブレークポイントを設定する。遭遇したブレークポイントを取り除いていき、遭遇しなかったブレークポイントのためのテストケースを追加する。
  • ChristianとDomagojがBoost.GILのIO拡張をベストにもっていき、かつレビューで議論された高度な機能を合作し、彼らの努力を結集することができたらすばらしいだろう。