画像ファイル属性管理ソフト AtPictureのスレ

画像ファイル属性管理ソフト AtPictureのスレ at SOFTWARE

1:名無しさん＠お腹いっぱい。
06/11/13 10:09:08 XU11cIfV0
フォルダ振り分けとは異なるアプローチで画像ファイルを管理するソフト
AtPictureについてやり取りするスレです。

・配布サイト
URLﾘﾝｸ(artistic-imitation.hp.infoseek.co.jp)

・AtPictureの特徴
ファイルをMD5ハッシュで管理、画像に属性をつけて分類できる
それぞれの属性にキーを割り当てて、振り分け感覚で属性を付与／削除できる
様々な条件で画像ファイルを検索し、ファイルパスリストを書き出すことができる
画像をあちこちのフォルダに置いたまま管理することも、一箇所に集めて管理することもできる
個々のファイルにはコメントを付けることができる
IHDBのデータをコメントに取り込むことができる
属性データのインポート／エクスポートができ、他人とデータをやり取りできる
Susie Plug-inを利用できる
書庫内のファイルも扱える（要Susie Plug-In）

・関連スレ
画像管理ソフトを語ろう
ｽﾚﾘﾝｸ(software板)
画像振り分けソフトを語ろう！2枚目
ｽﾚﾘﾝｸ(software板)

・関連サイト
Image Database
URLﾘﾝｸ(kemuri-net.dip.jp)

2:名無しさん＠お腹いっぱい。
06/11/13 12:25:34 hCwJTuJ70
ちょっとまっ

3:名無しさん＠お腹いっぱい。
06/11/13 14:50:44 p/bDFVjA0
作者の自演うぜぇ
タグによるアプローチなんて何らあたらしくもねーよ

4:名無しさん＠お腹いっぱい。
06/11/13 19:38:45 rKRzeTY00
フリーでアンインストール時にファイル消すだけでよくて
これより使いやすいタグ系のソフトあるんか

5:名無しさん＠お腹いっぱい。
06/11/13 20:38:30 /0f6xCLR0
>>3
だれも新しいなんて言ってねえよ

>>4
タグ付けはかなり便利になってきたけど、検索と閲覧がまだまだじゃね？

6:名無しさん＠お腹いっぱい。
06/11/13 20:41:18 oEAHv8270
タグ管理は新しくもないけど、現状使い物になるソフトが皆無っていう状況だからな。
更新されていくフリーソフトだからこそ期待して楽しむっていうことができる。

7:名無しさん＠お腹いっぱい。
06/11/13 21:58:27 PX9CrMPw0
登録開始してから2日経つのにまだDB登録作業が終わらない件orz

ハッシュはファイルの先頭数Kbの分で取得する簡易モードとか欲しいなぁ
hamanaはそれで実用になってるみたいだからできたらよろしくす

8:名無しさん＠お腹いっぱい。
06/11/13 22:15:04 /0f6xCLR0
一意なキーとしてのハッシュなのにファイルの一部から取得しても意味ないんじゃね
パスだけ登録してハッシュ取得は後回しにするとか

9:名無しさん＠お腹いっぱい。
06/11/13 22:30:29 rQFGLl1i0
量が多いと動作が鈍くなるのさえなければな・・・
なんでもかんでも取り込んじゃいかんけどさ・・・

10:名無しさん＠お腹いっぱい。
06/11/13 22:33:52 PX9CrMPw0
>一意なキーとしてのハッシュなのにファイルの一部から取得しても意味ないんじゃね
なんで？
そのファイルの一部が他のファイルと内容かぶらなければいいんだから意味はあるでしょ？
かぶりやすくなるっていう危険性はあるけど、ある程度のリスクを覚悟してスピードをとるっていう選択肢があってもいいんじゃないかと思ったんだけど…

>パスだけ登録してハッシュ取得は後回しにするとか
それもいいね
任意のタイミングで開始・停止できるならそれでもいいなぁ

11:名無しさん＠お腹いっぱい。
06/11/13 22:40:19 AFYs/rsR0
タグの階層化は従来のエクスプローラ風な管理方法ではなく
iTunesのような管理方法にしてほしい。

12:名無しさん＠お腹いっぱい。
06/11/13 23:00:56 /0f6xCLR0
>>10
IHDBなんかをインポートしたり、エクスポートしたデータを他のソフトで利用するときに不都合

重複画像を削除したいってだけなら、ファイルサイズとかCRCで比較する専用ソフトのほうが高速
そのうえでパスだけ登録しときゃ問題ないだろ

13: ◆cTzcVzYvME
06/11/13 23:57:07 /RrrOAUF0
スレ立ったのですね。>>1乙。

それと、パスリストを書庫にみせかけて展開する Susie プラグインを作ってみました。
改変OKなんで欲しい人はどうぞ。

>>9
量が多くても動作が鈍くならないようにする為の
仕組みは考えてありますので、正式版ではそれなりに速くなるはずです。

>>11
iTunes は以前参考のためにインスコしたんだけど、
いろいろと鬱陶しい動作をしやがったので削除してしまいました。
もいっかいインスコして管理方法を検討してみます。
ただ、画像と音楽とでは、それぞれ適した管理方式も異なるのでは？と考えています。

14:名無しさん＠お腹いっぱい。
06/11/14 00:34:21 mNbbwykG0
>>12
ああ、考えたら重複を削除するんでなけりゃハッシュチェックは要らないか
管理するだけなんでパスだけ登録にしときますよ

15:11
06/11/14 03:07:00 pcggTZ5X0
>>13
うまい説明ができないのですが・・・

具体的には、例えばファイルAに
「タグ1：画像　タグ2：風景　タグ3：海　山」
というタグを与え、ファイルBに
「タグ1：写真　タグ2：風景　タグ3：山　空」
を与えたとします。これを従来のエクスプローラであるような階層化をすると

　　画像
　　　├風景
　　　│　├海
　　　│　├山

　　写真
　　　├風景
　　　│　├山
　　　│　├空

となり、「風景」のタグのついた画像をすべて見たいというときに、「画像」以下の「風景」か、
「写真」以下の「風景」しか選択できなくなります。
（Windows Vistaに標準でついてるWindowsフォトギャラリーは上記のような感じ）
検索で「風景」と打ち込めば階層構造を無視して「風景」タグの画像（海、山、空）が
すべて見れるんだろうけど、いちいち文字打つのはめんどくさい。

16:11
06/11/14 03:07:59 pcggTZ5X0
iTunes的な手法なら

タグ1 |　タグ2 |　タグ3
すべて |　すべて |　すべて
画像 |　風景 |　海
写真 |　　　　 |　山
　 | |　空　

となり、タグ1は「すべて」を選択してタグ2は「風景」を選択すれば
「画像」以下か、「写真」以下か、といった制限なく「風景」タグの
画像がすべて選ばれることになります。

階層的にファイルを整理しつつも、エクスプローラのような
階層構造の弊害がなくなるのでiTunes的な手法が優れていると思っているのですが、
違いと利点が伝わるでしょうか・・・。

Winの画像管理ソフトでこのような手法をとっているものは
ないんじゃないでしょうかね。
（せっかくタグを扱えるソフトでも
みんなエクスプローラ的な階層構造をとってしまう。）
macではStackroomという、まんまiTunesを画像管理に変えたようなものが
あるのですが、macを持っていないので使用感はわかりません。

17:名無しさん＠お腹いっぱい。
06/11/14 07:31:09 mkDiuHbY0
>>15
属性自体を階層化してるわけじゃないからそういうアプローチはできないんじゃないか
と思ったけど、カテゴリを疑似的な属性として扱うことはできるな
あるカテゴリ以下のいずれかの属性を含む画像を検索すればいい

カテゴリ右クリックで実行するなり、
属性リストに親カテゴリを（色違いの文字かなんかで）表示して、
そこから検索できるなりすれば便利かも

18:名無しさん＠お腹いっぱい。
06/11/14 09:01:33 7O3TZeEg0
タグははてブチックにおすすめ出してつけられるようにしてよ。
いちいちつけるのめんどくさい。

19:名無しさん＠お腹いっぱい。
06/11/14 09:11:17 GuyUWzIX0
>>16
iTunes的というよりxmlだね。
ぶっちゃけて言えばiTunesがxmlを利用しているだけの話だし。

20: ◆cTzcVzYvME
06/11/14 18:39:05 uePex0Bt0
>>15-16
求めている機能が理解できました。
動作仕様がイメージできたので、
似たような機能を正式版で実装することにします。

> macではStackroomという、まんまiTunesを画像管理に変えたようなものが
> あるのですが、macを持っていないので使用感はわかりません。
Stackroom はオレも気になってるんだけど mac じゃなぁ…

>>18
それなりに普及するようなら、選ばれた画像ハッシュに対し、
どのような属性が付加されているか、P2P で取得できるようにしようかなとは考えています。

その為に「Winnyの技術」なる本を購入し、効率的なクラスタ化と通信手法を研究してますが、
P2P 技術自体、オレにとっては未知の領域なもんで、思ってたより難しそうです。

どっちにしろ、まだまだ先の話ですな。
あ、ファイル交換機能とかは付けませんよ？

21:名無しさん＠お腹いっぱい。
06/11/14 22:23:22 /2zKPivn0
画像ファイルの編集するとハッシュが変わるから
別ファイル扱いになるけど
なんとかならんかな？

22:名無しさん＠お腹いっぱい。
06/11/14 22:41:22 oaHMgZI60
夢は広がるけど、
2005年2月に作者さんが初登場したらしいことを思うと、
俺の求めるAtComicが出来るまでにはあと2年はかかりそうな予感

23:名無しさん＠お腹いっぱい。
06/11/14 22:51:08 GuyUWzIX0
>>21
編集管理はスレ違いというかソフト違い。
このソフトは撮影したり､Webからぶっこ抜いたりした画像をそのまま管理するのが主旨だよ。
編集した画像の管理となると数は激減するが履歴の管理が必要だったりと全く別物になる。
君が求めてるのは全く別分野のソフトだから､ここで文句や要望を言うより､主旨にあったソフト探した方がいい。

24:名無しさん＠お腹いっぱい。
06/11/15 00:39:10 bpgJMLze0
元スレで編集ソフトに渡す話もあったから
そのうち出来るんじゃね？
今でもハッシュかパスを用途に合わせて選択すればいいしさ

25:名無しさん＠お腹いっぱい。
06/11/15 08:26:31 wLbO8PJ60
他人とデータのやり取りすることを考えると、
編集後にも同じファイル扱いというのはどうなんだろ？
タグなりコメントなりでやりゃいいような気がする。

26:名無しさん＠お腹いっぱい。
06/11/15 08:46:21 hinFjTlh0
ずっとフリーで出してくれるの？やっぱ将来的には金取る？

27:名無しさん＠お腹いっぱい。
06/11/15 10:13:47 Rpxr5zDb0
編集履歴の管理なんかしなくていいから、
類似画像検索的な事が出来れば十分かな。
完全に同一ファイルしかチェックできないならあんまり意味無い。

拾い物エロ画像管理の話でアレだけども。

28:名無しさん＠お腹いっぱい。
06/11/15 19:35:12 PWLWbT4g0
タグの貼り付けが簡単になれば

29: ◆cTzcVzYvME
06/11/15 21:07:36 kA+GQyVp0
Picasa2 データの読み込み機能を実装しました。

これでテスト版への機能追加は終了とします。

今後いただいた要望は、正式版の機能として検討していきます。
ただし、簡単な要望やバグ修正には応じますんで、気軽に言ってください。

>>26
AtPicture に関してはずっとフリーにします。
そのかわり、オレが重視していない機能は一切つけません。

具体的には、

・印刷系機能
・画像編集系機能
・類似画像検索

この辺の機能は、それを専用とする優れたソフトが既にありますので、
それらを使えばイイと思います。

30:名無しさん＠お腹いっぱい。
06/11/15 21:49:59 F3UDTf7d0
>>29
・印刷系機能
・画像編集系機能
・類似画像検索

確かにこれらは他専用ツールとの連携がいいかもね

ちなみに作者さんはそれぞれ何使ってるの？
あらかじめ明示しておけば納得しやすいし、ユーザー側の参考になると思う

自分は画像編集にVix
印刷・類似検索は不要だからわからんけど。

31:名無しさん＠お腹いっぱい。
06/11/15 22:01:25 6eJvlYW+0
タグ付けのし易さ、分類した画像の検索などを含めた閲覧性、それがあれば個人的には満足だけど、
分類管理をAtPictureで行い、「鑑賞する」ことにおいて他のソフトと連携できるようになればいいな。
簡単に言えば見たいタグの画像を外部ビューワに渡せるという感じかな。そのへんが使いやすければ柔軟に使っていけそう。

32: ◆cTzcVzYvME
06/11/15 22:57:22 kA+GQyVp0
>>30
画像編集は編集内容に応じてフリーソフトを使い分けるが、
ぶっちゃけフォトショがあればそれでオールオッケ。

印刷は画像編集ソフトについてるやつで十分。

類似検索は不要だから使ってない。むしろ類似画像どんとこい。
だってきちんと分類されてたら閲覧時に気付くし、
気付かない類似画像は、類似画像であって類似画像でない（哲学的）。

>>31
属性付けの操作性と検索性能に関してはとことんこだわるつもり。

外部ビューアに渡す機能はテスト版でもつけようかなと考えたけど、
機能は単純なくせにプログラミング工数が多くてめどい。
外部ビューアがパスリストに対応してないと更にめどい。

一応、書庫用の SPI に対応してるビューアであれば、axpathlist.spi をいれることで、
パスリストを読めるようになるんで、正式版までは、見たい属性をリストアップし、
パスリストを書き出してからご鑑賞ください。
※axpathlist.spi は書庫内のパスには対応してないけど、
　ソース同梱してあるので誰か機能拡張してくれたら嬉しい。

SPI 未対応なビューアをお使いの場合は、
ビューア作者にパスリストに対応するよう要望したってください。
正式版でも外部ビューアとの連携は、基本的にパスリストで行うつもりですんで…

33:名無しさん＠お腹いっぱい。
06/11/15 23:56:59 /bC18EVh0
>>32
ソートにバグがあると言った者だが、
フォルダ別ソートが有効なのを見落してただけだったのでスルーしてくれ

34:名無しさん＠お腹いっぱい。
06/11/16 00:52:35 1ZXgkew10
>>31
タグ付けしやすさといえばstackroomにはスタンプ機能つーのがあって簡単にタグ付けていけるので楽だったよ
タグ付けする属性の名前をスタンプボタンに登録しておくと、
リストからファイル選んでそれぞれの属性のスタンプボタン押すだけで
ファイルに属性が付加されるって機能

それと、AtPictureのテスト版ちょっと使ってみたけど、タグはみんな同列扱いなのかな
stackroomはiTunesみたいに「ジャンル」や「作者名」のように内容の決まったものをまとめて管理してくれるから
>>16のような管理方法がやりやすい
もちろんそういう取り決めの無いフリーのキーワードも入れられる
共有ソフト特有のファイル名規則に対応してて、初めてファイル取り込むときも作者名が自動で登録されたりもする
このへんはMangaExplorerに似てるかな

こういうのAtComic作るとき参考にしてくれると嬉しいなぁ

35:名無しさん＠お腹いっぱい。
06/11/16 00:55:27 67cOuSCZ0
>>31-30
ツール間でのファイルの受け渡しならAutoHotKeyやポチエスに任せたら？

36:名無しさん＠お腹いっぱい。
06/11/16 04:42:29 VAUmBbaq0
>>16
>Winの画像管理ソフトでこのような手法をとっているものは
>ないんじゃないでしょうかね。

フリーじゃないがDigital Imageは、これが出来る。画像管理ツールとしてVistaにも似た機能がつくようで、やや期待。

参考までに、DigitalImageではタグ（DigitalImageではラベルと呼称）をいくつかのグループに分けていて
ラベル検索画面では、同グループ内はor、他グループ間はandで抽出されるという方式。
>>15-16についてなら、ラベルグループ１に画像、写真のラベルがラベルグループ２に風景のラベルが入っていて
ラベルグループ１の画像と写真にチェック、ラベルグループ２の風景にチェックで抽出される
（実際にはラベルがこれだけなら、ラベルグループ１にはチェックいらないんだけど）。

究極的には、タグの条件検索を複数にして、その間のand,orを指定できるようになれば
タグが並列に扱われていても解決するのだが、どういう手法をとるかは難しいところだねぇ。

>>15-16について言えば、iTunesのスマートプレイリスト風に
(画像　もしくは　写真） and (風景)
みたいな抽出条件の指定が出来るという形。

37: ◆cTzcVzYvME
06/11/16 08:11:23 IetcMzSF0
>>33
了解。

>>34
> stackroomにはスタンプ機能つーのがあって簡単にタグ付けていけるので楽だったよ
同じようなことがキーマップでできます。

属性ショートカットキーマップダイアログを表示し、適用範囲を「選択画像」に指定、
変更ボタンから属性を割り当てたら、「未設定キーを隠す」にチェックをいれる。
「トグルモード」のチェックははずしといたほうがイイかな。

あとは、サムネイルを選択し、設定したい属性のボタンを押せばＯＫ。

割り当てるボタンが足りんなら、新規キーマップボタンでキーマップ自体を増やせばイイ。
キーマップは、タブを右クリックして名称変更できるから、
適切な名前をつけてやって関連属性ごとにまてめておけばよい。

> タグはみんな同列扱いなのかな
チュートリアルにも書いたけど、属性に階層構造は不要だと考えています。
何故不要だと考えるかは、実例を交えて説明できますが長くなるんで割愛。
「ジャンル」や「作者名」などはカテゴリ分けで対応します。

> 共有ソフト特有のファイル名規則に対応して作者名が自動で登録
これは AtPicture でも実装する予定です。

38: ◆cTzcVzYvME
06/11/16 08:12:36 IetcMzSF0
>>36
Digital Image は、ちょうど体験版をインスコしてみたところです。
ラベル操作まわりのインターフェイスを参考にさせてもらうつもり。

> 究極的には、タグの条件検索を複数にして、その間のand,orを指定できるようになれば
> タグが並列に扱われていても解決するのだが、どういう手法をとるかは難しいところだねぇ。
そっすね。機能の実現は簡単なんだけど、いかにスマートな UI にするかが課題です。
ちなみに、スマートプレイリストは既に実装予定に入っとります。

39:名無しさん＠お腹いっぱい。
06/11/16 08:33:55 zNULr5Ty0
気張り過ぎて失速しないように、
細く長くやったってやヽ( ´ー｀)ﾉ

40:名無しさん＠お腹いっぱい。
06/11/16 13:38:53 1ZXgkew10
>>37
>チュートリアルにも書いたけど、属性に階層構造は不要だと考えています。
階層構造でなく>>36のようなグループでタグをまとめることを言いたかったんです
グループ間に上下は無くていいとので私も階層構造はいらないと思います

41:名無しさん＠お腹いっぱい。
06/11/19 13:08:09 9NGqV+xOP
類似画像検索って、こんな機能かな？

URLﾘﾝｸ(images.google.com)

42:名無しさん＠お腹いっぱい。
06/11/19 18:33:26 bzktroT50
大体そんな感じ

43:名無しさん＠お腹いっぱい。
06/11/19 18:56:35 jqOjyHQS0
これってまだ正式版じゃないのにver1なの？

44:名無しさん＠お腹いっぱい。
06/11/19 19:38:20 W180TjyG0
テストプログラムはadbtestという名称だからかまわないと思うが
AtPictureというソフト自体はまだ公開されていないし、作成されているかも不明だよ
>>1の振り分けソフトスレ読めば経緯がわかるかと思う

45:名無しさん＠お腹いっぱい。
06/11/20 07:42:09 UKrVFoa10
バージョンナンバーなんか適当でいいんだよ

46: ◆cTzcVzYvME
06/11/20 08:24:26 9an0dscT0
ちょいとバグ修正しました。

>>43
それはテストプログラムのバージョンであって AtPicture とは無関係です。
adbtest はβ版とかじゃなくって、あくまでテストプログラムなもんで…
うーんプロトタイプって言ったほうが正確かな。

>>44
> 作成されているかも不明
まずは属性DBエンジンを、単体のライブラリとして切り出す必要があるので、
AtPicture 本体の開発には、まだ手を着けておりません。

本格的な運用に入ると、DB仕様やライブラリ仕様に
手を加えるのが難しくなりますので、長期的に見るなら、
DBエンジンのライブラリ化は慎重に行うべきだと考えています。

一応、再利用性は考慮してコードを書いてきたんだけど、
外に出したくない部分や、有料のライブラリを使ってる箇所もあるので、
ライブラリ仕様によっては、その辺を分離しなければなりません。
また、クロスプラットフォームを考慮するならOS依存も取り除かないと…

できるだけ汎用的な仕様にしたいけど、それにこだわりすぎると、
開発工数がかさんじゃうので、その辺のさじ加減が難しい。

まぁそんなこんなでライブラリの仕様決定に悩んどるとこですわ。

47:名無しさん＠お腹いっぱい。
06/11/20 11:01:34 s5YQPGUh0
picasaだけじゃなくて
digital image albumやvistaとも連携できるといいな

48:名無しさん＠お腹いっぱい。
06/11/21 13:49:18 kokFfN1G0
SQLiteでも使うのかと思ってたらDBも自作だったのかΣ(ﾟДﾟ　;)

とにかく応援してるんだぜ。タグが共有できる時代が待ち遠しい。

49:名無しさん＠お腹いっぱい。
06/11/21 15:16:45 5fLJ5Usv0
タグに関しては、del.icio.us の bundle みたいな機能もあるとうれしいかも。

50:名無しさん＠お腹いっぱい。
06/11/26 10:51:35 33Q7k0D80
DBさえ完成すればガンガンソフトも開発されるのかな！　かな？

51:名無しさん＠お腹いっぱい。
06/11/26 17:45:04 upPtW5OZ0
ver1.0.1.11 きてる

52:名無しさん＠お腹いっぱい。
06/11/26 17:54:35 votr8U2F0
2006/11/26version 1.0.1.11

・取り込んだ画像がリストアップされなくなってたエンバグを修正

53: ◆cTzcVzYvME
06/11/26 21:16:55 /SihlzBq0
>>50
そうするつもり。つーかはやく本開発に入りたい。
いろんなアイデアが先走り状態なもんで。
でもライブラリ化の手を抜くわけにはいかんというジレンマ。

54:名無しさん＠お腹いっぱい。
06/11/28 11:49:42 xV/AGBzI0
自動で取り込んでると、ある書庫で延々とループする…
書庫が悪いのかスージープラグインがわるいのかこのアプリが悪いのかわからんです

55: ◆cTzcVzYvME
06/11/28 14:15:44 nl927Nuj0
>>54
まずはその書庫を、Susie もしくは書庫用SPI に対応したソフトで開いてみてください。

１．展開に失敗した場合
　SPI に頼らないアーカイバソフトで展開できるか試してください。
　展開に失敗するなら書庫が壊れています。
　正常に展開できるならプラグインに問題があります。

２．正常に展開できた場合
　プラグインに問題はありません。
　adbtest に問題があるので以下の質問に答えてください。

・メニューの「ファイルを開く」でその書庫を開けるか？
・書庫の形式と、それの展開に使用している SPI はなにか？
・書庫内に書庫は存在するか？
・書庫内に thumbs.db ファイルが含まれているか？

あと差し支えなければ、書庫ファイルのフルパスも教えてください。

56:54
06/11/29 02:47:15 SIVUQ5qj0
rarの書庫だったんですが、どうやらプラグインが古くて新しいrarに対応してなかったみたいです
バージョンアップしたらループしなくなりました

#ループしてる書庫の「次の書庫」が問題だったようで気づくまで時間かかりました

お手間を取らせてすみません

57:名無しさん＠お腹いっぱい。
06/12/04 17:45:13 X8Oz5keY0
>>48 と関連するけど、DBはODBCかなにかで
外部ツールから操作できるようにして欲しいかな。
PerlやPHPと連携できるだけでも活用の幅が広がりそう。

58:名無しさん＠お腹いっぱい。
06/12/04 17:58:56 hvMP2i610
dll に切り出してくれるだけで十分

59: ◆cTzcVzYvME
06/12/05 18:08:36 NolOpgbn0
>>57
> 外部ツールから操作
まずは DB操作ルーチンを DLL化しようと思ってます。
んで DLL化が完了したら、本開発に入る前に DLL だけを先に公開する予定。
と言っても、まだまだ時間がかかりそうですが…

60:名無しさん＠お腹いっぱい。
06/12/05 18:51:58 2FYfhBRs0
まだ時間かかるのか・・・

61:名無しさん＠お腹いっぱい。
06/12/05 19:25:50 1uBtfihi0
画像以外のファイルも扱えるようにならんかな？

62: ◆cTzcVzYvME
06/12/05 20:06:03 NolOpgbn0
>>60
ちょいと別件が忙しくってね。
とりあえずライブラリ化の方針は固まったんで、これから巻き返してきますわ。

>>61
できますよ。
adbtest ではアプリ側で画像以外をフィルタリングしてるけど、
属性データベース自体はどんなファイルでも突っ込めるようになってます。

63:名無しさん＠お腹いっぱい。
06/12/05 21:35:49 HiPS9/kP0
そのうちファイラ作って

64:名無しさん＠お腹いっぱい。
06/12/06 12:04:57 e89rW0050
>>62
まだかな、まだかな～ﾁﾝﾁﾝ

65:名無しさん＠お腹いっぱい。
06/12/06 17:32:14 PQ8Xrbas0

（*´Д`）
/（ﾍ　つ）ﾍ

66:名無しさん＠お腹いっぱい。
06/12/06 22:33:12 pAb187sm0
1.0.1.10にしたあたりから重複画像リストアップで全画像がヒットするようになった
以前のバージョン + 今のDBでも同様、.11 + 新規DBでは正常なんで
どこかでDBが破損したと思うんだけど
修復する方法はない？

67: ◆cTzcVzYvME
06/12/07 02:45:56 MJL84WF10
>>66
重複画像以外のリストアップは正常ですか？

いまちょっと動作チェックしていたら、
リストアップ処理がおかしな動きをしたので原因を探っているとこです。
まだ調査中なので、同じ原因だと断定はできませんが…

とりあえず重複画像のリストアップに関してですが、
db\adb\duplications フォルダ内にファイルは存在しますか？

ちなみに、duplications フォルダにあるファイルのサイズを合計して4で割った数が
重複ファイルの個数になるんですけど、リストアップ数と一致してますか？

68: ◆cTzcVzYvME
06/12/07 06:18:43 MJL84WF10
調査完了。

うちの環境で見つかったリストアップの不具合は、DBの不整合によるものでした。
ただし、何が原因で不整合が生じたのかまでは付きとめられておりません。

とりあえず対症療法的な修正を行いましたが、
重複管理機構との関連は低いので、>>66さんの環境における不具合は、
これとは別の原因によるものだと思います。

>>66
修復できるかどうか判断するには、不具合の原因（※不具合発生の原因ではない）を
特定しなければならないので、情報提供にしばしご協力ください。

69:名無しさん＠お腹いっぱい。
06/12/07 17:01:15 XHV7Rv0n0
>>67
＞duplications フォルダ内にファイル
存在した
サイズ/4とリストアップ数も一致した
ちなみに画像の総数は5,500枚ほど、重複検索でヒットした画像は3,799枚だったので、
全画像がヒットしたわけではなかった

環境は XP sp2, v1.0.1.11, DBは.0.2あたりから引き継いでる

70:名無しさん＠お腹いっぱい。
06/12/07 17:12:27 XHV7Rv0n0
バックアップをさかのぼったところ、.1.9までのDBは問題なかった

71: ◆cTzcVzYvME
06/12/07 18:52:17 MJL84WF10
>>69
> サイズ/4とリストアップ数も一致した
となると、重複画像のリストアップ処理は正常だと思います。

> 重複検索でヒットした画像は3,799枚
これらは、重複画像でないのにリストアップされている状況でしょうか？

ちょっと次の操作を試してください。

１．重複検索でヒットするのが3,799枚とのことなので、
　INIファイル[Option]キーの maxPathCount値をそれ以上（4000くらい）に設定する。
２．メニューの「表示」から並び順を「サイズ」にし、「フォルダ別に並べる」の
　チェックをはずす（昇順、降順はどちらでもイイ）。
３．重複画像のリストアップを行う。

DBが正常であれば、重複画像同士は２枚以上連続して表示されるはずです。
１枚だけの画像があるようならDBに問題があります。

また、重複検索で見つかる画像は必ずハッシュチェック済みであるはずです。
リストアップされたサムネイルを眺め渡したとき、HアイコンもIアイコンも表示されていない
画像が混じっているようなら、やはりDBに問題があります。

とりあえず上記手順を行い、どういった状況になったか教えてください。

72:名無しさん＠お腹いっぱい。
06/12/07 20:17:29 XHV7Rv0n0
>>71
手順に従ってリストアップしたところ、
無効なパスを破棄するとかのダイアログが1,870で止まったままだったのでキャンセルして再起動
再度試すと同じダイアログが394でしばらく止まり、
その後リストアップされた画像が394枚まで減っていた

重複画像は一部連続していたが、
類似画像も同様に連続していたので単にファイルサイズによるものだろう
実際に重複していた画像は10枚程度だった

ハッシュは全ファイルチェック済み

それから、終了後duplicationsフォルダは空になっていた

73: ◆cTzcVzYvME
06/12/07 21:30:03 MJL84WF10
>>72
> 終了後duplicationsフォルダは空になっていた
だとすると、重複検索では１枚もヒットしなくなっているはずです。
今一度、リストアップしてみてください。

duplications フォルダが空であるのに画像がヒットするようなら、
重複画像のリストアップ処理にも問題がありそうです。

74:名無しさん＠お腹いっぱい。
06/12/07 22:14:07 XHV7Rv0n0
>>73
重複検索ではヒットしなくなった
意図的に重複する画像を登録したがこれは正常にヒットした

ところで、>>72の段階でダイアログに表示されたヒットの最大値は3,750ほどだった
これは多分>>72の直前に別ソフトで重複画像をいくつか削除したのが原因
その後数字が減り
＞無効なパスを破棄するとかのダイアログが1,870で止まったまま
になったんだが、それ以前は常に3,799ヒットしていたから、
ファイルを削除したことが問題の解消に影響したかもしれない

75: ◆cTzcVzYvME
06/12/07 23:04:08 MJL84WF10
>>74
とりあえずDB自体は修復できたっぽいのかな？

> 別ソフトで重複画像をいくつか削除した
adbtest 以外から重複画像を削除した場合、そのあと１回目の重複検索では、
以前に検出されていた重複画像がまだリストアップされてしまいます。

ただし、このときパスの有効性チェックが正しく働けば、
削除された重複画像のパスがDBからも削除され、それと共に重複情報の更新も行われます。
なので、別ソフトや手動で削除した場合、重複検索は２回やらないと正しい結果になりません。

状況から推測しますと、無効なパスの破棄処理が完全に行われず、
重複情報が正しく更新されなくなっていたのだと思います。

ただひとつ気になるのは、重複検索にヒットしていた3,799枚なりのファイルが、
なぜ重複ファイルとして登録されてしまっていたのか？ってことです。
実際に重複していたのは10枚くらいなんですよね？

本来だと、重複を検出したときのみ duplications フォルダにそのMD5をファイル名とし、
重複情報ファイルが作られるはずなので…

もしかすると重複検出ルーチン、つまりハッシュDBとの照合にバグがあるのかもしれません。
ライブラリ化に伴い重点的にチェックすることにします。

76:名無しさん＠お腹いっぱい。
06/12/07 23:47:55 XHV7Rv0n0
>>75
＞とりあえずDB自体は修復できたっぽいのかな？
今のところ問題なく動作している模様
ありがとう

＞なぜ重複ファイルとして登録されてしまっていたのか
確か.1.10にバージョンアップした頃、
何千枚かの画像を別のフォルダに移動して再登録したことがある
＞.1.9までのDBは問題なかった
とも符合するから、これが関係しているかも

その時の手順は、
1. 属性あり、ハッシュチェック済みの画像を移動
2. フォルダを開く　から移動先のフォルダを開き新しいパスを登録
3. 画像を全選択してハッシュチェック -> 以前付けた属性が復帰

77: ◆cTzcVzYvME
06/12/08 02:50:16 DUA5sLA60
>>76
> 今のところ問題なく動作している模様
了解。とりあえずは一安心。

あと、報告いただいた手順から原因が特定できた気がします。
おそらく、>>71の手順を行う以前は、[Option]キーの maxPathCount値は
重複検索でのヒット数、つまり3799以下だったんじゃないでしょうか？

とりあえず、重複登録がされたのは
> 何千枚かの画像を別のフォルダに移動して再登録したことがある
このときで間違いないと思います。

報告いただいた手順の場合、３のハッシュチェックの時点では
ファイルが移動されたことを認識していないので、
このときに重複登録がなされるのは正しい動作です。

で、このあと本来なら、重複検索時にパスの有効性チェックではじかれ、
重複登録が解除されるのですが、パスの有効性チェックは、
リストアップ数が maxPathCount に達した時点で処理を打ち切るため、
いつまでたっても重複情報が消えずに残っていたんだと思います。

一応、パスの有効性チェックを最後まで行うようにもできますが、
重複数が maxPathCount を超える事はめったにないと思いますので、
そんな場合のみ、一時的に maxPathCount を弄ってやればOKだと思います。

ちなみに、リストアップ数に上限を設けているのは adbtest 側の事情です。
正式版では上限をなくした上、表示を待たさないようにするつもりなので、
この問題は起きないはずです。

78:名無しさん＠お腹いっぱい。
06/12/10 00:38:49 joL9mdKD0
また重複絡みのことだけど

1. C:\test から属性の自動生成
2. rename C:\test C:\TEST
3. C:\TEST から属性の自動生成

こうすると、同じファイルを参照しているにもかかわらず、
サムネイルビューに C:\test\someimg.jpg と C:\TEST\someimg.jpg が両方表示される
重複検索にもヒットする
どちらか一方を削除すると画像本体は削除されずに重複したサムネイルだけ消える
両方を削除すると画像も削除される

パスの比較はケースを無視したほうがいいんでは

79:名無しさん＠お腹いっぱい。
06/12/10 00:59:45 fXDV84f50
単ファイルをDBに追加するのに何か良い方法ない？
追加したいファイルをフォルダ移動させて、そのフォルダを丸ごとスキャンしかないかな？

80: ◆cTzcVzYvME
06/12/10 05:11:10 t0Q3xVgy0
>>78
パスは小文字か大文字に統一して登録するはずだったのに、うっかり忘れてました。
ちょっと手抜きで比較関数を決め打ちしちゃってるので
すぐには対応できませんが、正式版ではなんとかします。

>>79
DBへの追加だけならメニューの「ファイルを開く」かD&Dでできますけど、
たぶん自動生成みたいに属性設定やハッシュチェックまでやってしまいたいんですよね？
ちょいと息抜きがてら、そんな機能を作ってみますわ。

81: ◆cTzcVzYvME
06/12/10 23:37:29 t0Q3xVgy0
単ファイルの追加をやり易くしました。

ついでに自動生成の設定項目を増やしました。
親フォルダも属性として付加できるようになったので、
自動生成を数回に分けたり、あとで追加したフォルダとかの
登録がやり易くなったと思います。

82:名無しさん＠お腹いっぱい。
06/12/12 05:15:43 R2XCB1hO0
自動生成時に1ファイルずつDBに書き込んでいる？
してるなら複数ファイル毎に書き込むようにすれば速くなると思う。

83: ◆cTzcVzYvME
06/12/12 07:34:09 plmLapAc0
>>82
登録処理は１ファイル単位で行っておりますが、
アルゴリズム面での最適化はかけてありますので、
複数まとめてやったとしても、それほど速くはならないと思います。

と言っても、チューニングの余地はまだあると思いますが…

ただ、個人的な意見を申しますと、登録処理のパフォーマンスは、
現状のままで十分だと感じているのですが、これでもまだ遅いですか？

84:名無しさん＠お腹いっぱい。
06/12/12 11:29:20 SfK7G0hH0
開発進んでますか～？

85: ◆cTzcVzYvME
06/12/12 18:50:28 plmLapAc0
>>84
それなりにぼちぼちと。

今はトランザクション機能の実装をやってて、これが一番の山です。
前にも一度作ってみたんだけど、遅くて使いもんにならんかったから、
設計からやり直してます。なもんで、なかなか大変。

とりあえず、まともなトランザクション機能さえ実現できれば、
残りのライブラリ化作業はすんなりいくと思います。

86:82
06/12/13 17:50:35 Rfvma9Mw0
今日再度自動生成を試したら、極端に時間がかかっているようではありませんでした。
裏のプロセスがHDDにアクセスしていたのかもしれません。

当たり前のことですが、頻繁に自動生成する状況だと属性DBがあるドライブと
画像があるドライブを分けたほうがいいのかもしれませんね。

87: ◆cTzcVzYvME
06/12/13 19:08:26 ArTfoKZ60
>>86
了解。

HDDアクセスに関しては、実装上、けっこう激しいかも。
RAMの使用量を抑えるため、必要に応じてアクセスしたい領域だけをファイルマップし、
あたかもメモリを弄るかのように、直にファイルを書き換えていますので…

88:名無しさん＠お腹いっぱい。
06/12/15 21:15:06 HBYiyc7K0
まだダウンロードもしていないのだが、公式サイトのタイトルが
「プログラム」じゃなく「プラグラム」になっていることは誰も突っ込まないのか?

89: ◆cTzcVzYvME
06/12/16 00:26:18 z9LpIc160
>>88
素でミスってた… readme.txt の中まで orz
突っ込みありがと。直しました。

90:名無しさん＠お腹いっぱい。
06/12/16 13:38:40 bUODxG5N0
>>89
何かかわいいぞw

91:名無しさん＠お腹いっぱい。
06/12/19 22:45:33 Jo91pLMY0
エラーが出ました
win2ksp4です

エラーの出た箇所

旧スタイルのシェルを使用する

92: ◆cTzcVzYvME
06/12/20 07:09:20 DYCR1PIK0
>>91
報告ありがと。

ちゃんと調べてないけど、たぶん adbtest 側で使ってる Win32 API の中に、
旧スタイルのシェルじゃ使えないものがあるからだと思います。

でも今んとこ、それへの対応優先度は低いです。
どうしても旧スタイルで使いたい！という要望が多いなら考えますが…

ちなみに、DB操作ルーチン自体は、旧スタイルのシェルでも動くはずです。

93:名無しさん＠お腹いっぱい。
06/12/20 07:13:55 souMAfLK0
　

94:名無しさん＠お腹いっぱい。
06/12/26 12:00:45 9RGc1eKP0
今日始めてこのスレ見つけたけど・・・

スレ立の>>1が作者の自演臭いのは仕様ですか？

95: ◆cTzcVzYvME
06/12/26 17:25:52 TOuvScEa0
中間報告。

とりあえず、トランザクション機能がかたちになりました。
いくつかテストプログラムを作って実験していますが、
今んとこパフォーマンスは上々です。

これからそれを属性DBへ組み込んでいくのですが、
いくつか新規で追加したい項目があるので年内リリースはきびしそうです。
ただし、そのぶん性能アップには全力を尽くしたいと考えています。

それと、暫定的な API 仕様を公開しました。
API 仕様と言っても、単なるヘッダファイル郡ですが、
概略をつかむには十分だと思います。

開発者向けですが、興味のある方は目を通してください。

API 仕様（関数名、変数名、各種定義名を含む）の調整は、
正式リリース前の今なら可能です。
また、ライブラリ化に関する意見・アドバイスも受け付けます。

それらをふまえ、API 仕様を改善していくつもりですが、

・スレ立の>>1が作者の自演臭い

を仕様に含める予定はございません。

96:名無しさん＠お腹いっぱい。
06/12/26 17:33:34 b8dEnskm0
おつ

スレがたつまでの経緯みてれば誰も自演なんて思わないから気にしないでくれ

97:名無しさん＠お腹いっぱい。
06/12/26 18:33:43 but/L7fP0
（*´Д`）　ﾏﾀﾞｰﾁﾝﾁﾝ
/（ﾍ　つ）ﾍ

98:名無しさん＠お腹いっぱい。
06/12/26 22:29:04 zfAcqnoU0
この際、自演でも非自演でもいいけど、
スレタイのソフト作ってからスレ立てろよな

テスト版なんてアプリともいえない物でスレ立ててるの、これくらいじゃねぇの？

テスト版のｻﾎﾟやってる間くらい
てめぇん所のHPに掲示板でも立てて、そっちでやれよ

>>96
>>95に対して即レスだな
まるで作者がレスアップするタイミングを知って居たみたいだ
お前だろ？このクソスレたてたの？ｗ

99:96
06/12/26 23:02:31 b8dEnskm0
俺がスレたてたわけじゃないけどこの莫迦には何言ってもわからんのだろうな…

100:名無しさん＠お腹いっぱい。
06/12/26 23:32:03 NNGn3a030
何がどうしようが使い易けりゃ使うだけだからね

まあ使いにくいテスト版でも喜んで人柱になるマゾだけど

101:名無しさん＠お腹いっぱい。
06/12/26 23:39:33 hUbhLx1i0
Winnyなんて（以下略）

102:名無しさん＠お腹いっぱい。
06/12/27 04:07:41 +7AgcraW0
冬休みなんで（ｒｙ

属性情報APIに、エイリアス(ファイル情報APIでいう同期)や親属性を追加してほしいかも。
P2P等で複数人で属性DBを共有する段階になると必須になるかと。

103: ◆cTzcVzYvME
06/12/27 08:19:45 dxxqHvKK0
>>102
> エイリアス
別名定義っすね？
異なる属性名称だけど実はおんなじ属性で、
検索にはどっちを指定しても引っかかってほしい！みたいな？

今の仕様だと統合でどちかの名称に統一することで対応してますが、
名前は別なまま同一視させることもできそうなので、仕様を検討してみます。

> 親属性
これは属性に階層構造を持たせるということですか？
もしそうであるなら階層構造がどうしても必要となる状況を挙げてもらえますか？

一応設計段階で、属性DBにおける階層構造の必要性についても考察を行いましたが、
一見階層構造が適しているかのように見える事例でも、
それらの間に絶対的な親子関係は存在し得ないという結論に達しました。

そもそも属性管理が求められる動機は、
フォルダ管理における２つ欠点から来ていると思います。

１．あるファイルの分類(格納フォルダ)が一つに限定される
　　＝複数ジャンルの設定ができない。
２．階層構造の逆転が難しい

属性に階層構造を持たせることは2番目の欠点を引きずる事に
つながると思うのですがどうでしょう？

104:名無しさん＠お腹いっぱい。
06/12/27 09:27:25 2jJtSEbo0
ベータで2chつかってんじゃねぇよｗｗｗｗｗｗｗｗｗ

105:名無しさん＠お腹いっぱい。
06/12/27 10:05:03 gg46enpT0
冬か。

106:名無しさん＠お腹いっぱい。
06/12/28 01:34:11 D6qCMA0f0
>>103
エイリアスを検討してもらえるとは有難い。

なんとなく親属性と書いてみて、確かに必要な状況というのを想像してなかったですね。
しいていえば「マインドマップ」のツリー構造かな、と思ったんですが、
外部ツールを作れば解決する問題かもしれないのでスルーでよろ＾＾；

107: ◆cTzcVzYvME
06/12/28 22:47:55 cZmy0tJx0
>>106
> 外部ツールを作れば解決する問題かもしれないので
階層構造の必要性を考察した結果、辿り着いた結論がまさにこれです。
カテゴリを扱う API を用意していないのも同じ理由です。

・エイリアスについて
エイリアス化の目的が「名前は別なまま同一視」であるとするなら、
どれか一つをエンティティと定めた上で、それへのエイリアスを作成するという構造より、
同一とみなされた属性郡をすべて同列に扱い、同期グループを形成したほうが、
データの取り回しが楽かな？との考えをもとに、API 仕様を作ってみました。

実装段階で設計の穴が見つかることもありますので、
これで確定という訳じゃないですが、仕様を概観した上で、
この構造における問題点などに気付きましたら指摘ください。

108:名無しさん＠お腹いっぱい。
06/12/29 01:19:51 bozK3W5B0
来年中に完成するのかい・・・？

109: ◆cTzcVzYvME
06/12/29 02:38:16 HCPinno80
>>108
DLL化は余裕。

AtPictureは…オレが欲しい機能全部つめこむとしたら微妙。
来年の予定が不透明なんで、どれだけ開発時間を確保できるかもわからんしね。

とりあえずDLL化が終わったら、もいっぺん工数見積もってみて、
あんま時間かかりそうなら、いくつかの機能を後回しにするかもしれんが、
とにかく adbtest よりは使い易いソフトを来年中に公開できるとは思う。

110:名無しさん＠お腹いっぱい。
06/12/29 10:49:43 38gv3Pm70
> AtPictureは…オレが欲しい機能全部つめこむとしたら微妙。

そんなに時間がかかるなら、
とりあえず未完成でもAtComicの原型めいたものをAtPicture完成前に作っておいて欲しいな・・・。
そうすればひとまずタグ付けの作業に入れるじゃん・・・。
完成してみたらタグの仕様変わってましたってなったら目も当てられないけど。

111: ◆cTzcVzYvME
06/12/29 11:58:10 HCPinno80
>>110
> 完成してみたらタグの仕様変わってましたってなったら目も当てられないけど。
それはない。ライブラリ化に時間かけてるのはそれを避けるためだから。
万一変えるとなってもパッチ作るから大丈夫。

> とりあえず未完成でもAtComicの原型めいたものをAtPicture完成前に作っておいて欲しいな・・・。
了解。
原型として必要十分かつ、短期で開発できるようなソフト仕様を考えときます。

あとは、何人かプログラマもいるみたいなんで、
DLL公開したら、オレよりいいソフト作ってくれんかな？と、ちょいと他力本願にも期待している。
最終的に、画像、漫画、音楽、動画に対し、それぞれ専用の属性管理ソフトが欲しいんだけど、
必ずしも全部を自分で作らないかんわけじゃないからね。

112:名無しさん＠お腹いっぱい。
07/01/01 14:23:58 EEvl1JBQ0
あけおめ
誰か作者さんに精神と時の部屋をプレゼントしてやってくれ

113: ◆cTzcVzYvME
07/01/09 06:08:54 FvbHg4F90
開発スケジュールを検討した結果、
現状のライブラリをβ版として公開することにしました。
詳しくは readme.txt をご覧ください。

114:名無しさん＠お腹いっぱい。
07/01/09 07:17:36 WbYs21S50
>>113
GJ！待ってたよ。

115:名無しさん＠お腹いっぱい。
07/01/09 08:41:59 a5Q0pgPb0
> AtComic Primitive の開発にとりかかる。

むぅ。俺のとかぶるけどまぁいいや。

116:名無しさん＠お腹いっぱい。
07/01/09 15:40:22 EdB2zOJa0
まあこれがいいもんになるなら、俺も開発凍結するかな・・・めんどいし

117:名無しさん＠お腹いっぱい。
07/01/09 17:08:21 y6uu2q3D0
>>115-116
ちょっとお前ら開発中の奴を見せてみろ、一番いいの使うからｗ
マンガミーヤと連携が取れる奴がいいなｗ

118:名無しさん＠お腹いっぱい。
07/01/09 17:21:56 EdB2zOJa0
ミーヤに興味はないな
ま、まだ構想レベルだし、こんなに本格的じゃないから
期待に応えられるもんじゃないよ、きっと

119:名無しさん＠お腹いっぱい。
07/01/09 17:27:07 y6uu2q3D0
まぁ予定を見る限り、
AtComic Primitiveは秋とか冬とかになりそうな予感だし、
作れる人はガンガン頼むよガンガン

120:名無しさん＠お腹いっぱい。
07/01/09 17:39:48 tKIuOhW30
>>117
連携とれるやつお前作れマジで。
さあ皆がんばれ。

121: ◆cTzcVzYvME
07/01/09 22:54:51 FvbHg4F90
>>115-116
ライブラリを使ってくれる開発者がいると、
こちらもモチベーションが高まるので、
遠慮なくガンガン開発したってください。

それと、β版のうちはサポートに関する雑務を避けたいと思い、
ライブラリを利用したソフトの配布を禁じていますが、
その辺は柔軟に対応していきたいと考えていますので、
もしソフトができて公開したい！となったら一度相談ください。

ちなみにライブラリのライセンスは、商用利用にのみ制限を課し、
その他、非営利目的の利用は自由に行えるかたちを予定しています。

122:名無しさん＠お腹いっぱい。
07/01/16 00:48:10 lMGJCe1+0
ライブラリとか地味に更新してても無反応
まぁ俺にも関係ないしな・・・

123:名無しさん＠お腹いっぱい。
07/01/16 01:35:13 xQJBt3F70
ライブラリ、サンプルも含めて使い方わかんなかったｗ

124:名無しさん＠お腹いっぱい。
07/01/16 12:05:41 3W+WM3g80
wikiなりまとめブログなり作る？

125:名無しさん＠お腹いっぱい。
07/01/16 13:33:47 Ta4tbeUg0
正式版でてからにしろよ

126: ◆cTzcVzYvME
07/01/16 17:32:29 i9SSspiA0
>>125
同意。

βのうちは、わかる人だけわかればイイ。

それなりに開発経験あればわかるはずだし、
その点じゃ、β利用者をふるいにかけれるから。

まぁオレにしかわからんようじゃ、それはそれで困りもんだけど…

ついでに現状報告。

とりあえず GUI の基本となるメインフレームを作ってま。
GUI 整備は面白みが少ないのに、やたらコーディング量が多くて苦痛。
おいしいとこは後にとっとく性分故、面倒な作業は先に済ましたいところ。

127:名無しさん＠お腹いっぱい。
07/01/16 18:28:06 lMGJCe1+0
おいしいとこだけ食べたいよ

128:名無しさん＠お腹いっぱい。
07/01/16 22:42:34 7Gkz3iXU0
おいしいとこだけ食べさせて欲しい、でしょ？

129:名無しさん＠お腹いっぱい。
07/01/18 23:21:49 vCD9l7Fe0
期待しているので保守

130:名無しさん＠お腹いっぱい。
07/01/28 09:21:44 X2454qKu0
最終安定版とか来てるじゃん！
最終とか言われるとそろそろ正式版も始まるかと期待

131:名無しさん＠お腹いっぱい。
07/01/28 11:33:23 sh6qHviv0
>>130
wktk

132:名無しさん＠お腹いっぱい。
07/01/31 16:59:45 2v+iz4Ic0
使ってみて、ちょっと要望があるんですが今はそういう時期ではないのかな？
画像への属性付け操作について、表示されている画像を左の属性の上にD&Dで行えればかなりサクサクできそうなんですが、難しいでしょうか。
お暇な時にでも検討していただければ幸いです。

133: ◆cTzcVzYvME
07/01/31 20:58:56 jjqHa5RJ0
>>132
> 使ってみて、ちょっと要望があるんですが今はそういう時期ではないのかな？
adbtest に関しては、これ以上、機能を追加する予定はないですが、
要望、提案は、正式版開発の参考にさせてもらいますので遠慮なくどうぞ。
また、すぐ対応できそうな内容なら、adbtest に実装する場合もあります。

> 画像への属性付け操作について、表示されている画像を左の属性の上にD&Dで行えれば
> かなりサクサクできそうなんですが、難しいでしょうか。
特に難しいことはないと思いますので、正式版での実装を検討しておきます。
ちなみに「表示されている画像」とはサムネイルのことですよね？

ついでに現状報告。

GUI に関してはだいぶ形になってきた感じ。
今はサムネイルビューの作り込みをやってて、
リストアップを効率化するための実験的なインターフェイスを試してる。
うまくいくかどうかはまだわからんが、これが一つの山だな。

次ページ