Подтвердить что ты не робот

Обработка изображений на стороне клиента

Мы создаем веб-приложение, которое требует интенсивной обработки изображений. Мы хотели бы, чтобы эта обработка была максимально возможной на клиенте, и мы хотели бы как можно больше поддерживать как можно больше платформ (даже мобильных телефонов).

Да, я знаю, желаемое за действительное

Здесь информация:

  • Обработка изображений - это растеризация из некоторых данных. Подумайте, как создать PNG-изображение из файла PDF.

  • У нас нет большой мощности сервера. Таким образом, обработка на стороне клиента является немного обязательной.

Итак, мы рассматриваем:

  • Flash - наиболее распространенный, но из того, что я прочитал, имеются тусклые инструменты для разработки. (и без поддержки iPhone/iPad).

  • Silverlight - позволяет нам использовать .NET CLR, поэтому большой ++ (много кода в .NET). Но не поддерживается для большинства мобильных телефонов (по слухам, поддержка андроида в будущем)

  • HTML5 + Javascript - возможно, самый "портативный" вариант. Проблема заключается в том, чтобы переписать весь код обработки изображений в Javascript.

Любые мысли или архитектуры, которые могут помочь? Уточнение: мне не нужны дальнейшие идеи о том, какие библиотеки доступны для Silverlight и Javascript. Моя дилемма

  • выбор Silverlight означает отсутствие поддержки большинства мобильных телефонов.
  • выбор Flash означает, что мы должны перепрофилировать большую часть нашего кода, а поддержка iPhone/iPad не поддерживается.
  • HTML5 + Javascript нам нужно переделать большую часть нашего кода и не полностью поддерживаться во всех браузерах
  • выбор двух (Silverlight + Flash) будет слишком дорогостоящим

Любые готовые или яркие идеи/альтернативы, которые могут отсутствовать?

4b9b3361

Ответ 1

Это проблема, с которой постоянно сталкиваются разработчики программного обеспечения. Как обычно, идеального решения не существует. Вам нужно выбрать, какой компромисс является наиболее приемлемым для вашей компании.

Чтобы обобщить вашу проблему, большая часть вашего программного обеспечения для обработки изображений написана на .NET. Вы хотите запустить его на стороне клиента на мобильных устройствах, но на мобильных телефонах есть ограниченное проникновение .NET. Альтернативы с более высоким уровнем проникновения (например, Flash) потребуют повторного написания кода, который вы не можете себе позволить. Кроме того, эти альтернативы не поддерживаются на iPhone/iPad.

В идеале вы хотите запустить весь свой код .NET на большинстве существующих платформ, включая iPhone/iPad. Я могу с уверенностью сказать, что такого решения в настоящее время не существует - нет ответа "серебряной пули", который вы упустили.

Итак, что вам нужно, чтобы идти на компромисс? Мне кажется, что даже если вы обновляетесь во Flash, вы все равно пропустите крупный рынок (iPhone). И в любом случае перепрограммирование программного обеспечения чрезвычайно дорого.

Вот лучшее решение вашей проблемы - вам нужно скомпрометировать свое ограничение на выполнение на стороне клиента. Если вы выполняете серверную часть, вы получаете свой существующий код, а также можете развертывать практически все мобильные клиенты, включая iPhone.

Вы сказали, что мощность вашего сервера ограничена, но мощность обработки сервера дешева по сравнению с затратами на разработку программного обеспечения. Действительно, не все так дорого переносить ваш серверный компонент и просто платить за то, что вы используете. Скорее всего, ваше приложение будет иметь только низкое проникновение, чтобы начать с него. По мере роста бизнеса вы сможете позволить себе увеличить емкость своего сервера.

Я считаю, что это лучшее решение вашей проблемы.

Ответ 2

Обеспечьте обработку изображений на Amazon E2C, Azure или Google. IIRC E2C имеет множество распространенных проблем обработки изображений, упакованных и готовых к работе.

Azure, вероятно, более знакомая почва с точки зрения совместного использования кода в качестве веб-сервиса

Вы платите только за циклы CPU и передачи/хранения и т.д.

Ответ 3

Я уверен, что пользователи Silverlight и JS будут публиковать примеры. Вот несколько графических редакторов, написанных в actionscript:

Для начала существует библиотека ImageProcessing. Плюс PixelBender доступен в Flash Player 10, он быстро, он работает в отдельном потоке и люди делают с ними довольно сумасшедшие вещи.

НТН

Ответ 4

Некоторая помощь для части Silverlight:

Имеется редактор изображений Silverlight под названием Thumba. Недавно Nokola сделал один из них, названный EasyPainter, и он также предоставит исходный код в форме.

Для преобразования изображения я рекомендовал бы библиотеку с открытым исходным кодом ImageTools, которая также включает в себя некоторые базовые эффекты. Silverlight имеет класс для манипулирования пикселями растровых изображений, называемых WriteableBitmap. Библиотека с открытым исходным кодом WriteableBitmapEx представляет собой набор методов расширения для Silverlight WriteableBitmap. API WriteableBitmap очень минимален, и для таких операций имеется только массив пикселей Pixels. Библиотека WriteableBitmapEx пытается компенсировать это с помощью методов расширения, которые просты в использовании, как встроенные методы. Pixel Shaders также могут использоваться для создания быстрых и расширенных эффектов. Хотя они ограничены шейдерами Shader Model 2, их можно использовать для быстрого смазывания, тонирования и т.д.

Ответ 5

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я считаю себя сторонником платформы Flash. Я восхищаюсь огромным потенциалом Silverlights как технологии для развертывания практически любого .NET-контента через браузер, но у него низкий уровень проникновения, он ужасно продается и, хотя и воспринимается многими как таковой (в основном люди, которые не знают ни Flash, ни Silverlight) не является конкурентом Flash, так как Flash не является конкурентом Sliverlight. Идеалист во мне любит идею делать все в HTML + JS, используя стандарт, вместо того, чтобы полагаться на стороннее программное обеспечение. Но правда в том, что JS медленный, а API ограничен, а реализации JS, HTML и CSS ужасно непоследовательны по сравнению с браузерами.

Если вы действительно хотите придерживаться .NET и так заинтересованы в таргетинге на iPhone и его братьев и сестер, тогда вы можете посмотреть MonoTouch.

Тем не менее, хотя это может вас удивить, я расскажу вам об использовании Flash.:)

Почему? Бит обработки изображений - это наименьшая часть вашего приложения. Независимо от того, что вы пишете, я очень уверен в этом. Я не знаю о Silverlight, но во Flash фильтры, используемые "Thumba" и "EasyPainter", могут быть созданы в течение дня, большинство из них просто используют ConvolutionFilter, ColorMatrixFilter, DisplacementMapFilter и BitmapData:: paletteMap или даже просто применив один из другие фильтры Flash-предложения из коробки. Любые дополнительные вещи могут быть созданы с использованием PixelBender, на что указал Джордж. Язык ядра - это подмножество C, поэтому перенос классических фильтров не должен быть слишком трудоемким. Кроме того, alchemy (бэкэнд LLVM, ориентированный на Flash Player 10), можно было бы изучить, хотя он еще не очень стабилен.

В самой большой части вашего приложения будет много графического интерфейса, реализация графического интерфейса, бизнес-логики и т.д. Flash действительно отличная, когда дело доходит до простой, но достаточно быстрой обработки изображений, а с фреймворком Flex и MXML у вас есть мощный инструмент для продуктивного создания графического интерфейса вашего приложения, которое может очень хорошо взаимодействовать с множеством серверных решений практически для любой платформы.

Кроме того, Flash имеет отличное и активное сообщество, предлагающее множество обучающих программ, фрагментов кода, библиотек и фреймворков и большую экосистему с инструментами кросс-компиляции для доставки флэш-контента на другие платформы (в том числе предстоящий Flash CS5 или упомянутые Elips). Я не понимаю, где у вас сложилось впечатление, что на платформе Flash отсутствуют инструменты для разработки. Разница с пакетом .NET заключается в том, что они предоставляются множеством поставщиков. Предстоящий Flash Player 10.1 уже указывал Джордж, но, тем не менее, я хотел подчеркнуть, что это делает многие из перекрестных аргументов устаревшими.

И последнее, но не менее важное: я хотел бы указать haXe. Он позволяет компилировать SWF, но также и на С++, используя тот же API, который предоставляется NME, до предназначено для iPhone. Кроме того, в настоящее время ведется работа над андроидным бэкэнд. Если вы не играете в течение следующих 4-5 месяцев, то это определенно вариант.

Ответ 6

Ваша проблема - идеальная цель для языка программирования haXe. haXe написано для Интернета и может компилироваться в JavaScript, Flash и Objective-C (возможно, скоро в Java/.NET). Поэтому вы не выбираете, на какую платформу вы собираетесь инвестировать, но на каком языке. haXe легко адаптируется для программиста AcitonScript.

Нет смысла запускать ваши алгоритмы обработки изображений в изолированной программной среде JavaScript, когда Flash доступен, потому что он будет намного быстрее. Также нет смысла запускать алгоритмы обработки больших изображений на мобильном устройстве, таком как iPhone с JavaScript. Я бы только поддерживал JavaScript как худшее решение для резервного копирования.

Если вам не нравится использовать haXe, я бы пошел с Flash. Вы можете развернуть приложение Flash для iPhone, если это ваша проблема. Это также очень удобно, потому что вы получаете собственный код ARM. Есть действительно отличные инструменты для профессиональной разработки Flash. FDT и IntelliJ IDEA - два из них, Лучшая haXe IDE, вероятно, FlashDevelop на момент написания.

Поэтому я бы определенно не использовал JavaScript как единственное решение. haXe идеально подходит для того, чего вы пытаетесь достичь. Если вы не доверяете или не хотите инвестировать в haXe, вы можете использовать Flash из-за экспорта iPhone/iPad.

В зависимости от вашей учетной записи я бы также рекомендовал вам взглянуть на облачный хостинг, например Amazon EC2 и Google AppEngine. Стоимость хостинга дешевле, и масштабирование будет легко для вашей задачи. Опыт будет намного лучше, когда дело доходит до сложных операций, которые могут занять даже много времени на настольной системе.

Ответ 7

В дополнение к другим ответам, другой вариант может быть гибридным решением. Например, используйте Flash/Silverlight для большей части целевой аудитории и используйте серверную обработку для тех, кто ее не поддерживает (или вы можете создать собственное приложение для iP [hone | ad])

Возможно, вам придется делать что-то подобное в любом случае, поскольку мобильные телефоны, на которые вы нацеливаетесь, могут иметь недостаточную вычислительную мощность, в зависимости от сложности вашей обработки изображений.

Конечно, у вас все еще есть возможность обновить ваш сервер, который, хотя вы в настоящее время дисконтированы, вероятно, намного дешевле, чем расходы на разработку время создания/развертывания/тестирования клиентского решения.

Ответ 8

Вы можете использовать Silverlight для всех клиентов с поддержкой Silverlight и для клиентов, не являющихся клиентами Silverlight, на стороне сервера обработки изображений. Поскольку код Silverlight является С#, вы можете скомпилировать его, чтобы сделать (в основном) тот же код, что и Silverlight и не-Silverlight (то есть сервер). Это дает вам лучшее из обоих миров.

Ответ 9

Вы не говорите, на каком языке "весь этот код" вам придется переписывать. Можете ли использовать полуавтоматический перевод в Javascript?

Возможно, вы могли бы начать с сервера, как предлагает CraigS, а затем переместить функции в клиент со временем, а не переписывать все сразу.

Ответ 10

Вы проверили editor Pixlr.com?
Посмотрите на их API, а также.

Ответ 11

Лучшее решение - использовать silverlight (так что у вас уже есть готовый код). Если клиент не может запустить его (мобильные телефоны и т.д.), Тогда обработайте его на стороне сервера.

Это лучший компромисс.

Ответ 12

В зависимости от типа обработки изображений и опыта конечного пользователя, на который вы нацеливаетесь.

Поскольку вы хотите настроить таргетинг на мобильные телефоны, ваша обработка изображений должна учитывать тип телефона, который пользователь или получатель имеет (при обмене сообщениями через SMS/MMS), поскольку разные телефоны имеют разные экраны разрешения и обрабатывают разные изображения форматы для основных изображений и миниатюр.

Я бы предположил, что вы рассматриваете гибридную облачную архитектуру, о которой упоминалось в основных выпусках Microsoft PDC в этом году. Это позволит вам иметь собственный сервер для поддержки вашего приложения, но если вам требуется дополнительная емкость, потому что вы масштабируетесь в облаке с помощью AppFabric.

Кроме того, чтобы максимизировать доступность на рынке вашего продукта, вытягивая обработку изображений в общую многоразовую инфраструктуру, вы можете ориентироваться на разных платформах, используя в каждом случае положительные значения.

Я работал над решением, на котором размещалась его серверная часть обработки изображений и доставки, и затем создала различные предложения пользовательского интерфейса, позволяющие осуществлять продажи через рабочие столы, MNO и AppStores. Он может работать и с точки зрения бизнеса может предлагать преимущества эффекта масштаба.

Ответ 13

Почему бы не назвать Java-апплет?

Хорошие стороны:

почти вся поддержка браузера? нужно установить JRE? поддержка всех ОС Java предоставляет Java Advanced Image комплекты, но если С++ dll можно назвать, это лучше (JNI может вызывать dll С++)

Ответ 14

Как я его вижу, нет ни одного решения, которое бы отвечало всем вашим потребностям. Ваш лучший вариант, imo, - это пойти с Flash и надеяться, что Adobe установит соглашение с Apple, чтобы получить Flash на iPhone/iPad. Главным недостатком, конечно, является то, что вам придется переписать большую часть вашего кода.

Если мобильный сектор не является абсолютно критическим, выберите вариант Silverlight по указанным вами причинам. Вы также можете использовать Silverlight в режиме вне браузера для работы в качестве настольного приложения.