AdobeTV | Channels

Adobe MAX 2009, 2008 のビデオが見れるし、FITC のビデオもある。（※FITCは独自で映像流してたりもするけど。）

昨日はMAXのFlashBuilder関連のビデオ見てたら午前中が終わってしまった。
とにかくFlasherで英語リスニング勉強したいなという人にとっては一挙両得で勉強できる絶好のサイト。FITC Tokyo 2009に向けて英語耳を慣らしておこうって人にもいいかと思います。

これ通訳して日本語副音声作ってくれた人はきっと日本 Flash 業界のヒーローになれると思います。僕は全然聞き取れませんでした・・。

今アメリカでAdobeMAXやってるんですけど発表されたっぽい。やった！！！！！！！
clockmakerさんが詳細書いているのでここ読めばいいですね。
CNET でも紹介されてる。
アプリ転送には Mac 本体が必要とのことなので、これ Mac と FlashCS5 バカ売れするよね。僕は未来予測ができるわけもないので、あとで Mac 本体のアフィリエイト貼るぐらいしか思いつかないや。

「Goodbye, Papervision. | UnitZeroOne」

さっと読んだ感じだと、来日時も仰っていた Papervision3D を FlashPlayer10 の 3D エンジンに対応させた「PapervisionX」はまだリリースレベルの状態ではなく、ご自身の脱退ということもありリリースはあまり現実的ではないなぁとのこと。

これからはフリーランスとして Rhonda Forever project に参加したりしますとのこと。←トラックボールとペンで 3D を描くようにモデリングする直感的なツールっぽい。必見。

あとは個人的に Triangle3D っていう 3D エンジンを趣味レベルで作ったりしてるらしい。ブログで公開するぐらいのノリなライトなものなんですって。

という風に僕の脳内で翻訳したのですが、頼りないのでちゃんと原文読んでください＆教えてください。
まぁでも Tweener の例もあるけど、Flash で 3D といえば Papervision3D だし、現ユーザーの下支えもあるし、いきなり PV3D が下火になることはないでしょうね。

mixi Developer Center (ミクシィ デベロッパーセンター) » Flashを使ってみよう （ページ中段）招待機能とFlashに関して

結構はまりどころだと思いますので、Flash×mixiアプリを作られる方は留意されておくとよいかと思います。

Flash にも AIR にも、フルスクリーン機能がありますが、両方いっぺんにやったらどっちが最前面に来るのか？
実験方法としては、YouTube動画をフルスクリーンして、その上にパパパコメントのメッセージを流せるか？さてどうなるでしょう？
※もちろん前提として、パパパコメントのAIRクライアントは常に最前面に配置させるActionScriptを書いてあります。

やり方

1. パパパコメントをインストールして起動しておいて
2. YouTube動画をフルスクリーンにして
3. 他のPCからコメントして表示されたらAIRが上、表示されなければFlashが上。

やってみたら面白い結果が！！
Windows はブラウザに関わらずFlashが最前面にくる。Macはブラウザに関わらずAIRが最前面にくる。へー。

ということで「YouTubeをフルスクリーンでみんなで見ながら観客みんなでコメント投稿してワイワイ」みたいなことはMacだと簡単にできるということですね。
ブラウザ側はYouTubeでしか試してないので、よかったらみなさんもいろいろ試してみてください。

※パワポのフルスクリーンよりはちゃんとAIRが前面にくるのでご安心を。

Flash スライドショーなどで使う写真素材画像について調べました。
Photoshop→Flash連携での使用を想定して、画像の渡し方から、SWF パブリッシュ時の圧縮画質の見え方までを随時デスクトップキャプチャして画質比較してみました。
目視・主観でやっておりますので、そもそもの調査方法等、間違ってたら教えてください。

最終結論（5/22現在）

ファイルサイズを検討しつつ、「Web およびデバイス用に保存」で、「最適化」にチェックを入れて jpg 保存。

※このエントリは「Flash 写真スライドショーコンテンツ制作時の留意点」エントリの該当項目の調査検証となります。全容はそちらのエントリをご覧ください。

調査資料ダウンロードデータ

今回使ったデータ。今回の調査は下の各 PSD ファイルのレイヤーを比較することで確認いただけるようになっています。
PSD は PhotoshopCS3、FLA は FlashCS4 にて作成。ファイル容量が超重いのでそのつもりで！！

• 調査1の全画像をレイヤーで重ねた PSD データ
  →photoTest.psd(21,743KB)
• 調査2の全画像をレイヤーで重ねた PSD データ
  →photoTest_loader.psd(11,343KB)
• 調査3の全画像をレイヤーで重ねた PSD データ
  →photoTest_swf.psd(35,276KB)
• 調査3で使用した編集用 FLA データ
  →photoTest.fla(2,811KB)

Flash に渡す前時点での画質検証

まずは Flash に読み込ませる前の段階の画像についてバリエーションを用意してみました。元素材としてスライドショーコンテンツの背景に敷かれるような大き目の写真を用意しました。600万画素のデジカメで撮影した JPEG 画像を元ネタとして用意、これをそのまま Flash でロードさせるわけにもいかないので、Photoshop で開き、横1024px・縦768pxにリサイズします。
これを元画像として Photoshop を使って画像を用意します。

1. 「別名で保存」から jpg 保存。画質は「10（高：低圧縮率）」
   →photoTest_normal10.jpg(419KB)
2. 「別名で保存」から jpg 保存。画質は「7（中）」
   →photoTest_normal7.jpg(203KB)
3. 「別名で保存」から jpg 保存。画質は「1（低：高圧縮率）」
   →photoTest_normal1.jpg(74KB)
4. 「Web およびデバイス用に保存」から jpg 保存。画質は「85」
   →photoTest_web85.jpg(457KB)
5. 「Web およびデバイス用に保存」から jpg 保存。画質は「60」
   →photoTest_web60.jpg(231KB)
6. 「Web およびデバイス用に保存」から jpg 保存。画質は「10」
   →photoTest_web10.jpg(63KB)
7. 「別名で保存」から png 保存。
   →photoTest_normalpng.png(1602KB)
8. 「Web およびデバイス用に保存」から png 保存。PNG-8の256色
   →photoTest_png256.png(446KB)

ほとんど目視では画質の差がわからないものもあるかと思います。画像を拡大して比較しないとわからないものもあります。
詳細にその差異を調べる目的で、Photoshop 上で原画と各画像を「差の絶対値」で重ねたりしました。こうすれば原画と色が変わっていれば黒(#000000)以外になる。つまりグレーっぽいピクセルが多いほど原画とはかけ離れているということになります。
また、Photoshop 上でレイヤーで重ねた状態でヒストグラムを見ながら各写真の表示・非表示を切り替えることでも画質の変化量が分かります。

調査1での感想としては、
「別名で保存」のPNG保存した時（7）の画質は元画像そのままであり、その分ファイルサイズも大きい。
jpg画像（1,2,3,4,5,6）の場合、「別名で保存」でも「Web およびデバイス用に保存」でも圧縮後のファイルサイズを同じぐらいにすれば、画質もだいたい同じぐらいになる。2と5だと、空の階調が5の方がきれいだけど、ファイルサイズが厳密には5の方が30KBほど大きいのでそのせいかもしれない。1と4だとほどんど差は目視できない。なので保存の導線としては「別名で保存」でも「Web およびデバイス用に保存」でもどちらを選んでもよさそう。前者はADOBEマーカーやらサムネイルやらプレビューやらExif等のメタデータが入る（可能性がある）けれど、後者はそういうWEB表示に不要なデータが入らないからちょっと軽くなる。もちろん圧縮率は画質・ファイルサイズに影響する。今回の場合でいけば空のようなグラデーションさえなければ中程度（上記2や5）でも実用でいけそうに思える。実案件では写真の内容や質、コンテンツにおける写真を見せることへのウェイトなどに判断が委ねられる。
「Web およびデバイス用に保存」のPNG256色（8）はそもそも256色な時点で写真には向かない。ベタ塗りのグラフィックには最適なので色数を調整しつつGIFの代わりに使うと良い。

ここまでの結論として

1. swf に外部読み込みさせるための画像であれば、ファイルサイズがそのままローディング時間に影響するのでフルカラーのpngは不適。jpg形式でファイルサイズを検討しつつできるだけ高画質で保存する。画像の荒れ（ジャギ）は写真の内容にも依存するので、写真点数的に可能であれば目視で個別圧縮するといいかも。→調査2へ
2. Flash オーサリング環境（IDE）上のライブラリウィンドウに読み込む、つまりシンボルとしての利用、タイムライン上での写真画像利用をする場合は、Flash IDE 側で個別に画像圧縮をかけることができるので、それ以前の段階ではできるだけ原画のまま読み込むほうがよい。Photoshop で編集やリサイズした場合は「別名で保存」でPNG保存する。→調査3へ

調査2：外部読み込みからswf上での表示

次に、調査1での結果を踏まえ、Flash スライドショーで多用されるであろう「外部から画像を読み込んで swf 上で表示」させた最終成果時の各画像の表示を比べる。
使う画像は、実際の使用を想定してjpg画質10(上記調査1)、画質7(上記調査2)の2ファイルと、ファイル容量は大きいけど元画像に一番近いpng画像(上記調査7)の計3ファイルを使うとする。

その前に、
Flash のパブリッシュ設定の「JPEG画質」設定は、外部読み込み画像の画質にも影響するでしょうか？
答えは影響しないです。たとえFlash でJPEG画質を「0」に設定しても、外部読み込み画像は画像ファイルそのままの画質、無圧縮で表示されます。

では調査結果：

1. photoTest_normal10.jpg(419KB)を SWF から外部読み込みしたものをキャプチャ
2. photoTest_normal7.jpg(203KB)を SWF から外部読み込みしたものをキャプチャ
3. photoTest_normalpng.png(1602KB)を SWF から外部読み込みしたものをキャプチャ

感想としては、1ぐらいが容量・画質的に良い感じに思える。よって、大きめの写真を外部読み込みする場合は、ファイル容量を意識しつつ極力高画質なJPEG形式がいいと思いました。

調査3：Flash(swf) 上での圧縮調査

次に Flash(swf) 上での画像圧縮による画質の変化を調べてみる。調査1で、Flash シンボルとして画像を読み込ませる場合はpngがいいと判断したけれど、そのpngがswf上でどう圧縮されるかを見る。
ついでにjpg画像をシンボルにしたらどうなるかも一応調べてみた。

上の実験でできた photoTest_normalpng.png（原画クオリティと同等） と photoText_normaljpg7（jpeg画質7：軽量かつ実用できる元画像を想定）, photoText_normaljpg10（jpeg画質10：jpegでの最高画質の想定） の計3枚を Flash IDE のライブラリに読み込み、ビットマッププロパティの画質を以下のように比較検証してみた。

1. png画像を Flash ビットマッププロパティ「（写真画質）100」にてパブリッシュ
   →photoTest_png100.swf(686KB) をキャプチャ
2. png画像を Flash ビットマッププロパティ「80」にてパブリッシュ
   →photoTest_png80.swf(202KB) をキャプチャ
3. png画像を Flash ビットマッププロパティ「40」にてパブリッシュ
   →photoTest_png40.swf(66KB) をキャプチャ
4. jpg画質7を Flash ビットマッププロパティ「100」にてパブリッシュ
   →photoTest_jpg7_100.swf(424KB) をキャプチャ
5. jpg画質7を Flash ビットマッププロパティ「80」にてパブリッシュ
   →photoTest_jpg7_80.swf(166KB) をキャプチャ
6. jpg画質7を Flash ビットマッププロパティ「40」にてパブリッシュ
   →photoTest_jpg7_40.swf(68KB) をキャプチャ
7. jpg画質10を Flash ビットマッププロパティ「100」にてパブリッシュ
   →photoTest_jpg10_100.swf(590KB) をキャプチャ
8. jpg画質10を Flash ビットマッププロパティ「80」にてパブリッシュ
   →photoTest_jpg10_80.swf(210KB) をキャプチャ
9. jpg画質10を Flash ビットマッププロパティ「40」にてパブリッシュ
   →photoTest_jpg10_40.swf(67KB) をキャプチャ
10. png画像を Flash ビットマッププロパティ「劣化なし」にてパブリッシュ
    →photoTest_png_nocompress.swf(2111KB) をキャプチャ
11. jpg画質7を Flash ビットマッププロパティ「劣化なし」にてパブリッシュ
    →photoTest_jpg7_nocompress.swf(1807KB) をキャプチャ
12. png画像を Flash ビットマッププロパティ「100」「スムージング」にチェックにてパブリッシュ
    →photoTest_smoothing.swf(686KB) をキャプチャ
13. png画像を Flash ビットマッププロパティ「劣化なし」にて右下に0.5pxずつ移動させてパブリッシュ
    →photoTest_png100_05move.swf(686KB) をキャプチャ
14. ※調査4参考

まず11,12の「劣化なし(PNG/GIF)」での書き出しはそれぞれ写真画質(JPEG)書き出しした1,4とそれほどヒストグラム的にも変わらないわりには、ファイルサイズが3～4倍になってしまうので不適と判断。
次に、Flash のデフォルト書き出し圧縮設定は画質80ですね。これを100にすると多少キレイになるけれど、ファイルサイズの増加が結構大きいので、画質を見る感じでは80でもいいかなと思った。
スムージングの有無の比較（1と12）ではキャプチャした画像のヒストグラムが一致したので、写真を拡大縮小しないのであればスムージングの効果はなく、同一の画質になる。あくまで拡大縮小時のピクセルのスムージングに徹しているということが確認できた。

調査3での結論として
Flash IDE に PNGの状態で読み込んで ビットマッププロパティ：写真画質(JPEG)の80ぐらいでいいかなと。

調査4：外部読み込みと、シンボル埋め込みはどちらがキレイか？

これが気になるところ。調査3で作った PSD ファイルに、調査2-1の画像をインポートし、調査3-7と画質・ヒストグラム比較してみると

• 調査2-1のほうが、原画のヒストグラムに近い。つまり原画に忠実。
• ファイルサイズを比較すると、調査2-1は swf(21KB)+jpg(590KB)=611KB、一方調査3-7は swf(590KB)となった。

個人的には外部読み込みでいいんじゃないかと思う。

まとめ

Flash スライドショーコンテンツで大判の写真を使うのであれば、元写真を Photoshop でリサイズするのであれば、「別名で保存」でも「Web およびデバイス用に保存」のどちらでもいいから（※下記参照）、できるだけキレイな画質で JPEG 画像化して外部読み込みで表示させる。
という、なんだか当たり前のような結論に達しました。

追記：【別名で保存】【Web用に保存】

にじにじさんよりコメントいただきました。
「Photoshopの【別名で保存】【Web用に保存】の違いは、前者はADOBEマーカーやらサムネイルやらプレビューやらExif等のメタデータが入る（可能性がある）けれど、後者はそういうWEB表示に不要なデータが入らない、じゃ無いかな？
実データのバイナリが同じなら、WEB用に保存の方がデータ容量が小さくなるよ。」

ということで、そういえばjpg書き出しにおいて、それぞれの最高設定で書き出すのをやっていなかたｔのでやってみました。

1. 「別名で保存」から jpg 保存。画質は「12（高：低圧縮率）」
   →photoTest_normal12.jpg(812KB)
2. 「Web およびデバイス用に保存」から jpg 保存。画質は「100」
   →photoTest_web100.jpg(784KB)
3. 「Web およびデバイス用に保存」で、「最適化」にチェックを入れて jpg 保存。画質は「100」
   →photoTest_web100_saitekika.jpg(770KB)

上記3画像をレイヤーで比較できる PSD ファイル（photoTest_jpgHQ.psd(11,593KB)）重いので注意！

原画と上記の3画像を比較した結果、肉眼ではわからないものの、1,2,3とも原画とはちょっとだけヒストグラム上で変化が見られる。1と2はヒストグラム上で全く同一というわけではなかったけれど、これももはや肉眼で判断できる差ではないので、コメント頂いたように、Flash 用に同程度の画質で書き出す場合は無駄なデータが混ざっていない「Web用で書き出し」をしたほうが良い。さらに、2と3は「Web用で書き出し」設定画面上の「最適化」にチェックを入れたか入れてないかの違いだけど、ヒストグラムは完全一致した。つまり全く同じ画質。なので「最適化」チェックを入れておいたほうがファイルサイズが軽くなるので良い。

日本の Flash/ActionScript を世界にみんなで紹介するプロジェクト「JActionScripters.com」ブログが始まりました。
twitter 上での fladdict さんの呼びかけから3日で本オープン。海外への扉となりますね。

画像をキレイに表示するための Flash 独特のお作法などがいろいろとあったりするのですが、いつもちょっとやっては忘れてを繰り返して今に至るので、今回は手を動かしてじっくり比較検証していこうと考えています。

が、もし皆さんのノウハウをコメントとかでいただけたらすごく嬉しくありがたいので、書きかけですがフライング公開します。エントリ中で僕が勘違いしてるとこがあればご指摘いただけるととてもありがたいです。

よくある案件ということで「XML を swf からロードして、そこに書かれている画像 URL とキャプションをもとに、外部画像をロードして表示・切り替えていくスライドショーコンテンツ」という想定でおります。

画像形式

読み込む外部画像（写真）はjpg,pngのどちらがいいかという問題。別エントリにてまとめました。
→「Flashで使う写真素材の画像フォーマット」

ブラウザ全面に表示されるようにする

ブラウザウィンドウをリサイズした時に、写真の縦横比をキープしつつ全面表示させる手法。写真比率に対して、ブラウザウィンドウが縦長の場合と横長の場合を条件分けして表示させる「width/heightどっちか優先させる」コードを自分で書くか、あるいは sketchbook ライブラリの utils/FitUtil クラスを使う（ドキュメント化されてないのでライブラリパッケージを直接見ればいい）。あるいは下で紹介してる twist-cube さんの記事にもコード載ってました。※まだ調べてないけどAS3版 CASA に RatioUtil ってのもある。
以上すべてのアプローチとも実装方法は同じ縦横比算出してリサイズする手法で、コードも数行で実装できるので、自力で書くのがコンパクトでいいかもしれない。

とはいえ、限りなく小さくしていったときも追随させていたら、写真も小さくなるのはもちろん、メニュー項目を表示するスペースがなくなってギッチギチになる。そういう場合は swfforcesize.js という javascript ライブラリを使って、ブラウザウィンドウが一定サイズ以下になったらスクロールバーを表示させるようにする。※Progression にも swfforcesize が同梱されててありがたい。もう解消されてるそうですが、あれ？と思ったら Progression フォーラムをチェック。

画像をキレイに表示する

スライドショーでの詳細画像を拡大縮小回転など変形する場合にキレイに表示させるための方法。

AS3の場合：
スムージングをかけないと拡大縮小した時に汚くなる。対応としては
プロとして恥ずかしくないActionScript 3.0の大原則 CS3/CS4対応版 (インプレスムック エムディエヌ・ムック)

のtwist-cubeさまの記事（P107）に載っています。エッセンスだけ書くとロード完了時のイベントハンドラで：

var bmp:Bitmap = Bitmap(event.target.content);
bmp.smoothing = true;

さらにその記事には、外部からロードする対象がswfの場合、その外部swfの中の画像をきれいに見せるための方法も書かれています。

AS2の場合：
AS2は外部からロードした画像のスムージングがかからず汚いらしいので、以下のように対応する。
Saqoosha.net::BitmapData を超キレイに拡大縮小する方法（めちゃんこ重い）

画面解像度に合った写真画像をロードする

表示させる写真はできるだけ原寸で表示させたほうがきキレイですよね。とはいえ、画面解像度1600×1200のデスクトップPCを想定した大きいサイズの写真を、800×600のノートPCでわざわざ縮めて表示するのは、回線的にも無駄が多いです。なので、外部画像として、同じ写真を何パターンかサイズ違いで用意しておいて、ASで画面解像度を取得できる”System.capabilities.screenResolutionX”などを使って、それに応じて最適画像サイズをロードするようにするとかかな？

きれいにスクロールさせる

BitmapData 画像をスクロールさせるとなんかカクカクする。その対処法は：
Saqoosha.net::BitmapData を超スムースにスクロールさせる方法（めちゃんこ重い）
を参考にさせてもらう。引用させていただくと：

1. 読み込んだやつはそのまま使わずに、新たに作った BitmapData に draw する。
2. _quality は HIGH か BEST で。
3. MovieClip.attachBitmap するときの 3 番目のパラメータを never にする。（auto でも大丈夫かも）
4. MovieClip の _xscale, _yscale を 100 以外にする。

さくーしゃさんのエントリ中にもあるけれど、大きい写真をゆっくり拡大とか移動させるのは結構な負荷がかかります。ファンがよく回る。

画像を奇麗にフェードアウトさせる（混乱中につき注意！！！）

トランジション表現として、だんだん透明にしていくこともあると思います。単純なαフェードじゃなくって、なんか別の方法があるようなことをたしか昔てら子でmakocheさんに聞いたのにメモ紛失したので再検証すること。

1. alpha を0にトゥイーンして下地の白（or黒）にする
2. ColorMatrixFilter で白（or黒）にする
3. colorTransform で白（or黒）にする

のどれが最もキレイにフェードできるか？また、黒か白にフェードさせる時は、明度トゥイーンでも実現できるし、単色にフェードさせるなら着色トゥイーンでもできますよね。さてどの方法が一番キレイなのか調べる。

まず、白か黒にフェードする場合を考える。alpha 値を変化させるのは描画負荷が高いので、1よりは2が王道。ColorMatrixFilter を変化させるほうが良い。
例： Tweensyで色調補正（ColorMatrixFilter）パラメータテスト | (SCRATCHBRAIN.BLOG v2)
TweenMax の brightness も ColorMatrixFilter を変化させるタイプかな。2か3との比較で、3のアプローチの代表として、下のTweener での brightness を挙げて比較してみる。

Tweener の場合

1. alpha を0にトゥイーン
2. _brightness を 2.55 にトゥイーン（ドキュメントでは-1から1となってるけど2.55っぽいけどなぁ）
3. _colorプロパティを0xffffffにトゥイーン

という3アプローチで写真を一面白色にできる（黒にもできる）。1と3はどちらかというと単調にフェードする。2の方が雰囲気あるフェードをする印象。1が描画負荷高いはずだけど、背景が白一色の場合はどれもメモリ消費量に違いはなかった。3はグレー等の他の色にフェードできるのがメリットかな。

写真から写真へのαフェードは一番重いので、演出上どうしてもというのでなければできれば避けたい。

写真に集中できるようにする

UI 的なお話。前回紹介させていただいた「TWO STORIES FROM free stitch」さまのサイトでもしばらく画面操作しないでおくとメニューが隠れてマウスカーソルが非表示になるようにしてありますね。このロジックのコードも 上の twist-cube さんの記事で紹介されてました。
同様に、楽な方法としては、CASA Framework の AS3版、AS2版とも用意されている Inactivity クラスを使えば「○○秒間マウスが動かされなかったら△△する」という機能が簡単に実装できます。これも Saqoosha さんのAS2版の使い方エントリを参考にさせていただきましょう。AS3版も同じような感じで使います。
また UI の工夫例として「Lyndon Wade | Photographer」サイトでは、写真スライドショーコンテンツに必須の previous/next ボタンを、上手く非表示にしつつ、その隠し方自体がサイトの特徴的な UI としての印象付けになっています。
「TROYT COBURN」サイトのように、通常時は写真以外の全てを隠しておき、クリックするとカーソル部分にメニューが展開されるという見せ方もあります。

ローディングを配慮する

FILIPPA SMEDHAGEN SUND – MAKEUP ARTIST

独特の操作を必要とする UI の場合、画像のロード時間を活かして操作方法を説明しておくなどすると一石二鳥。

BGM を流す

世界観ができるので没頭系のスライドショーコンテンツ向き。「ANTEPRIMA」とか「TWO STORIES FROM free stitch」、「playMUJI」などなど、BGM を鳴らしていたほうがサイトにのめり込めます。

キャプション・テキストの処理

写真説明やコメントを添えるケースもあると思いますが、その文字がちょっとこだわりのある表示のさせかたをするとユーザが「おっ」ってなります。その結果、写真の待ち時間にイライラしがちなユーザを繋ぎとめてくれる効能があるのではないでしょうか。
テキストにかけるエフェクトを FlashIDE 上で直接編集するのが簡単ですが、XML 内に記述されたテキストデータをダイナミックテキストとして表示させることも多いかと思います。デバイスフォントの場合はフォントの透明度（alpha）をフェードさせることは通常できないので、colorTransform フィルタをかける Tips を使ったりします。

2段階ズーム

サムネイルから大きいサイズの詳細画像を表示させるのは通例ですが、近年のデジカメの高解像度化もあってか、そこからさらに大きいサイズの画像を表示して、写真のディティールを見せる演出も散見されるようになりました。
MoMA.org | Interactives | Exhibitions | 2007 | Jeff Wall
その場合はブラウザウィンドウのサイズよりもさらに大きいサイズの写真を表示させることになるので、UI にもひと工夫が必要です。マウスカーソルを上下左右に動かすことで写真が上下左右にスクロールする UI をよく見かけますね。

「minus – womens clothing」

このサイトはサムネイル・中サイズ・大サイズを一画面で表示、大サイズ写真をクリックすると、さらに最大写真をフルスクリーンで見られるようになっています。都合４段階。さすがにユーザ操作させすぎな気もしますが、なんとなく操作できる直感的な UI にはなっていると思います。
こういった「極大ズーム」表現は生地のテクスチャなどの商品ディティールを見せたいアパレル系サイトで見かける表現ですね。

トランジションの表現

写真と写真の画面遷移（トランジション）にこだわる。

La vera sartoria giapponese ｜ BEYES / バイズ

サムネイル画像

一般的な事例として、xmlの中にサムネイル画像の URL も記述されていて、swf の最初で一気にサムネイル画像をロードするというケースが多いと思います。サムネイル画像を全部読み込むまでローディング表示、完了したらスライドショー開始！のようなつくりにしたいのであれば、むらけんさんの GroupLoader を使うとらくちん。
あるいは xml ロード＆パース→全サムネイルロード→スライド開始→任意画像表示の一連の流れを Thread ライブラリにまかせるのもらくちん。

サムネイルでの演出

The Whale Hunt / A storytelling experiment / by Jonathan Harris

サムネイルの見せ方にこだわる。このサイトの場合、サムネイルクリック→一旦サムネイルを実寸拡大（モザイク表示になる）→本番写真と入れ替えという手法をとっています。そうすることでローディングの待ち時間をモザイクがスッキリ見えるワクワク感に変えるってことですね。
サムネイルの並びをキーとなる情報に応じてソートさせる手法も多く見られますね。
「Down the Foxhole – 51 Amazing Flash Galleries」にて、Flash スライドショーコンテンツの見せ方の実例をいくつか紹介されてます。写真を楽しんでもらうのが念頭であれば、素朴な UI（例：左っぽい場所に previous、右が next ボタンがあるんかな？っていう程度のリテラシで閲覧できる UI）が好きで、そこにプラスして驚けたり関心できたりする要素が盛り込まれてると印象に残るけど、そういうプラスアルファ要素は１つぐらいで十分だと思う。盛り込みすぎは禁物。

各写真にパーマリンクを持たせる

SWFAdress などを使って、各写真ごとにパーマリンクを設定しておけば、ユーザ同士で「このページ見てみて。URLは・・・・だよ」って感じで直接画像ページを教えあえるので素敵です。
Progression を使えばより簡単にパーマリンク付きサイトを作れますね。

まとめ

まずは経験として、上記を参考にしながら自力でスライドショーコンテンツをコーディングするといいかなと思います。
それを経て、ActionScript スライドショーの概念みたいなもんがなんとなく掴めた後に Thread を使うとそのコードの書きやすさと開発スピードに驚ける。あるいはツールチップやパーマリンクなどの便利機能一式の実装もしたければ Progression ベースで作るといいかな。

仕事で重宝するスライドショースキルをまとめておこうと思い立ってエントリを書いてみましたが、あらかた
プロとして恥ずかしくないActionScript 3.0の大原則 CS3/CS4対応版 (インプレスムック エムディエヌ・ムック)

で素敵にまとめてくださっていますが、UI 面などの配慮含め、今後も何か気付くこともあるかもしれませんのでエントリとしておきます。

できるん知ってました？（画像はCS4）