要望：最適化保存で破棄されるデータ(無駄なデータ)をlipファイルに保持しないで欲しい

この動作は私の想像

過去(コミスタ)で保存ファイルを読み込むとき遅いと言われ
クリスぺでメモリ展開をそのままファイルに保存して即座に編集に移れるようにした
今度はファイルサイズが巨大

 

そもそも原稿が完成したかは入稿して印刷が始まって完成とすると
保存動作は保存と別名保存でユーザが意識して保存しかないと思うけど(しかも同じlipで破棄とキャッシュだとどこで判断するの、一旦開いて破棄保存するの？、だったら編集中はフォルダに各レイヤがあるなど見分けられた方がいいのでは＜－－これは私の提案になっていく、ウザいとか書かれそうなので以降私はこの提案なるべく上げないようにします)

 

それとファイルを読み込みしたときファイル破損(たった1バイト)して読み込めなくてサポートに修復も無駄と思う、保存時にファイル内を64や128分割してあればその部分が髪の毛がなら一本引き直すだけで修復(10分では)

今は髪の毛レイヤが破損しましたが修復確認してくださいとサポート返答(3日かかる)

 

それと他の未実装機能を優先してもらいから
未実装機能を優先し完了してから改善がいいとも思うけど

クリスタＥＸは漫画作品として複数ページを管理・扱えるわけですが、コミスタと違い複数ページの作業は、基本的にメモリに広げたままになります。

今のままの仕様だとｌｉｐファイルは、変更を加えただけファイルサイズが大きくなっていくわけですから、漫画の作業として完成に近づけば近づくほど、キャッシュが効果的といえどファイルの読み込みと保存は遅くなるだろうし、使用メモリも大きくなっていくのではないかと、自分は考えています。これは誤った認識なのでしょうか？。

最近のＨＤＤの容量からすれば、ｌｉｐファイルのサイズが大きくても、保存スペースに困るといったことはないと思います。

しかし、ＲＡＭは違います。64bitOS 4GB以上のＲＡＭが扱えるといっても、実質物理的上限があります。32bitOSならもっと深刻です。

もちろん、搭載メモリサイズに合わせて、開くページの数を考えて作業をすればいいのですが、しかしながら、これがクリスタＥＸが目指す理想の作業なのかと思うと、疑問に感じます。

公式が説明したlip最適化は

新規空ファイル(この時点でキャッシュ作成)を作り

何か書かれているレイヤだった場合コピーを繰り返すだから空レイヤがなければサイズ縮小はされない＜－－編集中の保存しかできない仕様

 

M/B問題最大物理メモリ容量 (RAM)

pcの搭載メモリ問題はWin7初期機種では2GBまで、Win7後期は8GB、12年販売は16GB(ノートPCで改善は本体買い替え)

 

OS問題最大物理メモリ容量 (RAM)

Win7(64bit)のHome Premium16 GB、Professional(Ultimate)192 GB

Win7(32bit)のHome Premium4 GB、Professional(Ultimate)4 GB

 

実行中の使用MEMサイズは

環境設定-パフォーマンスで開くlipの適値(MB)を見つければいいのでは

4GB割り当てはB5-300dpi(2値)とか10GB,A4-150dip(カラー)＜－－この数値は検証なし

 

クリスタを通常動作させるなら8-16GB搭載が必要だし、今は五千-1万円でメモリは買えるから上記M/B問題なければ価格面では手頃と思っているけど

それなりに使えるは1600＊900、8GB、1TBか内臓500GBなら外付け1TB、CPU2GHz

クリスタの画面は16:9で設計だろうし

 

Win7中期までユーザは本体買い替えとなるからなーーー

 

-----------------------

訂正

ウザいとか書かれそうなので以降私はこの提案なるべく上げないようにします)ーー＞

ウザいとか書かれそうなので以降ここで私はこの提案参照をなるべく上げないようにします)

まず読み込みしてキャッシュ再構築、フリーズするよりまずは安定度、読み込みが別のSoft読み込みと比べ1/3で済むと喜んでいたのに

(インストール問題[ユーザ名2バイト－＞半角ユーザ作れ、MS IME]，ファイル名横の＊だって、保存が早くて保存したかわからないのでプログレスがほしいやPSD保存では＊が残る－－＞代替方法や＊が消えないは知っていれば問題視せずに定期更新まで放置－－＞だからRCのうちに不具合見つけて早めに報告しないと次の季節に先送りされるよ)

 

そしてこの保存は何も考えていない(安定度重視、だいたい読み込みができないとなったら2weekで再リリース必要になる)からキャッシュをそのままファイルに保存しているのでは

 

それと書き込みは前回との差分を書き込むとも言っているから編集を多く実行しているとファイルサイズが肥大、キャンパスサイズを2px増やす、2px減らすで改善するのはこれらの1編集の集合体言わばログがラスタに反映され破棄するからでは(書き込み量が少ないと軽減量が少ないかも)

保存でキャッシュを含まないというのは

保存する機能が全実装されてデータ形式が確定以降にフォーマットを策定し実装

それとサムネイルが実装されないのも保存形式が決まっていないから(今のサムネイル表示実装しても上記変更が予定されているから二重手間)

130で春の機能実装

140で夏の機能実装

150で冬の機能実装ここで予定機能が完了

160来年春で保存縮小

163来年夏で160以下の読み込み切り捨て(一旦160で変換)サムネイル表示

保存と言えば

保存を整備されたら、アシに渡して作業となるがデジアシは隣にいる必要がないので日本ブラジルでも可能

今1GBのlipがあって縮小されても301MBになった場合どのようにしてデータ送信するの

それか保存中にフリーズしたときデータが1バイト破損だけどクリスぺが破損検知で拒否ーー＞サポートに送って3日待つ、、、それなら内部分割保存していれば無事な分割を読み込みそのブロック書き直し

編集中か完成の判定十日間編集しなかったの検出どう実現するの

＞10日間分だけ残しておくとか、直近10ファイル分 だって＜－－コミック出すとなったら一か月間で10話分加筆すると不十分では

＜＝＝これらは私の別の提案だと思うけど

キャッシュの再構築は64bitPCなら10secでも32bitXPMem1GBだと9minかもしれない

メール発信(受信)1通あたり

最大受信容量20MB、ブロードバンド100MB、ダイヤルアップ1MB

だから

保存完成、保存完成分割、保存編集だと思うけど

車に例えると今リリ－スされているのはエンジンと車輪がついているだけちょっとしたことでトラブルが出る

要望は外装、メータつけてスピード超過、雨など普通に走りたい

私はエアーバック、前方レーダなど過去に起きた事故で予見できるなら予防機能も実装してくれ、だから”外装、メータ”と言うのは内包

※なるほど保存完成は再編集を禁止形式と思われていたのか

保存完成
　　読み込み
　　キャッシュが破棄されているだけで読み込みをしたら内部ではキャッシュ再構築(説明のため1分)して保存編集相当になる
　　編集は保存編集と比べ1分遅いだけで再編集できる

　　保存
　　レイヤーを収集して書き込む、以下レイヤー数分する(保存編集と比べるとキャッシュ破棄を行っている)
　　※2px増やす、2px減らすに相当

保存分割は上記を500kB-1024MB単位に分割しているだけで読み込みをしたら内部では．．．

保存編集はファイル名をフォルダとして、その中にlipで一つ構成編集しやすいのをファイルに分ける、もしもの時その一つを読めば1レイヤーを抜ける(破損救出)
レイヤー1.slip
レイヤー2.slip．．．
キャッシュ.tmp

備考
画像softで保存するのに必要なのは一枚ずつのレイヤーだから保存完成を作るときは
レイヤー1(連続データ)
レイヤー2(連続データ)
レイヤー3．．．だけでいいがここでレイヤー1の1バイト目が破損していた場合、今はすべて読み込みを放棄しているかもしれない

レイヤー1を128分割(or グリッド5*5マスなどある程度の大きさ)してあれば
レイヤー2-128分割
レイヤー3-128分割．．．これだとレイヤー1の左上120*80(グリッド5*5マス)ブロックを消失だけで済む

そもそもデータが破損することを前提として保存形式を考える事自体おかしいのではないでしょうか・・・？

保存・読み込みするたびにデータが破損したり、キャッシュが正しく再構築されないようではそもそも

データ作成・編集ソフトとしての体を成していないのではないかと思うのですが・・・

もし本当に、安定性の為にファイルの肥大化を招いていて、今後安定した段階でそれに着手するつもり、

前のレスの「キャッシュを保存を有期制にする」という提案について、10日や10ファイルというのは

とりあえず私の好みで暫定的に決めただけのことで

もっと伸ばしてもいいし、環境設定で自分で決められるようにすればいいだけのことだと思います。

半年前の肥大化したメタボなデータを長期間保存してHDDを圧迫するよりは、

コンパクトに保存して、必要な時が来たらにキャッシュを再構築する方がよっぽどスマートで正しいありかたではないかと・・・

原稿.lip(例として2レイヤーのみとする)

保存完成(1ファイル)
レイヤー1
bk1、ｂｋ2、．．．．bk127
レイヤー2
bk1、ｂｋ2、．．．．bk127
eof

保存分割相手または自分のメール受信最大値＝20MB、bk1(グリッド5*5など)＝1MB
原稿0001.lipcut(レイヤー1bk1、ｂｋ2、。。。ｂｋ19)
原稿0002.lipcut(レイヤー1bk20、ｂｋ21、。。。ｂｋ38)
原稿0003.lipcut．．．

保存編集
原稿.csp＜フォルダ＞
レイヤー1 bk1、ｂｋ2、．．．．bk127＜－－1ファイル
レイヤー2 bk1、ｂｋ2、．．．．bk127＜－－1ファイル
キャッシュ.tmp＜－－1ファイル


破損を前提について
破損を前提ではなく正常に書き込んでいるにもかかわらずエラーが出るから(ここの掲示板で何人か依頼しています)

データ展開するときチェックサムを計算(保存時にチェックサム書き込み)破損を検知して読み込まなければプログラムがフリーズしないなどあるし残りの部分があれば1コマだけ書き直しで済む
プログラムの作りによる、テンポラリに不具合(チェックサム)あった場合本来はレイヤーデータからキャッシュを再構成動作をするプログラムする
最悪ユーザが復元させるには1ファイルではなくレイヤー毎に保存が望ましい(保存編集はレイヤー数ファイルを作る)

＞キャッシュを保存を有期制
そもそも開かないファイルの検出が曖昧、これを実現するのは裏タスクでHD内を自動詮索してかつ見つけたらキャッシュ破棄しなければいけない、またはいきなりリストアップして肥大可能性があるからキャッシュ破棄をy/n問い合わせ

ユーザが不要と思ったときキャッシュ破棄しないと、いきなりHDが激しくアクセスしたとかリストアップ、ウザいと言われると思う

※チェックサムとはここでは誤り検出

キャッシュの有用性
いま思いついた別件で無限Undo要望のためにすべての記録が残っていないと実現できない