「mm」を含む日記 RSS

はてなキーワード: mmとは

<前の25件

2009-01-29

■http://anond.hatelabo.jp/20090128232804

横だけど、お客様は神様ですというのには意味がいくつかあってだな。

利用してくれるお客様は神様のようにありがたい。

という普段の意味と、

うちのお客さんは神様が相手の商売であって、あなたはその神様のご利益によって運ばれた生贄。

神様ありがとう、アーメン。みたいな意味があるんじゃないかって５mmだけ思った。

だから日本人は毟られるんだよ。

Permalink | 記事への反応(0) | 00:15

2008-11-26

■http://anond.hatelabo.jp/20081126000904

なるほどね、やっぱり残るのか...

ありがとうございましたmm

Permalink | 記事への反応(0) | 00:33

2008-09-25

■デジカメでの静止画サイズの決め方

たまにデジカメでの静止画の解像度の決め方をきかれるのでここにメモ。RAWで撮ることは前提としていない。

実例があった方がわかりやすいので、Canon IXY DIGITAL 920 IS http://cweb.canon.jp/cgi-bin/camera/dcam/spec.cgi?pr=ixyd920is を引き合いに説明する。

とにかくいい画質で保存したい場合

一番高い解像度と、一番いい画質でOK、ではない。まあ、間違ってはいないけど、一枚のサイズが大きくなるに従ってPCでのハンドリングが悪くなったりして都合が悪い(数枚レベルでもサムネイル表示に待たされたり)。

920ISの有効画素数は1,030万画素。一番高い画素数はラージ：3648×2736。3648×2736=9,980,928でだいたい1,000万に近い値になっている。(中略：キーワード：ベイヤー配列、カラーフィルタetc.)んで、だいたい1/3程度の画素数になる解像度があるはずなのでそれに設定した方がいい。920ISの場合、2272×1704＝3,871,488で、ミドル2がいいところ。

画質については、圧縮率の問題なので、撮影枚数とのトレードオフで決めればいいと思う。920ISの場合、ミドル2,スーパーファインで2GByteのSDカードを使用した場合、約960枚撮影できるので何も問題ない。このときの一枚あたりの容量は2MByte程度となるためハンドリングもしやすい。

Lサイズでしか印刷しないよ

例えばプリンタが300dpiの場合、11.8dot/mm。Lサイズはだいたい127mm×89mmで、1,500×1,051のサイズがあればいい。920ISであれば、ミドル3：1600×1200がいいところ。ただし、トリミングする場合や、プリンタの印刷の解像度が高い場合は、撮影時の解像度を上げてもいい(あげたとしても上で示したもの以上にしてもあまり意味はない)。

最近はメディアの容量も増えているのでLサイズのみの場合も高い解像度で撮影してもいいと思うけどね。

まとめ

  • 解像度はスペックで示されている有効画素数の1/3程度にしよう
  • 画質は撮影枚数とのトレードオフだよ
    • 普通は旅行に行ってどんなに撮りまくっても一日あたり200枚がいいところというのも頭に入れておこう
  • Lサイズでしか印刷しない場合、解像度を下げてもいいかも

Permalink | 記事への反応(1) | 11:20

2008-08-06

■

たのしい、グーグルマップストリートビューめぐり


無さそうなので作ってみた。

やっつけなのは許してくれ

・ホテル編




・有名になった、足がない人


・うんこ、踏んだ！


・お幸せに！


・あらあら



・事件・事故

（↑削除された！）



・もみもみ

↑もみもみの続き。



・パンツ

http://maps.google.co.jp/?ie=UTF8&layer=c&cbll=35.622924,139.603486&panoid=flgkxQRrqicNkymST9uTGQ&cbp=1,266.0764456064946,,1,-40.07972566971828&t=h&ll=35.634279,139.632196&spn=0.046111,0.109005&z=14

・カップル

（↑は削除された！）

（同じ人なのに、↑は残っている）

・あの場所



・こども


・おとな



・おんなのこ

（↑削除！！）


・こんな車


・安い！


・燃える男の。。。。


・UFO？



・謎の。。。。


・こっち、見んな！

（↑モザイクが入りましたね）

・建築中

↑から一コマ進んだだけで、急に高さが



・ここから北へ行くと

・ここから南西に行くと

・ここから南東に行くと



・ここから東へ行くと

・東に行くと、バグる


・道なき道を進む



・鹿


・鳥


・トンネル


・坂



・行き止まり



・海！


・あっちよ！


・入っちゃだめ！

・２３区なのに



ついでに画像を貼り付けできるかと思ったら、

はてなはembed出来ませんでした！

Permalink | 記事への反応(1) | 12:30

2008-07-11

■ズーム倍率と照準距離の関係

http://anond.hatelabo.jp/20080711131347

光学ズームっていうほうの倍率をみようね。

10倍ズームくらいあると、電信柱の上のカラスをそこそこ大きく写せるかな。

これはあまり正しい表現ではない。

レンズのスペックは、口径比と焦点距離で表され、このうちの焦点距離によって撮影対象のフィルム(あるいは撮像素子)上での大きさが決まる。

焦点距離はmmの単位で表され、その数字が大きいほど、撮影対象が大きく写る。ズームレンズの場合、xxmm??yymmといったふうに広角側(視野が広く、対象物が小さく写る)と望遠側(視野が狭く、対象物が大きく写る)の数字が示されている。しかし、撮影対象がどの程度の大きさで写るかは焦点距離とフィルムもしくは撮像素子の大きさによって異なるため、ただ単に焦点距離を示しただけではわかりずらい。このため、各カメラメーカーでは「35mmフィルム換算時の焦点距離」をカタログスペックとして表記している(ここでの35mmはフィルムのサイズを示しており焦点距離とは関係ない)。

では、光学n倍ズームというのは何を表しているかというと、望遠側の焦点距離から広角側の焦点距離を除したもの、先ほどの例で言うとyy/xxの値を「ズーム倍率」とよんでいる。このため、同じ10倍ズームであっても、28mm??280mmのものや、35mm??350mmのものが存在することになる。

ここからは蛇足。

人間の視野はだいたい(35mm換算で)35mmのレンズと同じと言われていて、広角側の焦点距離が35mmとなっているデジカメもおおい。しかし、人間の視野は案外狭くて、風景を撮る場合には35mmでは閉塞感を感じることがある(人間は首振り機構により視野を拡大できるものね)。逆に遠くのものを撮る場合、たとえば運動会でトラックを子供が走っている場合には450mm程度、野鳥を捕る場合600mm程度ないと満足する画を撮ることは難しい。つまり、28mmから、もしくは35mmからの光学10倍程度ではあまり役に立たない。

個人的には、人にデジカメ購入のアドバイスをする場合、望遠側の焦点距離にはあまり拘らず、広角側の焦点距離をチェックし、なるべく28mm以下のものを選択するように勧めている。

Permalink | 記事への反応(0) | 17:22

2008-03-13

■覚えるべき数字を列挙する

ちょ、ブックマ増えてるしw

そんなことしたら兄ちゃん改定しちゃうぞっ！

数
0.251/4
0.301log10 2
0.477log10 3
0.502/4
0.683正規分布において±1σに含まれる確率
0.753/4
0.785π/4
0.954正規分布において±2σに含まれる確率
0.997正規分布において±3σに含まれる確率
1n/n n0 log10 10
1.12標準数R20の1番目 101/20の近似
1.25標準数R10の1番目 101/10の近似 約5/4
1.41√2 一夜一夜
1.60標準数R5の1番目 101/5の近似
1.73√3 人並みに
2.0021 R10の3番目
2.24√5 富士山麓
2.50R5の2番目
2.72自然対数の底 e
312/4
3.14円周率 π
3.15R10の5番目
4.022 12/3 R5の3番目
5.0R10の7番目
612/2
6.3R5の4番目
8.023 R10の9番目
10十進法の底
121ダース
1624 16進数の底
242ダース
3225
363ダース
484ダース
605ダース
6426
726ダース
968ダース
12827
14412ダース
25628
1024210
65536216
1048576220
16777216224
  • log10 15 = log10 (3*10/2) = log10 3 + log10 10 - log10 2 ≒ 0.477 + 1 - 0.301 = 1.176
  • √15 = √(3*5) = √3 * √5 ≒ 1.73 * 2.24 ≒ 3.88
  • 鉄板のよく使われている厚さは標準数R10に近い。
理工
-273.15℃絶対零度 T
6.626e-34Jsプランク定数 h
0.1013MPa大気圧 P0
0.75kW1馬力の近似値 3/4
1.38e-23J/Kボルツマン定数 k
1.40乾燥空気の比熱比 κ ちょっと混ざったらしいｗ
4.19J/cal熱の仕事当量 J 水の比熱に等しい
7.86g/cm3鉄の密度
9.81m/s2重力加速度 g
22.4L/mol標準状態における理想気体の体積 V0
25.4mm/inch1インチの長さ
299792458m/s光速 c
6.022e23mol-1アボガドロ数 NA
  • 100万馬力は大体750MWくらい
  • ペットボトルの水500mlを1200Wで沸かそうと思うと 500mL*(100-20)℃*4.19/1200W=140秒は最低でもかかる
    • 注：実際は効率の問題があるのでもっとかかる。
  • プロパン(C3H8)は分子量44だから、ボンベが1kg軽くなると1000*22.4/44=509Lくらいのガスが出る
付記
  • 理工はついでで適当だ
  • 実はあまり覚えてない
  • 列挙することに意義がない
  • なんだかんだ言って実は工学系である
参考

他。

http://anond.hatelabo.jp/20080313121625

Permalink | 記事への反応(1) | 14:31

2008-03-05

■WEB屋底辺の品格

俺しがないWEB屋なんだけど、とあるWEBアプリケーションを頼まれで作ったときの話。

何でもやるIT土方なので、本当はデザインからシステムまで全部こっちで引き受けたいところなんだけど、発注側（代理店）が最初から勝手に「このイメージでいく」とクライアントに提出してて引っ込みつかなかったらしく、デザインに関しては別のWEB制作業者を入れ込んできた。

早速デザインがイラレであがってきたのだがこれがひどい。

CMYKなのは許すとして、単位が全てmm。しかも整数になってないので手で適当に置いたのがバレバレ。

もしかしてpxに変換すると整数になるのかもしれないと期待してみたが、案の定、もっと酷い状況に。

大きさも配置も小数が混じるので、画面に書き起こしたときに同じ要素でも幅も高さも位置も2-3px程度ばらける破目に。

何べん言っても改善してくれない。

ピクセルとかアンチエイリアスとかすら理解してくれないので「じゃあ書き出すときアンチエイリアスを切ればいいじゃないですか」とか言われるし。れっきとした株式会社が自社のサイトの事業にWEBデザインもやりますとか書いてあるのに。

わかってもらえないようなので、言いがかりと捕らえられない様、丁寧に説明してるんだがそれでも聞く耳を持たない。

最終的には「あなたの言ってることがわからない。そんなに気になるんであればそちらで対応すれば」という一方的な態度に出られた。

仕方なく、もらった「素材」をもとに、全てこちらで作り直した。

それでも先方はしっかり「WEBデザイン」として予算の全額を持っていきやがった。

もちろん、代理店に説明しても理解されなかった。

最初にしっかり納品物の用件定義をしなかった俺を含めて、

WEB屋の底辺ってこんなもの。

Permalink | 記事への反応(0) | 22:20

2007-10-18

■http://anond.hatelabo.jp/20071018024155

ものっそい横だけどカメラの方が断然細いはず。タンポンより細いと思う。子宮内部には数mmオーダのCCDカメラ入れたんじゃないかな。医療器具なので本物と比べるのは，1mと1kgとどっちが大きいですかって言ってるのと同じようなものだと思うよ。

とりあえず何もなくてよかったね。生理痛ひどいの大変だね。よくなりますように。

Permalink | 記事への反応(0) | 16:21

2007-05-22

■http://anond.hatelabo.jp/20070522034339

今時font color=""はなぁと思って書いてみたら妙に長くなってしまった。我ながらなんという資源の無駄。日付を手打ちしてるなら、むしろ日付全体を生成するほうが全然楽だけど、一応この形で足掻いてみた結果。コメント入れまくってるから省けば多少は見やすくなるかもよ。

なお文書内のh1は全て同一フォーマットの日付であることが前提。形式は多少変わってもOKで、右から何文字目が曜日かって部分だけを書き換えれば動くはず。

<html>
<head>
  <title>曜日テスト</title>
  <style type="text/css"><!--
    span.sun{ /* 日曜日 */
      color:  red;
    }
    span.sat{ /* 土曜日 */
      color:  blue;
    }
  --></style>
  <script type="text/javascript"><!--
   // 日付フォーマット中、右から何文字目が曜日か（曜日1文字の場合にしか対応してない）
    var DAY_POSITION_FROM_RIGHT = 2;

    /*
     * <h1>yyyy年mm月dd日（曜）</h1> を
     * <h1>yyyy年mm月dd日<span class="xxx">（曜）</span></h1> に変換する。
     * onloadで実行して塗り替え。
     */
    function colorDay(){
      var targetList = document.getElementsByTagName("h1"); // h1要素のリストを取る
      for(i=0; i<targetList.length; i++){ // h1の数だけぶん回す
       // h1の中身を三枚に下ろす（左側、曜日部分、右側）
        var nodeValue = targetList[i].firstChild.nodeValue; // h1の子であるテキストノードの値（日付）を取る
        var nodeValueLeft = nodeValue.substring(0,nodeValue.length - DAY_POSITION_FROM_RIGHT); // 左側
        var day = nodeValue.charAt(nodeValue.length - DAY_POSITION_FROM_RIGHT); // 曜日
        var nodeValueRight = nodeValue.substring(nodeValue.length - DAY_POSITION_FROM_RIGHT + 1, nodeValue.length); // 右側

        var dayType = ""; // 曜日に付与するクラス名を算出（平日なら空）
        if(day == "日"){
          dayType = "sun";
        }
        else if(day == "土"){
          dayType = "sat";
        }

        var dayObj = document.createElement("span"); // 曜日を入れるspanノードを生成
        dayObj.appendChild(document.createTextNode(day)); // 中身文字列は三枚の真ん中（曜日）
        dayObj.className = dayType; // クラスを付与

        // h1の中身作り直し
        targetList[i].firstChild.nodeValue = nodeValueLeft; // 元々の値を三枚の左側部分のみにする
        targetList[i].appendChild(dayObj); // その後ろに作った曜日のspanを足す
        targetList[i].appendChild(document.createTextNode(nodeValueRight)); // その後ろに三枚の右側を足す
      }
    }
  //--></script>
</head>
<body onload="colorDay();">
  <h1>2007年05月25日（金）</h1>
  <h1>2007年05月26日（土）</h1>
  <h1>2007年05月27日（日）</h1>
  <h1>2007年05月28日（月）</h1>
</body>
</html>

Permalink | 記事への反応(1) | 10:52

■こんな感じかい?

http://anond.hatelabo.jp/20070522023230

<html>
<head>
    <title>Test</title>
    <script>
    dayString = new Array('<font color="#ff0000">日</font>','月','火','水','木','金','<font color="#0000ff">土</font>');
  
    function init() {
        h1s = document.getElementsByTagName("h1");
        for(var i=0; i < h1s.length; i++) {
            var h1 = h1s[i];
            if (h1.innerHTML.match(/([0-9]+)年([0-9]+)月([0-9]+)日/)) { 
                var yy = RegExp.$1;
                var mm = RegExp.$2;
                var dd = RegExp.$3;
                var day = new Date(yy,mm-1,dd).getDay();
                h1.innerHTML = yy+"年"+mm+"月"+dd+"日("+dayString[day]+")";
            }   
        }        
    }     
    </script>
</head>

<body onload="init()">
<h1>2007年05月10日</h1>
<h1>2007年05月18日</h1>
<h1>2007年05月19日</h1>
<h1>2007年05月20日</h1>
</body>

素人なのでよくわからないぜ。

追記: バグっていたので直しました。ごめん。 ＞ http://anond.hatelabo.jp/20070522034339

Permalink | 記事への反応(1) | 03:31

2007-04-26

■増田 URL 時間法ではないか

http://anond.hatelabo.jp/20070426204854

「Permalink | トラックバック(0) | 20:48」のようにあるが、そこから考えると「20070426204854」は「yyyymmddhhmmss」だと考えられる。hh と mm までなら他の日記にも完全に当てはまるからな。ss に関しても、61 から 99 が見付からないのでまあ間違いないと思う。

日記を投稿しまくって秒まで一致させるぐらいは楽勝だと思うがこの場合どうなるのだろう。インクリメントするのかな。もしそうならば、インクリメント先に日記が存在しなくなるまでインクリメントし続ければ、いつかは空き秒に到達するのではないだろうか。これならば分、時間、日、月、年と繰り上がり続ければ、同一日付の中だのどうのという問題は解決できる。その場合、分が繰り上がったら、「Permalink | トラックバック(0) | 20:48」と書かれているのに「20070426204900」になったりするのかな。それともデータベースに投入される投稿時間の分も同時に変更されるのだろうか。

まさか同一秒の日記が存在することを想定できないような頭の悪いはてなではあるまい。

Permalink | 記事への反応(0) | 21:03

2007-04-25

■BMIってのがあるよ

ボディマス指数

体重(kg)÷身長(mm)÷身長(mm)

もしくは

体重(kg)÷身長(cm)÷身長(cm)×10000

20から25くらいがいわゆる「普通」

身長170とすると、70kgくらいまで「標準」

Permalink | 記事への反応(0) | 11:57

<前の25件
ログイン ユーザー登録
ようこそ ゲスト さん