If speed is important, Don t.

如同你一样,它试图利用业务处的技术或类似技术,将钢材的类型推向或抽象。 这会增加每个食堂的间接接触,从而杀害你的表现。

If you re calling staight to a function vs. a pointer to one (e.g., delegate, overriden method, functor) it can still be faster for the CPU, but if you re doing function calls at all reconsider; they re still extra work and if you can nest everything in the outer FOR loop, it will look ugly and functional programming snobs will sneer at you, remember, this isn t a big LOB app that will get hard to maintain. That s why engineers can still perfectly maintain 30 year old quickbasic code, the problem space doesn t need anything smarter (however usually their problems themselves need something a lot smarter than I!)

如果你想要加快速度,最好能为每一种形象优化简单的东西(如门槛值或再版)。 您还可以研究transformationmap,看看你能否完成你的工作。 这样,你就可以只写2个变算法(b&w),并且,如果使用类似的(或相同)矩阵,这两种情况都是一样的。

因此,实现了一条重要目标,即:任何途径的抽象、无缝的再利用、关切的分离。 加快boot(但希望不会再boot!) good

管道的铺设可与频道独立运行的算法进行良好运作;并非所有渠道都这样做,因此将受到很大限制。 你们还花了一点时间和空间,使所有这些复印件都成为可能。

我假定,你指的是在算法职能之外制造模版,其子类为模板参数。 这也可以奏效,但这意味着界定你的基本子母体业务,使之可以作为功能或操作者,在通用的纸浆类型上实施。 这比它所想象的要困难,而且应当在你掌握实施算法的一些经验之后进行。

A third option not mentioned is to promote the b/w images to full color, process them, and convert back to b/w. This optimizes the full color processing at the expense of the b/w.

For most algorithms it is not necessary to worry about monochrome vs. colour images. You either use the grey value of the monochrome image or you calculate the luminance/intensity/whatever of the colour and use that. You choose the measure luminance etc. by looking at which colour space will give you the result you want.

如果你计算了你将如何改变你的图像,你将使用一些有素的加固处理方法,例如,将两个皮尔斯混为pixel_a*0.5 + pixel_b*0.5,那么,你的六氯类将如何适用于不同的彩色渠道,即Pixel:operator+(consterator+) Pixel &),Pixel:operator*(float)等。

每种彩色频道都分别采用一些算法,但这些算法并不常见,而且往往在颜色的时段变化之间有某种关联,因此,你会做一些基本的事情,因为每个渠道完全独立。

我自己的图像类别使用一个平面结构(即,彩色渠道是分开的),而不是一个相互隔绝的结构。 但是,在图像配置和其他联合彩色加工任务方面,这种限制是独角兽器。

我正计划改写,以使用另一种方法,简单地说,它是一种两块元素。 此时,我无法确定我如何具体执行这一计划(模仿六等、六等基类或简单三维阵列)。

我还计划为这一相互隔绝的图像结构撰写一个包裹,以减轻我可能遇到的任何不利情况。 一件事是肯定的,这张画面的效率将大大高于对纸张图像的粉碎片。

Frankly 我认为,分散计划的效率相当低,因为你几次计算各种间接费用。 例如,如果你想要重新塑造形象,那么各种过滤系数的计算成本非常昂贵,因此,如果采用Pixel:operator * 和 + 而不是与基本子化元素相同的系数,那么,MUCH就能够更好地计算一次。