小米記趣～爸爸的小孩（老米＆小米）！

不是說小孩不能偷生
這句話真的很沒的錯
除了外型以外
殊不知連睡覺的模樣
也都如出一徹的呢....XD

父女倆睡姿


再靠近一點比對

小米記趣～狀似可愛小沙彌！

前幾天爹娘在沒有詢問我的意見下
把我抓去剪頭毛
而且還把跟我在娘胎裡相處個把個月的胎毛給剃個精光
厚～過分。。。。。。

還不知已經上了刑台


什麼？要剃頭毛，還要剃個精光。厚～過分


剃頭毛過程


楚楚可憐的勒～右眼下面還有一滴淚


其實夏天到了，換個清涼造型也不賴啦

Cool GFX: FITC Amsterdam Trailer

The opening trailer for FITC Amsterdam. Bikes, cows, and whores …

By Addikt Design Movement

陳小米露點照～唉呦！真羞～

這是洗澡的時候
應該在旁協助的助理（小米的爹）
居然忍不住的不務正業拿起相機狂拍
本來重點部位理當應該打馬賽克
但是為了不落俗套
所以就原汁原味的呈現啦
不過我猜想陳小米如果有自主意識的話
應該會怪我們北木居然給他全都露吧......XD

安靜且開心的沐浴著（兩點全露真害羞）


姿勢十足


怡然自得


上岸囉（重點部位被媽媽的手遮住）


舒服舒服


另一個角度看世界

陳小米另類足球裝！

不知為何
當陳小米穿上這副裝扮
就好像是足球員
何以見得
其實也說不上來
就是一個感覺吧～

足球彩色襪


雄糾糾氣昂昂的雙腳


偶要出場囉


預言勝利的微笑


襪一定賣成功


這樣口愛吧

Classic 80's: We Are the World

We Are the World

Classic 80's: Pet Shop Boy

Classic 80's: U2 - Where the streets have no name

小米的彌月禮...

From 彌月禮

From 彌月禮

Package designed by Audrey Chen

EXR layer naming conventions

http://www.mail-archive.com/openexr-user@nongnu.org/msg00178.html

R G B A Z
Raw Colour: Raw.R .G .B
Reflection Colour: Refl.R .G .B
Diffuse Colour: Diff.R .G .B
Specular Colour: Spec.R .G .B
Backdrop Colour: Backdrop.R .G .B
PreEffect Colour: PreEffect.R .G .B

Single channels:
Special, Luminosity, Diffuse, Specularity, Reflectivity, Transparency, Shading,
Shadow, Geometry, DiffShade, SpecShade

Motion.X .Y

the channel names should all be single-letters, Are there cases where you reed to put more letters?  That
would make it easier for people to make layers like "guy.head.spec.R"
and you know that everything before is part of the layer name and the
"R" is the channel.

And also, I think that is you have multiple channels that are tied
together, they should always use the layer format, like Motion.X and
Motion.Y.  I see some files that just say "X" or "Y" or "VX" or
"velX" and there's no good algorithmic way to know they're tied
together.

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

Channel Names

An OpenEXR image can have any number of channels with arbitrary names. The
specialized RGBA image interface assumes that channels with the names "R", "G",
"B" and "A" mean red, green, blue and alpha. No predefined meaning has been
assigned to any other channels. However, for a few channel names we recommend
the interpretations given in the table below. We expect this table to grow over
time as users employ OpenEXR for data such as shadow maps, motion-vector fields
or images with more than three color channels.

name         interpretation
----         --------------
Y            luminance, used either alone, for gray-scale images, or
          in combination with RY and BY for color images.
RY, BY       chroma for luminance/chroma images, see above.
AR, AG, AB   red, green and blue alpha/opacity, for colored mattes
          (required to composite images of objects like colored
          glass correctly).
-------------


A few thoughts on extending this:

- I think "Z" for camera depth should be added to the recommendation list. This
is a de facto standard in many (if not most?) apps already.

- I agree with the other comments that "." is the best way to
go for all other channels, so that associated channels can be easily matched by
layer.

- Layer names should be mostly unrestricted, but there should probably be a
recommendation for nesting within layer names, for example using dots or
underscores (e.g. layer.sublayer.channel). This could support things like
stereo images each with multiple layers. (For what it's worth, Nuke uses
"." for all channel names, but it doesn't allow dots in the
"" part.)

- For consistency, "" should, if possible, be chosen from the list of
main channels: R/G/B/A/Z/Y/RY/BY. This works for layers that represent colors.
Writers should be strict about using the recommended channel suffixes,
but readers should recognize other reasonable versions, like r/g/b/a,
red/green/blue/alpha, etc..

- What about scalar (single value) layers or layers that represent 3D data like
points/normals/vectors? Some apps currently use x/y/z as channel suffixes, e.g.
N.x, N.y, and N.z for normals. At least one uses nx, ny, and nz with no suffix.
For scalars, most apps I've looked at just output the layer name without a
channel suffix, e.g. "myscalar". It would be nice to have a unified,
deterministic rule to handle all of these cases without requiring complex logic
or lists of legal suffixes. What about using simple numerical indices for all
data (non-color) channels? The layer name should be enough for apps to
interpret the individual channels. Scalars could be the same, but with just a
single index. For example: N.0, N.1, N.2, myscalar.0. This idea could also
handle layers holding a 4-point vector or 16-element matrix at each pixel.

Thoughts? There might be a better approach than numerical indices for data
channels, but I can't think of anything else simple and flexible, at least not
without having a system to declare file-specific channel suffixes in a "channel
suffix declarations" attribute, or something like that. That would be an
interesting idea to explore, but I think we need to be practical. Anything more
than a simple naming convention is unlikely to be incorporated by application
developers any time soon.