攝影師七級分類 - 為諷刺而作的精神指南
你的相機並不重要 - 給想要拍出好作品的攝影同好
很中肯的文章，警惕之。
2010年1月11日 星期一
2010年1月4日 星期一
2009年12月19日 星期六
CANON EOS 20D 參數與 DPP 最適調整
蒐集網上分享~
對 EOS 20D機身參數：
對比 -2
銳利度+2
飽和度+1
色調 +0
只拍RAW檔
進DPP調整
DPP3.7.2設定
+RAW影像調整
---暗部調整(1) --> 是-1吧~!!
---銳利度(4)
+進階調整
---亮域雜訊抑制(0) --> 4
色差雜訊抑制 -> 5
這組設定測試過後最耐看
色階自然,銳利度OK.
有調整飽和度所以顏色上會比較討喜.
其他的部分都最接近現場感覺.
測試後發現DPP轉出的JPG(直出、或先TIFF再PhotoCap4轉JPG)整個雪花一片...
研究後發現是"亮域雜訊抑制"的問題 (參 [測試]canon 機身與後製消除雜訊分析 一文)，
後來，改設定
亮域雜訊抑制 -> 4
色差雜訊抑制 -> 5
轉出的JPG終於是適合人看得了~~
對 EOS 20D機身參數：
對比 -2
銳利度+2
飽和度+1
色調 +0
只拍RAW檔
進DPP調整
DPP3.7.2設定
+RAW影像調整
---暗部調整(1) --> 是-1吧~!!
---銳利度(4)
+進階調整
---亮域雜訊抑制(0) --> 4
色差雜訊抑制 -> 5
這組設定測試過後最耐看
色階自然,銳利度OK.
有調整飽和度所以顏色上會比較討喜.
其他的部分都最接近現場感覺.
測試後發現DPP轉出的JPG(直出、或先TIFF再PhotoCap4轉JPG)整個雪花一片...
研究後發現是"亮域雜訊抑制"的問題 (參 [測試]canon 機身與後製消除雜訊分析 一文)，
後來，改設定
亮域雜訊抑制 -> 4
色差雜訊抑制 -> 5
轉出的JPG終於是適合人看得了~~
2009年12月7日 星期一
無線解決方案 - WDS survey (醞釀實作!)
有在用無線AP的一定都常為訊號不穩、熱當~這類問題所苦，近來適逢家裡網路幾乎掛點的狀況，為何用"幾乎"~!因為開個IE竟然要30秒~首頁是google傳統頁ㄟ~~越想越不對，烏龜重置然後爛SMC AP也power down了，狀況一樣沒改善，原以為SMC爛只影響無線的狀況，沒想到用有線連的PC也一樣，重點是，我的wow也沒法玩了~~這簡直是太嚴重了，看來該下定決心換掉它了。
----------------------------------- 分隔 ----------------------------------------
survey解法，有一款 Ruckus 覆蓋王 似乎不錯，但價格不斐，要 $3xxx ，而且我的狀況是樓中樓，也怕它只是距離遠但穿透性無法合我所用；繼續爬文後，發現另一個 solution - Wireless Distribution System(WDS) ，嗯~這似乎能解決我的問題，而且也能保留往後擴充~
這二篇文章：
----------------------------------- 分隔 ----------------------------------------
survey解法，有一款 Ruckus 覆蓋王 似乎不錯，但價格不斐，要 $3xxx ，而且我的狀況是樓中樓，也怕它只是距離遠但穿透性無法合我所用；繼續爬文後，發現另一個 solution - Wireless Distribution System(WDS) ，嗯~這似乎能解決我的問題，而且也能保留往後擴充~
這二篇文章：
可以好好參考，搭 SparkLAN 速連通訊 WRTR-142 802.11g 無線路由器 $888，加購一根10 dBi天線Y購也只要$690搞定，
看來甚至我不必急者買2臺AP，先買一台+天線，或許連WDS都不必了，等試過再報告了。
另外的選擇： 上網3件事DIR-600實測 (上網+下載+Skype) ，看來D-Link可以考慮。
華碩ASUS WL-520GU 似乎也不錯，配合 華碩WL-520gu刷tomato問題請教 這篇改機。
華碩ASUS WL-520GU 似乎也不錯，配合 華碩WL-520gu刷tomato問題請教 這篇改機。
2009年11月28日 星期六
敗了-皇室御用 - 法國夢特嬌頂級新絲纖維冬被
最近常逛486大的敗家網
真的是繼 Mobil01之後另一個要少去為妙的地方！
不過，今天看到 皇室御用 - 法國夢特嬌頂級新絲纖維 冬被 團購
心想，一直對家裡的棉被很不滿意，都是老爸老媽給的(硬塞來的 -.-)棉被，然後每一條都有些故事提醒著我們要飲水思源*&^#種種的...即使它們有的已經很硬了、有的根本是春夏被~~
其實我只想要蓋得暖蓋得爽的棉被~ 就好了，尤其這款被可以水洗!!看來是可以敗下我人生的第一條(自己掏錢買的)棉被了。
真的是繼 Mobil01之後另一個要少去為妙的地方！
不過，今天看到 皇室御用 - 法國夢特嬌頂級新絲纖維 冬被 團購
心想，一直對家裡的棉被很不滿意，都是老爸老媽給的(硬塞來的 -.-)棉被，然後每一條都有些故事提醒著我們要飲水思源*&^#種種的...即使它們有的已經很硬了、有的根本是春夏被~~其實我只想要蓋得暖蓋得爽的棉被~ 就好了，尤其這款被可以水洗!!看來是可以敗下我人生的第一條(自己掏錢買的)棉被了。
2009年11月10日 星期二
Visual Studio從2003到2005的演化
身為還在VS 2003抽不出身的本團隊，在面對VS 2008 的現在，有必要了解齊演進過程，下文詳細載明其演進。
參考來源： 關心: Visual Studio從2003到2005的演化（全文） (在「Google 網頁註解」中檢視)更換 OFFICE 2007 的序號
Office的非正版提示苦惱了我好一陣子，尤其在客戶端 present 時真是太刺眼了！
找到這篇文章，一試果然有用。
(以下全文轉載自 Blog of A Yellow Tiger)
今天灌MSDN的Visio，灌好了就直接啟動。結果，啟動次數被用光了！大家還真是會用啊，好不容易弄到另一組MSDN的產品金鑰，卻不知道要怎麼換產品金鑰。難道，要重灌Visio才能再打一次產品金鑰？
別再相信沒有事實根據的說法了！求助於Google吧，用中文找，找到的都是教破解或是免序號。改用英文找，以"visio 2007 change key"為關鍵字，果然一下就找到了，趕快記下來，下次再遇到同樣的情形就可以參考了：
1. 在Registry裡找到下面的subkey
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Registration
2. 因為Visio和Office 2007的其他東西分屬於不同的subkey，所以，Registration這個subkey下面會有不只一個長得像{901.......0FF...}的subkey。一一點進去看ProductName，就可以確認Visio是在哪一個subkey之下。
3. 在Visio所在的subkey中，把ProductID和DigitalProductID兩個subkey給刪了。
4. 執行Visio，就會出現輸入產品金鑰的對話框了。輸入新的序號後，就可以進入Visio的畫面並接著成功啟動了。
PS1:用正版還要受罪，真是不太爽啊！
PS2:這方法適用於其他Office 2007的產品。
找到這篇文章，一試果然有用。
(以下全文轉載自 Blog of A Yellow Tiger)
今天灌MSDN的Visio，灌好了就直接啟動。結果，啟動次數被用光了！大家還真是會用啊，好不容易弄到另一組MSDN的產品金鑰，卻不知道要怎麼換產品金鑰。難道，要重灌Visio才能再打一次產品金鑰？
別再相信沒有事實根據的說法了！求助於Google吧，用中文找，找到的都是教破解或是免序號。改用英文找，以"visio 2007 change key"為關鍵字，果然一下就找到了，趕快記下來，下次再遇到同樣的情形就可以參考了：
1. 在Registry裡找到下面的subkey
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Registration
2. 因為Visio和Office 2007的其他東西分屬於不同的subkey，所以，Registration這個subkey下面會有不只一個長得像{901.......0FF...}的subkey。一一點進去看ProductName，就可以確認Visio是在哪一個subkey之下。
3. 在Visio所在的subkey中，把ProductID和DigitalProductID兩個subkey給刪了。
4. 執行Visio，就會出現輸入產品金鑰的對話框了。輸入新的序號後，就可以進入Visio的畫面並接著成功啟動了。
PS1:用正版還要受罪，真是不太爽啊！
PS2:這方法適用於其他Office 2007的產品。
2009年11月9日 星期一
M$的VSTS(Visual Studio Team System)
以下內容轉載自 Kai's World 微軟的VSTS(Visual Studio Team System)能有多少發揮呢?
最近公司要打算導入VSTS把IT的某個開發Team拿來當白老鼠，基於一些理由我也就需要研究一下VSTS在玩什麼把戲
看完一些他的教學文件跟產品介紹文件，我其實是非常同意他的遠見，他是想做一個系統開發平台，建立一個Team Foundation Server然後不管是開發人員、架構師、測試人員、DBA、Project Manager通通在同一個平台做事，然後他再提供各個專業人員所需要得工具，讓大家協同合作，還有內建的一些軟工的流程可以套用，落實開發流程，進一步自動產生一些有用的報告或是"Real"的報告讓Project Manager真正掌握開發進度。
我想以上是他想要完成的目標，再細部的往下研究一下
VSTS他並非使用UML的語言而是DSL(Domain Specific Language)，他提出的理由是UML太過抽象，是否可以應用在不同的Domain，我們是不是應該因應不同的Domain有不同的語言，所以DSL還有提供讓你定義你自己的DSL，他也提出了一些學術上的論點，找來當初制定UML的人來幫他背書。
我沒用過DSL也沒有裝來畫畫看，所以我無法評論，但是我想很多人會有跟我一樣的想法"搞什麼又要來一個規格之爭嗎"好不容易花時間學會了UML，結果你要我用你自己定義的DSL，我又要花時間學DSL，然後只For你的VSTS，這樣實在是!@#$%^&*(這也是我沒裝來畫畫看的原因)，不知道是不是我有所誤會，說不定是共存，讓想用UML的用UML，想用DSL的用DSL這樣比較make sense如果是強迫中獎這樣我想很多人都很難接受。
接下來分享的部份是我認為比較有價值的部份"軟體工程"
我相信在軟工的世界沒有什麼Best Practice，所以目前才有這麼多派系之分，不同公司、不同文化、不同案子都可能產生公司自己的Best Practice，這次微軟提供了微軟自己的MSF(Microsoft Solutions Framework)你可以用微軟開發軟體的方法論來開發自己的軟體，微軟也號稱這套方法論在微軟內部已經從1994年使用自今(不知道大家覺得微軟的品質如何)這MSF涵蓋了CMMI Level3也讓你對未來Level4、Level5做準備。
如果只是這樣我想大家會問他跟RUP沒什麼兩樣阿
重點來了我覺得最吸引人的有兩點
1.他也讓Agile同時存在，在Anile部分他提供了MSF for Agile Software Development微軟從Motorola找來Agile社群中的David Anderson來操刀，讓兩種方法論都可以在VSTS上使用，但是這還不是最新引人的，最吸引人的是你可以客製化你的流程，他只是提供你最極端的兩個範本，你可以依據自己組織的需要調整你自己的開發流程，微軟也宣稱會繼續update各大學派的方法論範本給大家下載免費使用(當然VSTS是要錢的)。
2.文件管理部份由於VSTS是系統協同合作的，很多報告可以由系統自動產生，讓不愛寫文件的工程師工作量減輕不少(我也不愛寫但是有時又是非寫不可)，再者我之前提到的"Real"，很多人都有經驗明明，你手上的程式只完成30%，但是project schedule是50%，你在report中要寫多少 ? maybe 40%，也或許你認為後面的開發速度會突飛猛進cover現在的delay而填上50%，導致Project manager拿到錯誤的資料，而做出錯誤的評估，你也浪費時間寫出一份讓人有錯誤評估的report。
遇到這狀況，我還寧願不要有這份report，讓工程師專心寫程式。Project Manager透過Project manager的工具連上server，看看目前完成度或是直接選取所需要的資訊。
至於DBA，版本控管，還有測試方面市面上已經有很多工具，大致大同小異就不多做介紹，接下來就是讓市場跟時間來證明他了。
---------------------------------------------------------------------------
鳥毅的Blog:安裝Team Foundation Server SP1 測試環境
VSTS 實驗室: TFS 2008 單一伺服器簡易安裝說明 (在「Google 網頁註解」中檢視)
Visual Studio Team Foundation Server 安裝筆記
最近公司要打算導入VSTS把IT的某個開發Team拿來當白老鼠，基於一些理由我也就需要研究一下VSTS在玩什麼把戲
看完一些他的教學文件跟產品介紹文件，我其實是非常同意他的遠見，他是想做一個系統開發平台，建立一個Team Foundation Server然後不管是開發人員、架構師、測試人員、DBA、Project Manager通通在同一個平台做事，然後他再提供各個專業人員所需要得工具，讓大家協同合作，還有內建的一些軟工的流程可以套用，落實開發流程，進一步自動產生一些有用的報告或是"Real"的報告讓Project Manager真正掌握開發進度。
我想以上是他想要完成的目標，再細部的往下研究一下
VSTS他並非使用UML的語言而是DSL(Domain Specific Language)，他提出的理由是UML太過抽象，是否可以應用在不同的Domain，我們是不是應該因應不同的Domain有不同的語言，所以DSL還有提供讓你定義你自己的DSL，他也提出了一些學術上的論點，找來當初制定UML的人來幫他背書。
我沒用過DSL也沒有裝來畫畫看，所以我無法評論，但是我想很多人會有跟我一樣的想法"搞什麼又要來一個規格之爭嗎"好不容易花時間學會了UML，結果你要我用你自己定義的DSL，我又要花時間學DSL，然後只For你的VSTS，這樣實在是!@#$%^&*(這也是我沒裝來畫畫看的原因)，不知道是不是我有所誤會，說不定是共存，讓想用UML的用UML，想用DSL的用DSL這樣比較make sense如果是強迫中獎這樣我想很多人都很難接受。
接下來分享的部份是我認為比較有價值的部份"軟體工程"
我相信在軟工的世界沒有什麼Best Practice，所以目前才有這麼多派系之分，不同公司、不同文化、不同案子都可能產生公司自己的Best Practice，這次微軟提供了微軟自己的MSF(Microsoft Solutions Framework)你可以用微軟開發軟體的方法論來開發自己的軟體，微軟也號稱這套方法論在微軟內部已經從1994年使用自今(不知道大家覺得微軟的品質如何)這MSF涵蓋了CMMI Level3也讓你對未來Level4、Level5做準備。
如果只是這樣我想大家會問他跟RUP沒什麼兩樣阿
重點來了我覺得最吸引人的有兩點
1.他也讓Agile同時存在，在Anile部分他提供了MSF for Agile Software Development微軟從Motorola找來Agile社群中的David Anderson來操刀，讓兩種方法論都可以在VSTS上使用，但是這還不是最新引人的，最吸引人的是你可以客製化你的流程，他只是提供你最極端的兩個範本，你可以依據自己組織的需要調整你自己的開發流程，微軟也宣稱會繼續update各大學派的方法論範本給大家下載免費使用(當然VSTS是要錢的)。
2.文件管理部份由於VSTS是系統協同合作的，很多報告可以由系統自動產生，讓不愛寫文件的工程師工作量減輕不少(我也不愛寫但是有時又是非寫不可)，再者我之前提到的"Real"，很多人都有經驗明明，你手上的程式只完成30%，但是project schedule是50%，你在report中要寫多少 ? maybe 40%，也或許你認為後面的開發速度會突飛猛進cover現在的delay而填上50%，導致Project manager拿到錯誤的資料，而做出錯誤的評估，你也浪費時間寫出一份讓人有錯誤評估的report。
遇到這狀況，我還寧願不要有這份report，讓工程師專心寫程式。Project Manager透過Project manager的工具連上server，看看目前完成度或是直接選取所需要的資訊。
至於DBA，版本控管，還有測試方面市面上已經有很多工具，大致大同小異就不多做介紹，接下來就是讓市場跟時間來證明他了。
---------------------------------------------------------------------------
TFS 出了名的難裝~ 原本還想使用已經於VM既有的SQL 2008 DB，但似乎狀況更多，到頭來重作一份VM從頭來過，DB改用SQL 2005就順了~
安裝記實：
1.SQL Server Agent需啟動且為自動。
2.SQL Server Browser需啟動且為自動。
(到最後，整個SQL開頭的service都設自動且啟動！除了SQL Server Active Directory Helper外)
3.使用 SQL Server 介面區組態工具啟用遠端 TCP/IP 連接。
4.SQL 2005需上到 SP2。
終於，最後一個問題僅剩硬體需求，CPU需2.2G，就不理它繼續下一步，接下來的過程如同下述說明，建立TFSSERVICE帳戶啟動服務用 and keep Next 直到完成。
5.依個人喜好，可以依照"安裝指南"，安裝"Team Foundation Build"。
6.再安裝"Team Explorer"。
7.安裝Windows SharePoint Services Extensions。
8.安裝TFS SP1。
這樣就全部裝好，接下來就打開 Visual Studio，使用Team總管連結上Server。
(2009/11/24)
裝是裝好了，但要開第一個專案就出問題了!!~ 一直出現錯誤
Error
無法連接到位於 192.168.XX.XX 的指定 SQL Server Reporting Services。
Explanation
[專案建立精靈] 無法連接到位於 192.168.XX.XX 的 SQL Server Reporting Services。此時尚無法判斷連接失敗的原因。由於連接失敗，精靈無法完成建立 SQL Server Reporting Services 網站。
(2009/11/25)
改參考 Huan-Lin 學習筆記 on DotBlogs 中的 Visual Studio Team Foundation Server 安裝筆記重裝整個TFS，這次選用SQL 2005 Ent版，並於SQL裝完上SP3後安裝WSS3.0 with SP2。
怎麼這次是被診斷沒安裝Analysis Service～ 天阿，心裡真是很X。
(2009/11/26)
幾經波折，被Firewall卡了一陣子，最後索性依照 install guid把所有port開啟(NOD32請切到互動過濾模式，不然都不知道它會不會亂濾！)，原先仍一直被診斷沒安裝Analysis Service~ 試著merge TFS install image與sp1後重試還是一樣的訊息，期間改了多次service啟用帳戶，最後是都以TFSSERVICE啟動，後來似乎因為WSS沒啟用所致 -.- ，
終於~~只剩CPU或RAM不符要求，終於可以下一步了...
話說，要繼續TFS安裝時，在WSS一步又被卡了，訊息如下：
Error codes: TF220035 (The URL at the specified location is not a Windows SharePoint Services site) or TF220041 (The specified Windows SharePoint Services site URL is not the default site collection site)
這問題請見TFS 2008 on Windows Server 2008 Installation Problem (TF220035 or TF220041)又過了一關~~ 下一王是
Error 28805 Setup cannot finish the request to the SQL Server 2005 Reporting Service report server. Verify that the report server is installed and running, and that you have sufficient privledges to access it看來是Reporting Service的加密金鑰檔住~直接刪除！！又過了一關~~
挖塞~~已成功安裝~~~~~~(我哭了...)
看來，要開始安裝TFS前，需確認以下四個URL都要有：
http://btf-tfs/
http://localhost/reports/
http://btf-tfs:30736
鳥毅的Blog:安裝Team Foundation Server SP1 測試環境
VSTS 實驗室: TFS 2008 單一伺服器簡易安裝說明 (在「Google 網頁註解」中檢視)
Visual Studio Team Foundation Server 安裝筆記
2009年11月6日 星期五
Introduce UML Class Diagram
(以下原文轉載自 smalltide 's Blog Introduce UML Class Diagram )
對UML的類別圖稍微做些簡介,不討論程式語言相關的部份
純為概念性的簡介
類別圖主要功能是表示物件之間的靜態關係
類別圖由三個部份組成
1.類別名稱 2.成員變數 3.成員函式
成員函式前有符號代表存取權限
類別之間的關係有以下幾種
1.Association(關聯)(knows a)
X知道Y的存在
X可能以pointer(指標)或reference(參考)知道Y的存在
在概念模型階段方向性(箭頭)通常不太有意義可以省略
2.Dependency(相依)(use a)
X相依Y
Y若改變 X可能會受到影響 但X的改變不會影響到Y
X可能有某個functiond可以call Y的function
3.Composition(組合)(has a)
X組合Y
Composition是一種整體完全擁有部分
如車子(X)擁有4個輪子(Y)
當(車子)X消滅時(4個輪子)Y同時也會消滅
4.Aggregation(聚合)
X聚合Y
Aggregation是一種"擁有性"比較弱的關係
如車子(X)裡面有4個人(Y)
當車子(X)消滅時4個人(Y)不會消滅(當然車禍除外!!)
5.Inheritance(繼承)(UML以繼承表示泛型關係)
X繼承Y Z繼承Y 此時Y和(X,Z)之間就存在著泛型關係 Y是共同化(抽象化)X,Z則是特性化(具體化)
如 人(Y) 美國人(X) 台灣人(Z) 日本人(W)
XZW繼承Y 則 Y和XZW就存在泛型關係
對UML的類別圖稍微做些簡介,不討論程式語言相關的部份
純為概念性的簡介
類別圖主要功能是表示物件之間的靜態關係
類別圖由三個部份組成
1.類別名稱 2.成員變數 3.成員函式
成員函式前有符號代表存取權限
類別之間的關係有以下幾種
1.Association(關聯)(knows a)
X知道Y的存在
X可能以pointer(指標)或reference(參考)知道Y的存在
在概念模型階段方向性(箭頭)通常不太有意義可以省略
2.Dependency(相依)(use a)
X相依Y
Y若改變 X可能會受到影響 但X的改變不會影響到Y
X可能有某個functiond可以call Y的function
3.Composition(組合)(has a)
X組合Y
Composition是一種整體完全擁有部分
如車子(X)擁有4個輪子(Y)
當(車子)X消滅時(4個輪子)Y同時也會消滅
4.Aggregation(聚合)
X聚合Y
Aggregation是一種"擁有性"比較弱的關係
如車子(X)裡面有4個人(Y)
當車子(X)消滅時4個人(Y)不會消滅(當然車禍除外!!)
5.Inheritance(繼承)(UML以繼承表示泛型關係)
X繼承Y Z繼承Y 此時Y和(X,Z)之間就存在著泛型關係 Y是共同化(抽象化)X,Z則是特性化(具體化)
如 人(Y) 美國人(X) 台灣人(Z) 日本人(W)
XZW繼承Y 則 Y和XZW就存在泛型關係
2009年11月4日 星期三
flickr大量貼圖的好用工具---Friendly.flickr
挖~真是太讚了~ 身處這個網路的世代，要寫篇文章、回覆些論壇帖子，沒圖幾乎是沒人看；雖然已經付費上 Flickr Pr，但如果只是個放圖的地方，那真是不值得花錢！
發現這個工具，可以將Flickr上的圖轉貼上Blog或其它論壇，詳見
Friendly.flickr原作-搖擺天秤的程式開發日誌
另外有其它人的推薦~~
輕鬆插入 flickr 的相片到部落格 - Friendly.Flickr
《推薦》flickr大量貼圖的好用工具---Friendly.flickr & quickr pickr
二話不說，直接試試啦。
測試貼圖並於 Friendly.flickr 上排版後結果 (以下為轉貼於 Flickr 上的相片)
發現這個工具，可以將Flickr上的圖轉貼上Blog或其它論壇，詳見
Friendly.flickr原作-搖擺天秤的程式開發日誌
另外有其它人的推薦~~
輕鬆插入 flickr 的相片到部落格 - Friendly.Flickr
《推薦》flickr大量貼圖的好用工具---Friendly.flickr & quickr pickr
二話不說，直接試試啦。
測試貼圖並於 Friendly.flickr 上排版後結果 (以下為轉貼於 Flickr 上的相片)
2009年10月30日 星期五
隨身機之王道：MINOLTA TC-1
極米的 隨心所欲－隨身機之王道：MINOLTA TC-1 全世界介紹TC1寫得最好的文章。
MINOLTA投注了該公司最頂尖的開發技術與科技精華完成這台全世界最小的輕便相機，到底有什麼特殊之處?
爬原文吧~~
MINOLTA投注了該公司最頂尖的開發技術與科技精華完成這台全世界最小的輕便相機，到底有什麼特殊之處?
爬原文吧~~
2009年10月23日 星期五
轉貼 - DPP關於銳利度的一點心得分享
(原帖)
一般來講，對人像而言~~機身預設銳利度4就很夠了...
銳利再高鋸齒狀會越來越明顯..結果就是會出現網路上不少銳過頭很不自然的照片
然後將暗處-1 or 重口味-2 ,整張照片會看起來又清楚又但膚色依然保持粉嫩..
不建議加對比..因為對比會將亮處拉更亮,亮處容易爆掉..臉不容易生硬
風景的話DPP銳利頂多用到6,這時鋸齒狀已經快看得出來了
一樣用暗處調整,通常我喜歡-1就很夠 重口味-2
對比的話視情況....通常還是比較偏向以暗處調整和亮處調整分開調
一般來講，對人像而言~~機身預設銳利度4就很夠了...
銳利再高鋸齒狀會越來越明顯..結果就是會出現網路上不少銳過頭很不自然的照片
然後將暗處-1 or 重口味-2 ,整張照片會看起來又清楚又但膚色依然保持粉嫩..
不建議加對比..因為對比會將亮處拉更亮,亮處容易爆掉..臉不容易生硬
風景的話DPP銳利頂多用到6,這時鋸齒狀已經快看得出來了
一樣用暗處調整,通常我喜歡-1就很夠 重口味-2
對比的話視情況....通常還是比較偏向以暗處調整和亮處調整分開調
2009年10月17日 星期六
CANON全時手動對焦鏡頭
基本上有這個功能的鏡頭還滿多的，
依官網的解說，看到有下面這一個 Full Time Manual 的圖示
，就是有此功能，所有使用環形超音波馬達的 EF 鏡頭都有全時手動功能，不限 L 鏡。而既然全時手動功能是超音波馬達（USM）所帶來的功能，那 EF-S 鏡頭也是依有沒有搭載超音波馬達來看有沒有全時手動功能的。
依官網的解說，看到有下面這一個 Full Time Manual 的圖示
，就是有此功能，所有使用環形超音波馬達的 EF 鏡頭都有全時手動功能，不限 L 鏡。而既然全時手動功能是超音波馬達（USM）所帶來的功能，那 EF-S 鏡頭也是依有沒有搭載超音波馬達來看有沒有全時手動功能的。
2009年10月12日 星期一
2009年10月11日 星期日
2009年9月22日 星期二
品一杯好咖~重回手沖咖啡的世界
好長一段時間沒好好沖杯咖啡了~(自從好咖們都不在身邊了...)
不過多虧了艾倫的精心烘培好豆，有印尼曼特寧、巴西山多士、肯亞AA、巴拿馬卡門莊園和衣索比亞耶加雪菲，這下不好好品嚐就真的太對不起自己囉!
誰知遍尋不到我的濾滴器，只好上網購找找了~~ 突然看到這組金光閃閃的機絲
這款濾滴器不需要再買濾紙，非常好清洗，金屬的網子是24K鍍金，跟完美好咖真是絕配~
網子是特殊設計，咖啡液體流動很順暢不會過濾掉咖啡香醇口感的物質只要飲水機有熱水就可以馬上沖一杯，不會塞住，頂多用牙刷稍為刷即可，基本上只要好好用，是用不太壞。
代理商的網站，可以看到更詳盡的內容。有swissgold瑞士製造公司elfo ag的介紹、swissgold產品特色、使用方法，甚至將swissgold與其他的沖煮咖啡器具做比較，網站內容還滿多的，有興趣的人可以慢慢看。
我上網購自 Y拍：北極海咖啡
沒想到它還是在板橋江翠站附近，看來是註定要買的了。
感謝艾倫兄了~
不過多虧了艾倫的精心烘培好豆，有印尼曼特寧、巴西山多士、肯亞AA、巴拿馬卡門莊園和衣索比亞耶加雪菲，這下不好好品嚐就真的太對不起自己囉!
誰知遍尋不到我的濾滴器，只好上網購找找了~~ 突然看到這組金光閃閃的機絲
這款濾滴器不需要再買濾紙，非常好清洗，金屬的網子是24K鍍金，跟完美好咖真是絕配~
網子是特殊設計，咖啡液體流動很順暢不會過濾掉咖啡香醇口感的物質只要飲水機有熱水就可以馬上沖一杯，不會塞住，頂多用牙刷稍為刷即可，基本上只要好好用，是用不太壞。
代理商的網站，可以看到更詳盡的內容。有swissgold瑞士製造公司elfo ag的介紹、swissgold產品特色、使用方法，甚至將swissgold與其他的沖煮咖啡器具做比較，網站內容還滿多的，有興趣的人可以慢慢看。
我上網購自 Y拍：北極海咖啡
沒想到它還是在板橋江翠站附近，看來是註定要買的了。
感謝艾倫兄了~
2009年9月14日 星期一
解析度、畫素與洗照片尺寸
(轉載自 http://www.mobile01.com/topicdetail.php?f=164&t=50944 )
1.解析度：
解析度，慣用單位表示上，以dpi (dot per inch)來顯示，白話一點就是1英吋的長度裡包含了幾個點的個數，
注意啦～這些點是排成一直線的喔！
實質上，就有點像是長度單位裡面又隱藏包含了密度的意義，所以呢...解析度越高，就是1英吋長度內點數越多，也就是我們常說的解析度越高，看起來就越細膩。
舉例說：一條72dpi的線，我們肉眼所看到的這條線，他在每一英吋的長度內，是由72個點所組成，聰明的看官，如你所想：
一條300dpi的線，就是每一英吋的長度內，由300個點所組成。
（注意囉～ 72dpi 與 300dpi ～可是重要數字喔）
2.畫素：
想必大家對〝公分〞這長度單位非常慣用熟悉，然後面積單位〝平方公分〞，
沒錯，畫素其實就有點像是面積的意思。
但它不以平方單位表示，而是以多少畫素來描述。
打各比方說：
例1：
（長度500個點）乘以（長度500個點）＝ 250000個畫素（25萬畫素）
例2：
我們常把螢幕設為：1024*768，此時我們看到的畫素約為78萬6千個畫素，
又因為，螢幕一般解析度為72dpi（或96dpi），所以眼力不太差的話，通常都可看到我們螢幕上的點，
而（寬1024個點）*（高768個點）＝786,432畫素，就構成我們看到的畫面。
註：一般數位相機的CCD（感光元件）拍的數位照片大都為72dpi ←（從ACDSee軟體，可看到這數值）。
註：CCD，比方說，就像是傳統像機的底片。
例3：
一般來說，人的肉眼看圖片，當解析度≧300 dpi 時，就不易察覺我們是在看由一大堆點所組成的圖，也就是說，此時眼睛看到的是：由點組成之非常平滑連續（smoth，continuous）的線，又由線組成之非常平滑連續（smoth，continuous）的面...
簡單講就是〝一張圖〞（既不叫他為〝點〞，也不叫他為〝線〞）。
想必當然，我們一般洗數位照片，就是採用300 dpi 的。
3.洗照片尺寸：
一堆廢話後...大家關心的重點來了...不再贅述，直接舉例說明：
例1.
洗3*5照片＝3英吋*5英吋（採用 300dpi ）
＝（3*300個點）*（5*300個點）＝（3*5*90000）
＝1350000畫素（1百35萬畫素）
同理
例2：
洗4*6照片＝4英吋*6英吋（採用 300dpi ）
＝（4*300個點）*（6*300個點）＝（4*6*90000）
＝ 2160000畫素（2百16萬畫素）
再同理...不贅述了...
洗照片所需畫素：
3*5吋照＝3*5*90000＝1百35萬畫素
4*6吋照＝4*6*90000＝2百16萬畫素...這最常用吧～
5*7吋照＝5*7*90000＝3百15萬畫素
6*8吋照＝6*8*90000＝4百32萬畫素
7*9吋照＝7*9*90000＝5百67萬畫素
1.解析度：
解析度，慣用單位表示上，以dpi (dot per inch)來顯示，白話一點就是1英吋的長度裡包含了幾個點的個數，
注意啦～這些點是排成一直線的喔！
實質上，就有點像是長度單位裡面又隱藏包含了密度的意義，所以呢...解析度越高，就是1英吋長度內點數越多，也就是我們常說的解析度越高，看起來就越細膩。
舉例說：一條72dpi的線，我們肉眼所看到的這條線，他在每一英吋的長度內，是由72個點所組成，聰明的看官，如你所想：
一條300dpi的線，就是每一英吋的長度內，由300個點所組成。
（注意囉～ 72dpi 與 300dpi ～可是重要數字喔）
2.畫素：
想必大家對〝公分〞這長度單位非常慣用熟悉，然後面積單位〝平方公分〞，
沒錯，畫素其實就有點像是面積的意思。
但它不以平方單位表示，而是以多少畫素來描述。
打各比方說：
例1：
（長度500個點）乘以（長度500個點）＝ 250000個畫素（25萬畫素）
例2：
我們常把螢幕設為：1024*768，此時我們看到的畫素約為78萬6千個畫素，
又因為，螢幕一般解析度為72dpi（或96dpi），所以眼力不太差的話，通常都可看到我們螢幕上的點，
而（寬1024個點）*（高768個點）＝786,432畫素，就構成我們看到的畫面。
註：一般數位相機的CCD（感光元件）拍的數位照片大都為72dpi ←（從ACDSee軟體，可看到這數值）。
註：CCD，比方說，就像是傳統像機的底片。
例3：
一般來說，人的肉眼看圖片，當解析度≧300 dpi 時，就不易察覺我們是在看由一大堆點所組成的圖，也就是說，此時眼睛看到的是：由點組成之非常平滑連續（smoth，continuous）的線，又由線組成之非常平滑連續（smoth，continuous）的面...
簡單講就是〝一張圖〞（既不叫他為〝點〞，也不叫他為〝線〞）。
想必當然，我們一般洗數位照片，就是採用300 dpi 的。
3.洗照片尺寸：
一堆廢話後...大家關心的重點來了...不再贅述，直接舉例說明：
例1.
洗3*5照片＝3英吋*5英吋（採用 300dpi ）
＝（3*300個點）*（5*300個點）＝（3*5*90000）
＝1350000畫素（1百35萬畫素）
同理
例2：
洗4*6照片＝4英吋*6英吋（採用 300dpi ）
＝（4*300個點）*（6*300個點）＝（4*6*90000）
＝ 2160000畫素（2百16萬畫素）
再同理...不贅述了...
洗照片所需畫素：
3*5吋照＝3*5*90000＝1百35萬畫素
4*6吋照＝4*6*90000＝2百16萬畫素...這最常用吧～
5*7吋照＝5*7*90000＝3百15萬畫素
6*8吋照＝6*8*90000＝4百32萬畫素
7*9吋照＝7*9*90000＝5百67萬畫素
2009年9月12日 星期六
觀景窗倍率、對焦點分佈
(轉貼自 http://www.wretch.cc/blog/grantliang/)
1. 視野率:
在取景時，透過景觀窗看到的實際畫面．
例如95%視野率，代表你可以看到實際畫面的95%，在其他邊邊角角的地方
是整個被切掉的．這有什麼差別?
差別在於，你抓到了一個完美畫面後，回家一看，發現邊邊怎麼多了隻手啊、腳啊
或者是說，你想拍一個唯美的裸女圖，結果回家一看，發現三點全都入鏡了 (驚喜?)
100%視野率的有：Nikon D300 、Nikon D3 、Sony A900 、Canon 1DsMK3 、Canon 1D MK3 、Nikon D2x
不滿的有：Canon 5D 、Canon 40D 、Nikon D700
2.放大倍率 & 面積：
這純碎是片幅大的屌
片幅越大，他反映出來的觀景窗看起來就越大
放大倍率 = 觀景窗 / 感光元件
反正，要大的，挑全幅機就對了．因為APS機放大倍率再大，始終也是要卡掉，所以反而沒有全幅機來的大
(詳請見全文)
1. 視野率:
在取景時，透過景觀窗看到的實際畫面．
例如95%視野率，代表你可以看到實際畫面的95%，在其他邊邊角角的地方
是整個被切掉的．這有什麼差別?
差別在於，你抓到了一個完美畫面後，回家一看，發現邊邊怎麼多了隻手啊、腳啊
或者是說，你想拍一個唯美的裸女圖，結果回家一看，發現三點全都入鏡了 (驚喜?)
100%視野率的有：Nikon D300 、Nikon D3 、Sony A900 、Canon 1DsMK3 、Canon 1D MK3 、Nikon D2x
不滿的有：Canon 5D 、Canon 40D 、Nikon D700
2.放大倍率 & 面積：
這純碎是片幅大的屌
片幅越大，他反映出來的觀景窗看起來就越大
放大倍率 = 觀景窗 / 感光元件
反正，要大的，挑全幅機就對了．因為APS機放大倍率再大，始終也是要卡掉，所以反而沒有全幅機來的大
(詳請見全文)
2009年8月18日 星期二
面試系統分析設計的好題目
今天終於下定決心update面試考題，看過SAD方面有一篇很好的文章，轉仔原文如下。
(原文轉載自 克明老師Blog 從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇 )
(原文轉載自 克明老師Blog 從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇 )
如果我是某大軟體公司的主管，要應徵軟體結構性的設計人員 (偏對技術性，而非需求分析)，一般的職稱是稱之為 系統設計師 (SD, System Designer)，或者號稱為架構師 (Architect)、資深技術人員等。 若他們在履歷表上寫著擅長或懂 "O-O (Object Oriented)" 或 "UML"、結構設計 等，那麼，我不會考他們什麼 UML 語法還是 設計樣式 (Design Pattern) 等等。 那只是 "背書" 而已，一點意義都沒有。 要背書的話，不如直接給個電腦上網，然後要應徵人員展現如何透過 Google 查詢找到如何實做設計樣式的方法還比較實在。
我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！
所以，我會提供一個如這樣的考題：
上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。
老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。
表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：
我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！
所以，我會提供一個如這樣的考題：
Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤，相對來說，一個標籤可以有一到多個書籤。 另外，標籤是不會含有子標籤 (Sub-Tag) 的。
如果我要改良 Google 書籤的設計，希望能再加上 "資料夾 (folder)" 的管理觀念，也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一)，而某一個資料夾可以擁有一到多個書籤，同時資料夾也能再包含子資料夾 (Sub-folder)。
同樣類似的應用，可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。
請你利用 UML 類別圖，來表達出關於 書籤、標籤與資料夾的結構關係，並簡單說明你的設計想法。
上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。
老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。
表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：
這張設計圖該如何解讀呢？
先觀察紅色區塊，也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看，它可以被多個 標籤 標記，所以在多重性 (multiplicity)的表達，會是 1..* (一到多)。 再來從 標籤 的角度來看，一個標籤可以有一到多個 書籤，所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題，大概知道意思就可以了。
再來就是觀察藍色區塊這邊，這就是典型的 "複合結構 (composite structure)" 樣式了，它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來，成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢？ 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾，在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係，它必然被包含 (也就是聚合關係)在某一個 資料夾 內，所以在 資料夾 類別這邊的 多重性 是表達為 1；而一個 資料夾 可以有 一到多 個書籤與子資料夾，所以在 "Bookmark Entry" 類別這邊，多重性是表達為 1..* 。
說實在的，即使不會複合結構的表達也沒關係，若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別)，這就夠了，在這個考題當中，反而要突顯的不會是資料夾的樹狀結構，再次強調，是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在，這才是關鍵。
再來，又如何知道上述的設計圖是正確的呢？ 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確，那太耗時費工了；我強烈建議使用 物件圖 (object diagram)，利用實際的案例，對應所設計的類別，很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了，讀者若有興趣，可以利用 UML 工具(如 EA)來練習看看，然後也可以把 Model 檔寄給我，多少我還能協助 Review 驗證的。
※ 延伸參考： o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇。
先觀察紅色區塊，也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看，它可以被多個 標籤 標記，所以在多重性 (multiplicity)的表達，會是 1..* (一到多)。 再來從 標籤 的角度來看，一個標籤可以有一到多個 書籤，所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題，大概知道意思就可以了。
再來就是觀察藍色區塊這邊，這就是典型的 "複合結構 (composite structure)" 樣式了，它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來，成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢？ 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾，在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係，它必然被包含 (也就是聚合關係)在某一個 資料夾 內，所以在 資料夾 類別這邊的 多重性 是表達為 1；而一個 資料夾 可以有 一到多 個書籤與子資料夾，所以在 "Bookmark Entry" 類別這邊，多重性是表達為 1..* 。
說實在的，即使不會複合結構的表達也沒關係，若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別)，這就夠了，在這個考題當中，反而要突顯的不會是資料夾的樹狀結構，再次強調，是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在，這才是關鍵。
再來，又如何知道上述的設計圖是正確的呢？ 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確，那太耗時費工了；我強烈建議使用 物件圖 (object diagram)，利用實際的案例，對應所設計的類別，很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了，讀者若有興趣，可以利用 UML 工具(如 EA)來練習看看，然後也可以把 Model 檔寄給我，多少我還能協助 Review 驗證的。
※ 延伸參考： o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇。
訂閱：
文章 (Atom)