m43的高感还是很杯具# PhotoGear - 摄影器材
k*r
1 楼
e*n
2 楼
这些sony用户造假层出不穷, 成习惯了呵. 先几天刚有个网站拿nex和gh1比, 把gh1拍
的比小dc都不如, iso200就糊的一塌糊涂.用的是啥镜头也不提. 简直是笑话.
那几个图都是这个sony造假的用户在imaging-resource下载, 然后自己后期加料做的"
对比"图. 还能更无耻点嘛?
下面的是我刚在imaging-resource下载后裁的3张. NEX5, GH1, GF1的ISO3200对比
【在 k***r 的大作中提到】
: 要不要入个Nex-3呢
: http://sonyalpharumors.com/wp-content/uploads/2010/05/NEX5-EPL1-GF1-
: GH1.jpg
: http://tinyurl.com/2bzqn5l
的比小dc都不如, iso200就糊的一塌糊涂.用的是啥镜头也不提. 简直是笑话.
那几个图都是这个sony造假的用户在imaging-resource下载, 然后自己后期加料做的"
对比"图. 还能更无耻点嘛?
下面的是我刚在imaging-resource下载后裁的3张. NEX5, GH1, GF1的ISO3200对比
【在 k***r 的大作中提到】
: 要不要入个Nex-3呢
: http://sonyalpharumors.com/wp-content/uploads/2010/05/NEX5-EPL1-GF1-
: GH1.jpg
: http://tinyurl.com/2bzqn5l
e*n
3 楼
更搞笑的是GH1的高感在m43里最牛, 结果it加的料最多, 搞成最杯具的一个了. 造假也
要有点专业态度嘛
要有点专业态度嘛
d*0
4 楼
EP1ISO 200下面暗部噪点很明显，革命鸡不能要求太高。
x*c
5 楼
要是能下载到raw的图就好了。
从来不高感直出jpeg
从来不高感直出jpeg
c*t
6 楼
LR3还不能解NEX的raw吧，master早
【在 x****c 的大作中提到】
: 要是能下载到raw的图就好了。
: 从来不高感直出jpeg
【在 x****c 的大作中提到】
: 要是能下载到raw的图就好了。
: 从来不高感直出jpeg
x*c
7 楼
C大早，前几天camera raw支持nex了，希望lr3补丁也不远.
【在 c*****t 的大作中提到】
: LR3还不能解NEX的raw吧，master早
【在 c*****t 的大作中提到】
: LR3还不能解NEX的raw吧，master早
c*t
8 楼
敢问master除了LR还用啥?
【在 x****c 的大作中提到】
: C大早，前几天camera raw支持nex了，希望lr3补丁也不远.
【在 x****c 的大作中提到】
: C大早，前几天camera raw支持nex了，希望lr3补丁也不远.
x*c
9 楼
cpp，ps。。。
现在主要是lr3了，人像有时间进ps，随拍没时间进cpp
【在 c*****t 的大作中提到】
: 敢问master除了LR还用啥?
现在主要是lr3了，人像有时间进ps，随拍没时间进cpp
【在 c*****t 的大作中提到】
: 敢问master除了LR还用啥?
c*y
10 楼
Master牛X啊，
用C++自己写程序，处理照片啊。
大家来拜啊。。。
【在 x****c 的大作中提到】
: cpp，ps。。。
: 现在主要是lr3了，人像有时间进ps，随拍没时间进cpp
用C++自己写程序，处理照片啊。
大家来拜啊。。。
【在 x****c 的大作中提到】
: cpp，ps。。。
: 现在主要是lr3了，人像有时间进ps，随拍没时间进cpp
x*c
11 楼
这两天是被c++搞晕了。
有没有处理过5维的array，介绍一下经验？
【在 c********y 的大作中提到】
: Master牛X啊，
: 用C++自己写程序，处理照片啊。
: 大家来拜啊。。。
有没有处理过5维的array，介绍一下经验？
【在 c********y 的大作中提到】
: Master牛X啊，
: 用C++自己写程序，处理照片啊。
: 大家来拜啊。。。
c*y
12 楼
维数高，IT应该给你专门的class啊
难不成还要你仔细写不成
【在 x****c 的大作中提到】
: 这两天是被c++搞晕了。
: 有没有处理过5维的array，介绍一下经验？
难不成还要你仔细写不成
【在 x****c 的大作中提到】
: 这两天是被c++搞晕了。
: 有没有处理过5维的array，介绍一下经验？
x*c
13 楼
大公司才有自己的library
小team得自己找一个。。。
【在 c********y 的大作中提到】
: 维数高，IT应该给你专门的class啊
: 难不成还要你仔细写不成
小team得自己找一个。。。
【在 c********y 的大作中提到】
: 维数高，IT应该给你专门的class啊
: 难不成还要你仔细写不成
k*r
14 楼
E-PL1差不多。信号弱，噪声马上就很明显。所以在纠结Nex乐
【在 d*****0 的大作中提到】
: EP1ISO 200下面暗部噪点很明显，革命鸡不能要求太高。
【在 d*****0 的大作中提到】
: EP1ISO 200下面暗部噪点很明显，革命鸡不能要求太高。
c*y
15 楼
那我不知道了，我也是最近才开始学c++的。。。。。
教主熟
【在 x****c 的大作中提到】
: 大公司才有自己的library
: 小team得自己找一个。。。
教主熟
【在 x****c 的大作中提到】
: 大公司才有自己的library
: 小team得自己找一个。。。
x*c
16 楼
倒是找到两free，据说好用的，但compile有问题。错误比较莫名其妙。
【在 c********y 的大作中提到】
: 那我不知道了，我也是最近才开始学c++的。。。。。
: 教主熟
【在 c********y 的大作中提到】
: 那我不知道了，我也是最近才开始学c++的。。。。。
: 教主熟
s*e
17 楼
牛 :))
【在 c********y 的大作中提到】
: 那我不知道了，我也是最近才开始学c++的。。。。。
: 教主熟
【在 c********y 的大作中提到】
: 那我不知道了，我也是最近才开始学c++的。。。。。
: 教主熟
s*e
18 楼
其实真的要小还是小DC比较好
【在 k***r 的大作中提到】
: 要不要入个Nex-3呢
: http://sonyalpharumors.com/wp-content/uploads/2010/05/NEX5-EPL1-GF1-
: GH1.jpg
: http://tinyurl.com/2bzqn5l
【在 k***r 的大作中提到】
: 要不要入个Nex-3呢
: http://sonyalpharumors.com/wp-content/uploads/2010/05/NEX5-EPL1-GF1-
: GH1.jpg
: http://tinyurl.com/2bzqn5l
o*x
19 楼
5维和一般的2维或3维的主要差别在哪儿？有什么特殊要求吗？
【在 x****c 的大作中提到】
: 这两天是被c++搞晕了。
: 有没有处理过5维的array，介绍一下经验？
【在 x****c 的大作中提到】
: 这两天是被c++搞晕了。
: 有没有处理过5维的array，介绍一下经验？
d*0
20 楼
感觉EP1这个sensor宽容度不太行，高感也比sony那个差了1.5档
【在 k***r 的大作中提到】
: E-PL1差不多。信号弱，噪声马上就很明显。所以在纠结Nex乐
【在 k***r 的大作中提到】
: E-PL1差不多。信号弱，噪声马上就很明显。所以在纠结Nex乐
s*e
21 楼
可能要用sparse array?
【在 o*****x 的大作中提到】
: 5维和一般的2维或3维的主要差别在哪儿？有什么特殊要求吗？
【在 o*****x 的大作中提到】
: 5维和一般的2维或3维的主要差别在哪儿？有什么特殊要求吗？
x*c
22 楼
主要考虑速度问题。5维要花费不少cpu在计算索引上。
现在code里用的是native的C的5维定义。
double a[3][3][10][3][6];
在想用其他第三方的会不会快些。另外一个就是dynamic allocation了，这个我还没想
好是不是很必要。
不知道如果不需要dynamic allocation，nataive那种定义是不是就是最快的。
【在 o*****x 的大作中提到】
: 5维和一般的2维或3维的主要差别在哪儿？有什么特殊要求吗？
现在code里用的是native的C的5维定义。
double a[3][3][10][3][6];
在想用其他第三方的会不会快些。另外一个就是dynamic allocation了，这个我还没想
好是不是很必要。
不知道如果不需要dynamic allocation，nataive那种定义是不是就是最快的。
【在 o*****x 的大作中提到】
: 5维和一般的2维或3维的主要差别在哪儿？有什么特殊要求吗？
x*c
23 楼
不需要sparse，是dense的
大概就是300x48x6x5x3的量级。
我自己写的话最多用到3维，尽可能避免更高维数的。要把5维拆开好像也不容易。
【在 s*****e 的大作中提到】
: 可能要用sparse array?
s*e
24 楼
空间固定以后，直接开
double m[300][48][6][5][3]是最快的
【在 x****c 的大作中提到】
:
: 不需要sparse，是dense的
: 大概就是300x48x6x5x3的量级。
: 我自己写的话最多用到3维，尽可能避免更高维数的。要把5维拆开好像也不容易。
double m[300][48][6][5][3]是最快的
【在 x****c 的大作中提到】
:
: 不需要sparse，是dense的
: 大概就是300x48x6x5x3的量级。
: 我自己写的话最多用到3维，尽可能避免更高维数的。要把5维拆开好像也不容易。
x*c
25 楼
嗯，我也是这样想的，看有人测试过三维的，native的定义是最快。
如果不需要dynamic allocation，size给定，好像没法优化了。
有几个4维，5维array是global的，不知道改为dynamic allocated有没有可能改善
speed。
【在 s*****e 的大作中提到】
: 空间固定以后，直接开
: double m[300][48][6][5][3]是最快的
如果不需要dynamic allocation，size给定，好像没法优化了。
有几个4维，5维array是global的，不知道改为dynamic allocated有没有可能改善
speed。
【在 s*****e 的大作中提到】
: 空间固定以后，直接开
: double m[300][48][6][5][3]是最快的
k*r
26 楼
上NEX不？
【在 d*****0 的大作中提到】
: 感觉EP1这个sensor宽容度不太行，高感也比sony那个差了1.5档
【在 d*****0 的大作中提到】
: 感觉EP1这个sensor宽容度不太行，高感也比sony那个差了1.5档
d*0
27 楼
EP1的两个轮子我很喜欢，要不早就出了。Nex操控差了点。
【在 k***r 的大作中提到】
: 上NEX不？
【在 k***r 的大作中提到】
: 上NEX不？
o*x
28 楼
如果是多重for循环顺序操作的话，自己计算索引，尽量减少乘法次数，使用已有乘法
结果对于速度有一定改善，我原来这样用过，不过有些编译器可能本身有这个优化能
力。
如果是随机存取数组的话，如果不能减少索引计算时间，我感觉改为动态分配的应该不
会有多大改善。
【在 x****c 的大作中提到】
: 嗯，我也是这样想的，看有人测试过三维的，native的定义是最快。
: 如果不需要dynamic allocation，size给定，好像没法优化了。
: 有几个4维，5维array是global的，不知道改为dynamic allocated有没有可能改善
: speed。
结果对于速度有一定改善，我原来这样用过，不过有些编译器可能本身有这个优化能
力。
如果是随机存取数组的话，如果不能减少索引计算时间，我感觉改为动态分配的应该不
会有多大改善。
【在 x****c 的大作中提到】
: 嗯，我也是这样想的，看有人测试过三维的，native的定义是最快。
: 如果不需要dynamic allocation，size给定，好像没法优化了。
: 有几个4维，5维array是global的，不知道改为dynamic allocated有没有可能改善
: speed。
k*r
29 楼
E-PL1一个都没有，菜单设计的还比较容易用，所以也对付了。
NEX好歹有一个，应该还方便，550D之类的也只有一个，呵呵。
【在 d*****0 的大作中提到】
: EP1的两个轮子我很喜欢，要不早就出了。Nex操控差了点。
NEX好歹有一个，应该还方便，550D之类的也只有一个，呵呵。
【在 d*****0 的大作中提到】
: EP1的两个轮子我很喜欢，要不早就出了。Nex操控差了点。
s*e
30 楼
不可能，dymamic allocated 只能更慢，绝对不能更快 :))
【在 x****c 的大作中提到】
: 嗯，我也是这样想的，看有人测试过三维的，native的定义是最快。
: 如果不需要dynamic allocation，size给定，好像没法优化了。
: 有几个4维，5维array是global的，不知道改为dynamic allocated有没有可能改善
: speed。
【在 x****c 的大作中提到】
: 嗯，我也是这样想的，看有人测试过三维的，native的定义是最快。
: 如果不需要dynamic allocation，size给定，好像没法优化了。
: 有几个4维，5维array是global的，不知道改为dynamic allocated有没有可能改善
: speed。
s*e
31 楼
其实一次乘法和五次乘法差的不多，因为cpu是pipeline的
何况编译器本身有优化，我看就没有必要费这个劲吃力不讨好了
【在 o*****x 的大作中提到】
: 如果是多重for循环顺序操作的话，自己计算索引，尽量减少乘法次数，使用已有乘法
: 结果对于速度有一定改善，我原来这样用过，不过有些编译器可能本身有这个优化能
: 力。
: 如果是随机存取数组的话，如果不能减少索引计算时间，我感觉改为动态分配的应该不
: 会有多大改善。
何况编译器本身有优化，我看就没有必要费这个劲吃力不讨好了
【在 o*****x 的大作中提到】
: 如果是多重for循环顺序操作的话，自己计算索引，尽量减少乘法次数，使用已有乘法
: 结果对于速度有一定改善，我原来这样用过，不过有些编译器可能本身有这个优化能
: 力。
: 如果是随机存取数组的话，如果不能减少索引计算时间，我感觉改为动态分配的应该不
: 会有多大改善。
相关阅读