代码之家  ›  专栏  ›  技术社区  ›  moogs

客户端图像处理

  •  32
  • moogs  · 技术社区  · 14 年前

    我们正在构建一个需要大量图像处理的基于Web的应用程序。我们希望这个处理负载尽可能多地在客户机上,并且我们希望尽可能多地支持平台(甚至移动设备)。

    是的,我知道, 一厢情愿

    信息如下:

    1. 图像处理是从一些数据中光栅化的。想象一下从PDF文件创建PNG图像。

    2. 我们没有太多的服务器电源。所以客户端处理是必须的。

    因此,我们正在考虑:

    1. flash——最广泛,但从我所读到的内容来看,它的开发工具比较单调。(目前还不支持iPhone/iPad)。

    2. Silverlight-允许我们使用.NET CLR,所以有一个很大的++(许多代码在.NET中)。但大多数手机都不支持(有传言称未来支持Android)

    3. HTML5+javascript-可能是最“可移植”的选项。问题是必须用javascript重写所有的图像处理代码。

    有什么想法或架构可以帮助你吗? 澄清:我不需要进一步了解哪些库可用于Silverlight和JavaScript。我的两难处境是

    • 选择Silverlight意味着不支持大多数手机
    • 选择flash意味着我们必须重新开发大部分代码,而不支持iphone/ipad。
    • HTML5+javascript我们必须重新开发我们的大部分代码,但还没有在所有浏览器中得到完全支持。
    • 选择两个(Silverlight+Flash)会花费太多

    我可能会错过任何现成的或明智的想法/备选方案?

    14 回复  |  直到 10 年前
        1
  •  28
  •   Craig Schwarze    14 年前

    这就是软件架构师一直面临的问题。像往常一样,没有理想的解决方案。您需要选择哪一种折衷方案最适合您的业务。

    为了总结您的问题,大多数图像处理软件都是用.NET编写的。您希望在移动设备上运行IT客户端,但在移动设备上的.NET渗透性有限。具有更高渗透性(如flash)的替代方案将要求您重新编写代码,而这是您负担不起的。此外,iPhone/iPad不支持这些替代方案。

    理想情况下,您需要的是在大多数现有平台(包括iPhone/iPad)上运行所有.NET代码的方法。我可以自信地说,目前还没有这样的解决方案——没有一个“银弹”的答案是你忽视的。

    那么你需要在什么方面妥协呢?在我看来,即使你重新开发了Flash,你仍然会错过一个主要市场(iPhone)。无论如何,重新开发软件是非常昂贵的。

    这里是解决您的问题的最佳方案——您需要在“客户端执行”约束上妥协。如果您执行服务器端,您就可以保留现有的代码,并且可以部署到几乎所有的移动客户端,包括iPhone。

    你说你的服务器能力是有限的,但是与软件开发成本相比,服务器处理能力是便宜的。实际上,将服务器组件外包并支付使用费用并不是那么昂贵。最有可能的是,您的应用程序只有很低的渗透性才能启动。随着业务的增长,您将能够负担得起升级服务器容量的费用。

    我相信这是解决你问题的最好办法。

        2
  •  7
  •   user73993    14 年前

    在Amazone2c、Azure或Google上托管您的图像处理。IIRC E2C有许多常见的图像处理问题,打包后就可以使用了。

    在将代码作为Web服务共享方面,Azure可能更为熟悉。

    你只需支付CPU周期和传输/存储等费用

        3
  •  4
  •   George Profenza    14 年前

    我相信会有Silverlight和JS用户发布示例。以下是一些用actionscript编写的图像编辑器:

    1. Phoenix
    2. PhotoshopExpress

    有一个 ImageProcessing library 首先。 加上 PixelBender 在flash player 10中可用,速度很快,它在单独的线程中运行 和 people 用它做一些非常疯狂的事情。

    高温高压

        4
  •  4
  •   Rene Schulte    14 年前

    Silverlight部分的一些帮助:

    有一个名为 Thumba . 诺科拉最近打了一个电话 EasyPainter 他还将在future中提供源代码。

    对于图像转换,我建议使用开放源代码库 ImageTools 这也包括一些基本的影响。 Silverlight有一个名为可写位图的位图像素操作类。开放源码库 WriteableBitmapEx 是Silverlight的可写位图的扩展方法集合。可写位图API非常简单,只有原始像素数组可用于此类操作。WriteableBitmapex库尝试用类似于内置方法的易于使用的扩展方法来补偿这一点。 像素遮影器也可以用来制作一些快速和高级的效果。尽管它们受材质球模型2的限制,但材质球可用于快速变蓝、着色等。

        5
  •  3
  •   Joa Ebert Emran    14 年前

    你的问题是 haXe 程序设计语言。HAXE是为Web编写的,可以编译到JavaScript、Flash和Objtovi-C(很可能是Java/.NET)。 因此,您不会选择要投资的平台,而是选择使用哪种语言。haxe很容易被AcitonScript程序员采用。

    当flash可用时,在javascript沙盒中运行图像处理算法是没有意义的,因为它会更快。在iPhone和JavaScript这样的移动设备上运行繁重的图像处理算法也是没有意义的。我只支持将javascript作为最差的回退解决方案。

    如果你不想用哈克斯,我就用闪光灯。如果这是你的问题,你也可以为iPhone部署你的Flash应用程序。这也是非常好的,因为您得到了本机的ARM代码。实际上,有非常好的工具可以用于专业的Flash开发。 FDT IntelliJ IDEA 是其中的两个。最好的haxe ide可能是 FlashDevelop 在写作的时候。

    所以我肯定不会把javascript作为唯一的解决方案。哈克斯是完美的你所要达到的目标。如果您不信任或不想投资于Haxe,您可以使用Flash,因为 iPhone/iPad export .

    根据您的使用案例,我还鼓励您考虑像AmazonEC2和Google Appengine这样的云主机。托管成本很低,扩展对于您的任务来说很容易。当涉及到复杂的操作时,即使在桌面系统上花费很多时间,这种体验也会更好。

        6
  •  3
  •   Taryn user758618    11 年前

    免责声明:我认为自己是Flash平台的拥护者。我钦佩Silverlight作为一种通过浏览器部署几乎所有.NET内容的技术的巨大潜力,但它的渗透性很低,市场营销非常糟糕,尽管许多人(大多数人不知道Flash或Silverlight)都认为它是Flash的竞争对手,就像Flash不是SliverLight的竞争对手一样。我的理想主义者喜欢用HTML+JS标准做任何事情的想法,而不是依赖第三方专有软件。但事实是,JS速度慢,API有限,而且JS、HTML和CSS的实现在浏览器中非常不一致。

    如果你真的想坚持.NET,并且对瞄准iPhone及其兄弟姐妹很感兴趣,那么你可能想看看 MonoTouch .

    不过,尽管这可能会让你吃惊,我还是要告诉你使用flash。:)

    为什么?图像处理位是应用程序的最小部分。不管你在写什么,我都非常肯定。我不知道Silverlight,但是在flash中,“thumba”和“easypainer”使用的过滤器可以在一天内创建,其中大多数只是使用 ConvolutionFilter , ColorMatrixFilter , DisplacementMapFilter BitmapData::paletteMap 或者仅仅通过应用 other filters Flash offers out of the box . 任何额外的东西都可以使用乔治指出的PixelBender来创建。内核语言是C的一个子集,因此移植经典过滤器不应该太费时。阿尔索 alchemy (一个针对FlashPlayer10的LLVM后端)是一个值得研究的选项,尽管它还不太稳定。

    应用程序的最大部分将是大量的图形用户界面设计、图形用户界面实现、业务逻辑等。当涉及到简单而相当快速的图像处理时,Flash确实是很棒的,并且通过flex框架和mxml,您有一个强大的工具来高效地创建应用程序的图形用户界面,它可以与许多服务器进行很好的互操作。几乎适用于任何平台的解决方案。

    另外,flash有一个伟大而活跃的社区,提供大量的教程、代码片段、库和框架,以及一个庞大的生态系统,并提供交叉编译工具,以将flash内容交付给其他平台(包括即将推出的 Flash CS5 或上述elips)。我不明白,在您的印象中,Flash平台缺少开发工具。与.NET套件不同的是,它们由许多供应商提供。即将到来的flash player 10.1已经被乔治指出,但我想强调的是,这使得许多跨平台的考虑都过时了。

    最后,我想指出的是 haXe . 它允许编译到SWF,但也可以使用C++提供的非常相同的API编译。 NME ,为了 target the iPhone . 此外,Android后端系统也在进行中。如果你不打算在未来4-5个月内推出,那么这绝对是一个选择。

        7
  •  2
  •   Paolo    14 年前

    除其他答案外,另一种选择可能是混合解决方案。例如,对大多数目标受众使用flash/silverlight,对不支持flash/silverlight的受众使用服务器端处理(或者您可以为ip[hone ad]创建本机应用程序)

    无论如何,您可能必须这样做,因为您的目标手机可能没有足够的处理能力,这取决于您的图像处理变得多么复杂。

    当然,您仍然可以选择升级您的服务器,尽管您目前已经打折了,但可能是 far cheaper 而不是花费开发时间来创建/部署/测试客户端解决方案。

        8
  •  2
  •   NotDan    14 年前

    您可以对所有启用了Silverlight的客户端使用Silverlight,对于非Silverlight客户端,请执行图像处理服务器端操作。由于Silverlight代码是C,您可以对其进行双重编译,以使(大部分)相同的代码与Silverlight和非Silverlight(即服务器)工作。这让你两全其美。

        9
  •  1
  •   Darius Bacon    14 年前

    你不会说你要重写的“所有代码”是用什么语言写的。半自动翻译成javascript是否可行?

    也许你可以像Craigs建议的那样从服务器端开始,然后随着时间的推移将函数移动到客户机中,而不是一次重写所有的函数。

        10
  •  1
  •   Gabriele Petrioli    13 年前

    你检查过吗 editor 属于 Pixlr.com ?
    看看他们的 API 也。。

        11
  •  0
  •   Andreas Bonini    14 年前

    最好的解决方案是使用Silverlight(这样您就已经准备好了代码)。如果客户机不能运行它(移动电话等),那么在服务器端处理它。

    这是最好的妥协。

        12
  •  0
  •   Rus    14 年前

    取决于图像处理的类型和最终用户体验。

    当你在寻找目标手机时,你的图像处理需要考虑到用户或接收者拥有的手机类型(如果通过短信/彩信发送信息),因为不同的手机有不同的分辨率屏幕,并处理主图像和缩略图的不同图像格式。

    我建议您考虑一个混合云架构,正如今年微软PDC主题演讲中提到的那样。这将使您能够拥有自己的服务器来支持您的应用程序,但是如果您由于使用AppFabric扩展到云端而需要额外的容量。

    此外,为了最大限度地提高产品的市场可用性,将图像处理拉到一个通用的可重复使用的基础设施,允许您针对不同的平台,利用每个平台的优点。

    我研究过一个解决方案,它在服务器端托管了图像处理和交付基础设施,然后构建了不同的用户界面产品,允许通过台式机、MNO和AppStores进行销售。它可以工作,从商业的角度来看,可以提供规模效益。

        13
  •  0
  •   Forrest    14 年前

    为什么不提到Java applet?

    好的一面是:

    几乎所有浏览器支持? 需要安装JRE? 全OS支持 Java提供Java高级图像工具包,但是如果调用C++ DLL,那是最好的(JNI可以调用C++ DLL)

        14
  •  -1
  •   Gabe    14 年前

    在我看来,没有一个解决方案能满足你的所有需求。你最好的选择,IMO,是使用Flash,并希望Adobe与苹果达成协议,在iPhone/iPad上使用Flash。当然,最大的缺点是你必须重写你的大部分代码。

    如果移动扇区不是绝对关键的,那么出于前面提到的原因选择Silverlight选项。您也可以在浏览器外模式下使用Silverlight作为桌面应用程序。

    推荐文章