Существующие web-решения по обработке изображений (RAW, фильтры, JPEG)?

Не за что.

Существующие web-решения по обработке изображений (RAW, фильтры, JPEG)?

Нет, я бы таким сервисом не пользовался. Мне не нужно выкладывать RAW'ы в сеть.

Существующие web-решения по обработке изображений (RAW, фильтры, JPEG)?

Я про фильтры и цветовую корекцию. Это можно увидеть и на 100х100. Фотографии я не проявлял. Чукча не фотограф, чукча писатель :)

А вы попробуйте. Иначе понять, что нужно пользователям крайне проблематично. В том числе откройте какую-нибудь программу для проявки изображений, схлопните окно до 100х100 и попробуйте понять, что дают фильтры. Само впечатление от картинки зависит от её размера.
Кстати, фильтры не всегда применяются ко всему изображению:
www.darktable.org/2012/07/some-enhancements-to-conditional-blending/
А еще можно фильтрами получить на какой-то мелкой детали очень вырвиглазный цвет. На превьюшке он смешается с соседними пикселами и будет незаметен, а при печати вылезет.

Согласитесь, там не важна целая картинка. Интересен регион либо светлого фона, либо переход некий.

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

И потом, 2-5 параметров — это архи мало для продвинутого шумоподавления. Скорее 20-40.

20-40 может быть внутри, но человек не справится с их установкой. В интерфейсе более 2-5 параметров сделают его малопригодным для использования.

чистого алгоритма (того что вы прочтете на википедии) в камерах среднеценового ряда никогда не будет (ключевые слова — это performance, bandwidth).

Возможно. Но производителям проще делать одинаковые алгоритмы во всех фотоаппаратах. Есть PowerShot A1300 за 2K рублей и EOS-1D Mark IV. за 140k рублей. У них одинаковые процессоры digic4, только у 1D их два. Алгоритмы там зашиты хардварные, чтобы быстро работали. В младших моделях многие фичи отключены.

Существующие web-решения по обработке изображений (RAW, фильтры, JPEG)?

Ну я просто интересуюсь, как такое можно сделать.

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

Но ведь есть сервисы куда пользователи уже льют свои RAW.

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

Что касается мегабайт — зачем пользователю отсылать каждое изображение во всей его «красе» — thumbnail'а вполне будет достаточно.

У меня разрешение экрана всего в два раза меньше, чем разрешение фотографии. Это все равно мегабайты. Кроме того, любой scroll или zoom будет инициировать загрузку.

Что касается больших вычислений — а если, скажем, возложить это на cloud computing?

Ключевое слово — latency. Вычислений не очень много, компьютер с ними справляется за несколько секунд, но их надо сделать как можно быстрее. Затраты на передачу данных все съедят.

Регэксп для проверки на регэксп

Нет. Например строка "[" или строка "(" не являются регулярными выражениями т.к. в них не сбалансированы скобки.

Можно ли обойтись без виртуального наследования?

Согласен. Спасибо.

Можно ли обойтись без виртуального наследования?

Теперь интерфейсы превратились в шаблонные классы. Как привести указатель к этому базовому классу, чтобы куда-то передать?

Можно ли обойтись без виртуального наследования?

Отдавать const и не const объект. Методы, соответсвенно, тоже пометить как const и не const.
А статистические мотоды лучше попробовать навесить агрегацией, а не наследованием. Т.е. сделать класс, который хранит ссылку на dataset и считает статистику. Это более слабая связь, что хорошо.

Можно ли обойтись без виртуального наследования?

Зачем убирать virtual, если у них действительно общая база?

Фильтрация в GET в RESTful

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

Фильтрация в GET в RESTful

Просто у маркета API ни разу не REST. И причин на это можерт быть много. Иногда это требования совместимости с используемыми версиями софта/браузерами/ОС мобильных телефонов. Например, пару лет назад отправить DELETE или PUT запрос иногда было просто невозможно. Иногда это инертность разработчиков, иногда особенности предметной области.
Если хотите пример REST API, то можете посмотреть на то, что предлагают Яндекс.Фотки. Оно сделано на основе atom.

Фильтрация в GET в RESTful

Мы не знаем какие именно обновились, надо каждый день все выкачивать, а там их не одна тысяча.

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

Фильтрация в GET в RESTful

Наоборот, за счет отсутствие состояния общение между клиентом и сервером становится прозрачным и его семантика понятна любому промежуточному звену (layered system). Это и позволяет организовать кеширование. Также отсутсвие состояния позволяет создавать высоконадежные и высокопроизводительные системы.
Вот когда появляется состояние, возникает куча технических проблем и плясок с бубнами.

Фильтрация в GET в RESTful

Это так скажем спецификация/рекомендация ну или что-то типо того от мужика, который все это двигает.

А я всегда думал, что это другой мужик стоит за REST: en.wikipedia.org/wiki/Roy_Fielding
Что это он в 2000 году написал докторскую диссертацию:
www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Если хочется понять, что такое REST и что в нем ГЛАВНОЕ, надо читать её. Там объяснено почему надо делать так или иначе, какие цели достигаются какими приемами. А то, что по приведенной вами ссылке краткое изложение основных практических положений REST и некоторое количество отсебятины касающейся практической стороны, но не касающейся REST. В том числе REST не требует использования HTTP, человеко-понятных-URL, использования путиЮ а не аргументов для идентификации объектов, JSON, XML. И он целиком опирается на гиперссылки между ресурсами, а не " While services are still useful without them". А касательно «Create Fine-Grained Resources» в диссертации Филдинг наоборот пишет, что HTTP разрабатывался в первую очередь для пересылки большие документов.

Разбивать на несколько запросов не всегда круто, особенно когда id — какой-нибудь хеш и у вас вообще их штук 50 вмещается в url, а POST позволил бы более адекватные объемы получить.

Я понимаю. Но я бы рассматривал это как последний вариант, который стоит использовать, если не найдется другого более красивого решения.

есть огромная разница между последовательными и параллельными запросами.

Используйте SPDY, он будет через один сокет гнать несколько HTTP соединений. Кстати, откуда в RPC вы возьмете параллельные запросы через одно содениение? Или речь не о HTTP RPC?

Фильтрация в GET в RESTful

Так сделайте тогда объект-коллекцию «модели обновленные после XXX». В каждом элементе возвращаемого списка не забудте прописать URL модели, чтобы их можно было положить куда следует. Если они обновляются раз в 1-2 дня, да еще не все сразу, то каждый такой список будет небольшим и ничего страшного в том, что там если лишние модели не будет. Зато будет предельно простой интерфейс.

Фильтрация в GET в RESTful

REST API не должно отдавать ответы из кэша, кэшировать должен клиент.

Нет, кеширование доспускается на любом уровне, в том числе промежуточным proxy сервером, о существовании котороно не знает ни клиент, ни сервер. Это фишка, позволяющая снизить связность и уменьшить задержки. Чтобы кеширование правильно работало в стандарте HTTP описана семантика HTTP методов и заголовки управления кешированием.

REST API может только выдавать заголовки, содержащии рекомендации к кэшированию.

А еще клиент может выставлять заголовки типа If-Modified-Since, чтобы не непегружать канал, если данные не обновились.

Фильтрация в GET в RESTful

Одно на все команды.

Ну и в REST оно одно. У HTTP 1.1 есть специальный режим, когда после выполнения запроса соединение используется для последующих запросов.

Да, пожалуй, на днях 3-4 вечера изучал rest принципы и видимо проглядел, где там описывается групповое создание ресурса, а может и нет этого в спецификации.

У REST вообще нет спецификации. Можете определить PUT в коллекцию объектов коллекции объектов как замещение уже существующих объектов и создание новых. Так, как работает операция update у dict'а в Python. Это будет соответствовать семантике PUT и позволит массово создавать и модифицировать объекты.

Фильтрация в GET в RESTful

А в RPC соединение открывать не надо?

Файловый накопитель с одновременным доступом через LAN и USB?

Ну у меня вот ситуация обратная. Я понял, что софт toshiba smart TV писали очень странные люди, а интерфейс проектировали садисты, поэтому я ищу такую коробочку, чтобы выкинуть польт от телевизора. Ну не устраивает меня включение и переключение между каналами (спутник через DLNA) в полминуты, требующее использования ноутбука.

Пока дороговато получаются подходящие коробочки.

Файловый накопитель с одновременным доступом через LAN и USB?

Кстати, любопытно, может можно сделать FAT-SMB преобразователь, хотя бы на Read-only, что таки позволило бы решить эту задачу?

FAT — это файловая система. Она хранится на носителе. Жесткие диски/фшешки — очень медленные устройства. Поэтому нельзя за каждым байтом туда каждый раз лазить — это долго. Компьютер (в вашем случае телевизор), зная, что это ЕГО диск и никто кроме него писать туда не может, кеширует данные с диска в памяти. Если содержимое диска начнет меняться, пойдут странные и непредсказуемые глюки. Т.е. пока идет чтение данных телевизором, их нельзя менять.

Теоретически, можно сделать железяку, работающую в таких ограничениях. Но это будет не самое удобное устройство. Вывод: smart tv — не достаточно умны. Нужно использовать внешний проигрыватель файлов, а телевизор просто должен работать как экран.