引用:

原帖由 kb01 于 2010-9-13 22:31 发表
首先我已经跟你说了，自己不是程序员，学过的东西浅，何况早忘的差不多了
其次，这个算法并不涉及非常困难的程序功能，都是现成控件可以搞定的，算法本身也非常浅显易懂，是面向过程的，还是单线的
你要是连这个都 ...

原来你不知道啊~~~

那问题就来了，既然你不会做一样东西，又凭什么说这个算法很好写呢？

控件？你懂控件究竟是什么吗？

引用:

原帖由 kb01 于 2010-9-13 22:34 发表
我是不怎么懂，你可以告诉我啊，你要实现什么缩放功能，我来试图看看以我的智商能否让你搞定实现过程

既然你不懂，那你凭什么胡说八道呢？？

小声再问句，什么叫线程？你分得清线程和进程的区别吗？
什么叫面向过程？什么叫面向对象？说的明白吗？

引用:

原帖由 kb01 于 2010-9-13 22:34 发表
我是不怎么懂，你可以告诉我啊，你要实现什么缩放功能，我来试图看看以我的智商能否让你搞定实现过程
比如现在在你面前的就是一个1080p的屏幕，你可以点屏幕上的任何一点，以此点为中心做任意倍数的放大（当然不能 ...

那好，我就问个最简单的吧。

比如我在800X600的位置取一点，放大至1024X768的显示范围。
这个算法怎么写？

引用:

原帖由 kb01 于 2010-9-13 22:40 发表
等等，你还没说放大倍数呢

哈哈哈哈哈，朋友，问问题拜托专业点。

基准点已经给你了，需要显示的画面大小也已经给你了。你还要怎么样？
觉得简单就自己把这个算法写出来。
我也可以告诉你大约需要注意那几点。
首先你该如何将基准点告诉电脑，通过C语言，或者二进制数，倘若你很牛叉的话。
其次如何将需要显示的点阵算出来，这个地方需要一点小技巧。不过也不是难到不行。
最后，如何将制定范围的点阵显示你需要显示的信息。这里是个难点。因为每个像素对应了RGB三原色的搭配，难点在于如何获取原图的该点的像素。
以及获取参数之后如何有效率地依次填充至每个点阵。

[ 本帖最后由 QuiGon 于 2010-9-13 22:49 编辑 ]

引用:

原帖由 xphi 于 2010-9-13 22:46 发表
理论上DeepZoom支持的图片大小是没有限制的，因为技术上不需要限制图片树深度。而那个所谓最神奇的图片拼接算法，SilveLight的一个DeepZoom组件就可以做到了。如果有空去看过当时演示的原始演示视频的话，就知道Sony ...

没人觉得PS3是外星科技，是你自己在自娱自乐罢了。

微软的技术一向牛叉，我和你对微软的认知差别在于，我知道微软牛叉在哪儿，而你不知道。

即使这样，一张32亿像素的图片，用微软的技术来处理，效率上也是值得期待的

引用:

原帖由 kb01 于 2010-9-13 22:50 发表

喷了，对啊，你就告诉我一个点的位置，请问一个点象素为1，1024*768象素为差不多80万，本身这图只有1080p的不到一万倍，你tm神仙也放缩不了啊...

呵呵，因为你不懂，你在软件方面是个白痴，所以我不将门槛设太高。

难道你还非得挑战高难度吗？？我就问你一句，你究竟还要不要脸啊？？？

废话少说，点已经给你了，显示的范围也已经给你了，只是一整张图片的一部分而已，难度应该降低很多很多了。
赶紧写算法，少废话！

引用:

原帖由 kb01 于 2010-9-13 22:59 发表
如果你的意思是，在这张1080p的图上800 600的位置放缩出原图的清晰度，那就可以了
首先既然要求原图分辨率，那么图库就清楚了，为最大的（10000张1080p），其次图片中心也清楚了，   易得    x

请看题目要求答题，并且我已经给了你提示，不要想当然！
现在不要求你计算32亿像素的图片采样。我问得再直白点，如何将指定大小范围内的点阵按你的要求输出相应的图像。

同时我希望你回答问题也专业点，必要时候可以直接贴代码。

引用:

原帖由 xphi 于 2010-9-13 23:06 发表
说起来现在哪里还有什么小型机，中型机哦，这种陈古八年的概念现在还真是难得见到。要是现在这些领域还有人在用小中型机，那才真是胡说八道。

我已经说过了，不要用你不懂的东西来作为你辩论的论据，这只会彰显你的无知。
同时我还说过，我对扫盲没兴趣。

若想知道小型机是干嘛的，麻烦上一下google，谢谢

引用:

原帖由 kb01 于 2010-9-13 23:10 发表
我只需要贴出具体流程即可，算法的话任何一个程序员都可以做出来

哈哈哈哈哈哈哈哈，任何一个白痴也都会吃饭睡觉拉屎放屁，倘若这就是你不会写的理由的话~~~~

引用:

原帖由 kb01 于 2010-9-13 23:10 发表
我只需要贴出具体流程即可，算法的话任何一个程序员都可以做出来

我最后再不厌其烦将你的“方案”做一下分析。希望你能看懂。

你的想法的原理在于将一张指定的图片预先分割成若干块，需要调用时再取相邻点阵的几幅图片分割显示。

这个想法存在至少三处致命问题。

1. 如何去有效分割图片，究竟按什么尺寸进行单张图片采样？倘若需要显示的面积刚好大于4张图片，那又该怎么取样图？倘若指定了最终输出的分辨率，那实际上是将输出画面的大小局限在一个范围内，这与真正的无缝拼接是有差别的。
2. 这也是你的想法最致命的一点。无论你怎样划分单张图片，前提都是在一张已知的图片上进行。换句话说，首先需要有一张经过初始化过的图片供你分割。用你听得懂的话来说就是，你首先得将这整张几十个G的图片初始化一遍，在这之后电脑才能获取每一个点阵的具体位置。那么这就等于已近加载过一遍原图，之后的操作只是在原图基础上进行裁剪而已。
3. 这个问题延续了问题2，既然已经将原图初始化，那么再用所谓4图拼一图的做法就有点多余，因为已经获取了所有点阵信息，只需将制定点阵位置告诉计算机即可，还用得着多一步做什么二次裁剪吗？

引用:

原帖由 xphi 于 2010-9-13 23:17 发表
话说你怎么知道我不懂？子非鱼，安知鱼之乐？
说起来，关于计算机的分代问题，我就算要和你讨论也犯不着去查什么Google，你还是省省吧。

呵呵，有点农村婆子掐架的意思了。

只是我实在没兴趣陪你浪费时间~~

引用:

原帖由 kb01 于 2010-9-13 23:31 发表
1，废话，本来就是针对普通显示器的，你要是针对几十亿点对点显示器还有什么花头好搞？
2.当然，我不是说了吗，预处理后做成图库，现实中也是这么做的，你不是说pc做不到吗，我告诉你能做到，就是容量会大不到一倍
...

哦~~~~~~~~~~~弄了半天，你的意思原来是：把一张32亿像素的几十G的原图先让电脑加载一遍，然后再从内存里将这张图片的每一部分分别读取出来。
哈哈哈哈哈哈，那请问你，还搞什么小图分割呢？反正整张图片已经加载过了，你搞小图分割还要浪费性能进行分割，而加载图片的时长根本不变！
还搞什么四图拼接呢？反正整张图片的信息计算机里已经有了。直接取需要的点阵信息不是更直接吗？
最后问一句，既然有这时间将原图整个加载一遍，那还搞什么压缩、缓存、分割、归档啊？？？
总而言之一句话，你干嘛老是多次一举呢？？？

哈哈哈哈哈哈哈哈哈，真他妈傻逼啊！！！！！！！
抱歉，我并非说你人傻逼，我只是说你的这个想法十分傻逼。

我真心希望我的老板以及这世界上所有的老板的想法都能和你一样傻逼，这样的话，我就更好混了。

引用:

原帖由 kb01 于 2010-9-13 23:43 发表

明明是，用一台机器（比如大型机）把这张图做成图库，把这个几十g的图库放到pc硬盘即可

哈哈哈哈哈哈
行了，不用解释你雷人的思维方式了。
我已经明白了。

打个比方说就是，想把魔方的六面玩出来，先得把每一块的个体所能处于的位置先玩一遍。
顺便说一句，魔方总的变化数为43，252，003，274，489，856，000。或者约等于4.3X10^19。如果一秒可以转3下魔方，不计重复，需要转4542亿年，才可以转出魔方所有的变化，这个数字是目前估算宇宙年龄的大约30倍。。。。。。。引自百度百科。

我就再问一句，就算我的老板今天心情很好陪我一天加载完了全部图片，倘若客户变态，一下提供了100多张这样的图片，我该怎么办？？？

引用:

原帖由 kb01 于 2010-9-13 23:55 发表

不好意思，即使按照最细的2倍倍数，缩放128倍（即象素提高到16384倍，对1080p的图就是300多亿象素），也只需要3万多张图

不用玩数字游戏了，想你这种智商也不一定算得清楚。

见好就收吧，给你个台阶下，算我输给你了。

别浪费时间了~

引用:

原帖由 xphi 于 2010-9-14 00:02 发表
32亿像素的图片如果以Jpeg有损方式保存的话，确实没有数十G的大小，但是粗略估计也在数个G的数量级。前面我只是就事论事的谈谈下面这种说法而已。

采用有损压缩，可以有效减小所占容量。
难点在于如何有效地判定哪个点阵采用哪种级别的压缩方式。
这很考验算法。所以我很早就说了视频编码、图像编码和音频编码不是什么人都能做的。

当然有些人认为这一切都很简单，是个程序员就能写。

而我只想说，我对刚才浪费的几小时感到很后悔。