Учитывая, что на сегодняшний день большинство алгоритмов secure hash находятся на грани балланса между «есть вскрытие» и «ещё не нет», видимо не совсем «абсолютно не трудно».
А Sony с PS не самый удачный пример, учитывая ограничения на запуск кода. Если конечно Вы не являетесь сторонником введения подобных ограничений в Win.
Дело не «в жлобятся». Причин много, но вот две основные:
1. Аутентичность контента.
Если файл ABC можно скачать с 1000 источников, трудно гнарантировать его подлинность.
2. Ассоциация «P2P = пиратсво».
Многие страны до сих пор пытаются запретить P2P технологии как таковые, Microsoft явно не будет рада ввязаться в подобные разборки.
Кстати, у немалая часть P2P систем имеет корни в разработках Microsoft Research.
Как-то слишком уж хорошо всё это звучит. :)
Надеюсь в скором времени будет возможность пошупать всё это и у нас.
Кто бы ещё ответил на насколько вопросов:
1. Когда же наконец появится в России.
2. Что именно из телефонов под WP7 появится у нас и (весьма немеловажно) почем.
3. Планируется ли для WP7 (Marketplace) оплата со счёта телефона. Опять-таки «у нас».
P.S: Пока прилип к Android, но телефон на WP7 возьму, когда появится, дабы составить своё мнение. А там уже посмотрим.
Простейший вариант — один базовый компонент ® и разница между ним м двумя другими (R-G, R-B).
Фильтр применяется либо только к базовому компоненту, либо до дельты.
Alpha обычно хранится как-есть.
Делать такое кодирование неопциональным смысла нет, т.к. выигрыш будет не на всех изображениях.
Можно попробовать ещё scale-delta. Он даёт более стабильный выигрыш.
Кроме того, есть попиксельные варианты Paeth, учитывающие многоканальность цвета.
1. Это зависит от реализации. Смысл в том, что сейчас можно сделать один тупой регион на всю картинку, а позже можно сделать более умную реализацию не меняя алгоритм распаковки.
2. Поканальная дельта
3. Ну, если битовая карта не растратна…
4. Поток коррекции
1. Регионы — это идеал )
2. Могу посоветовать подумать над разделением/дифференциальным кодированием каналов.
3. «Цепочки одинаковых символов» != «повторяющиеся фразы». Кстати, шаг 6 с битовой картой выглядит весьма растратным.
4. На практике — бОльшая часть изображений уже с квантованием. А это уже можно использовать и в lossless режиме.
5. Можно взять «Kodak Lossless True Color Image Suite», кстати регионы для фильтров дают очень неплохой результат на «самолёте» и «африканке».
1. Разделение по каналам — гуд. А выключение предусмотрено? Если нет, то не надо делать «по строкам», как в PNG, лучше ух сразу делать для регионов (для начала — прямоугольных).
2. Тут вопрос не столько в практическом применении, сколько в универсальности алгоритма.
3. Часть LZMA это словарное (LZ) сжатие, я о том, что смыст в применении его после BWT как-то неочевиден.
4. Именно.
5. Для тестирование как-то не принято брать один файл из набора. Дабы ни у кого не возникало сомнений, что выбран самый удачный для конкретного алгоритма.
Насчёт VB — это не более чем моё личное вкусо-цвето-ощущение.
Главное, что «тема интересна». )
1. Paeth используется так же как и в PNG? Если да (побайтно) — то толку от него чуть.
2. Насколько я понял, Alpha не поддерживается. Плохо.
3. Зачем использовать LZMA после BWT? Понятно, что сжатие скорее всего будет, но с точки зрения и сжатия и распаковки черезчур затратно.
4. Если уж делать сжатие с потерями в YcbCr, то странно не учитывать разницу восприятия цветовых компонент.
5. Делать сравнение сжатия на самовыбранном изображении — то же что и просто назваться «лучшим сжатием». Для борьбы с «самопровозглашением» есть стандартные наборы тестовых изображений.
Вообще сжатие изображений это задача серьёзная, а в данной реализации это больше похоже на «а если взять PCX и сжать его ZIP будет ещё меньше».
И ещё, это конечно личное впечатление, но от использования VB для таких задач меня слегка покоробило.
Да, и последнее — не стоит воспринимать всё это как наезд, скорее это знак, что есть к чему стремиться.
Значит всё же голове появилось, но навела фраза «добавим в тред немного извращений» )
Но всё равно нестабильно будет. Даже при макс. приоритете на тред.
Погуглите как происходил тот самый «китайский» взлом.
При всём моём уважении к гугл, разговаривать после всего случившегося «о безопасности» им стоит как минимум шепотом.
Видимо я напрочь неправильный.
Потому, что мне больше нравится именно такой «аккуратный» вариант, а не очередные заявления о «абсолютно защищённой системе» и «полном отсутствии вирусов», независимо от того, о какой системе/платформе идёт речь.
Какая разница, писать на Си++ контролируя явно указатели, или настраивать GC, делать клиент-сервер и так далее. Сложности всего этого не отличается на порядок.
Разница не только в сложностях. Хотя они и отличается, пусть и не «на порядок».
Для большинства приложений сегодня безопасность не менее значительна чем производительность.
Ошибка при работе с указателями с C++ одна из наиболее распространённых «ошибко-дыр».
При работе в управляемой среде, незнание GC выльется в потерю производительности.
Но это я не к тому «что лучше, а что хуже». Просто у всего есть и плюсы и минусы.
И, таки да, всё надо «уметь готовить». Иначе даже самая трижды-рас-серебрянная пуля не поможет.
Основная сложность (и время) в проектировании, алгоритмах, поддержке и далее, далее.
Может я и ошибаюсь, но похоже весь спор просто из-за разницы в точках зрения.
Судя по Вашей фразе, Вы ближе к точке зрения менеджера-архитектора.
А большинство оппонентов (я в их числе, каюсь) смотрят на это с точки хрения программиста.
Лично я предпочитаю избегать подобных проблем на этапе проектирования/написания кода.
Привязываться к конкретной настройке GC как-то… не нравится в общем.
И не сказал бы что я «не умею их готовить». Не нравится и всё тут.
Ну а проектирование вообще отдельная тема.
В большинстве (чужих) проектов, что довелось видеть, проектированием занимались люди практически не знакомые с платформой.
В результате, делалось всё это лишь для того, чтобы потом с гордостью сказать «над проектированием системы 3 месяца работали наши лучшие непонятно-кто».
… а потом ещё 3 месяца программисты придумывали сами-знаете-какие названия этим непонятно-кому.
В конце-концов плюнули и втихую за месяц «перепроектировали» всё сами, но дабы соотвествовало «изначальному проекту».
Лично мне так и не довелось поработать в _настоящей_ связке менеджер-архитектор-разработчик.
Вот так. «Грустнично-реалистично»…
Насчёт C# и подвисаний — классическая ситуация.
Вот только причина не в «страшном тормозном GC», а (пардон) в уровне разработчиков.
Автоматическое управление памятью не значит, что об управлении последней можно вообще забыть.
Тем более это важно для проекта сложности выше среднего.
Ну, а если вдруг появились мысли в стиле «фу, какой гадкий этот C#», уточню — всё это актуально и для Java и практически для любой системы с управлением памятью.
А Sony с PS не самый удачный пример, учитывая ограничения на запуск кода. Если конечно Вы не являетесь сторонником введения подобных ограничений в Win.
1. Аутентичность контента.
Если файл ABC можно скачать с 1000 источников, трудно гнарантировать его подлинность.
2. Ассоциация «P2P = пиратсво».
Многие страны до сих пор пытаются запретить P2P технологии как таковые, Microsoft явно не будет рада ввязаться в подобные разборки.
Кстати, у немалая часть P2P систем имеет корни в разработках Microsoft Research.
А кто-нибудь знает, есть на WP7 что-то взамен андроидной синхронизации с гугловскими контактами?
P.S: Спасибо и тебе, о добрый умный аноним, не поленившийся оставить своё безусловно обоснованное и чрезвычайно ценное мнение в карме
Надеюсь в скором времени будет возможность пошупать всё это и у нас.
Кто бы ещё ответил на насколько вопросов:
1. Когда же наконец появится в России.
2. Что именно из телефонов под WP7 появится у нас и (весьма немеловажно) почем.
3. Планируется ли для WP7 (Marketplace) оплата со счёта телефона. Опять-таки «у нас».
P.S: Пока прилип к Android, но телефон на WP7 возьму, когда появится, дабы составить своё мнение. А там уже посмотрим.
Фильтр применяется либо только к базовому компоненту, либо до дельты.
Alpha обычно хранится как-есть.
Делать такое кодирование неопциональным смысла нет, т.к. выигрыш будет не на всех изображениях.
Можно попробовать ещё scale-delta. Он даёт более стабильный выигрыш.
Кроме того, есть попиксельные варианты Paeth, учитывающие многоканальность цвета.
2. Поканальная дельта
3. Ну, если битовая карта не растратна…
4. Поток коррекции
2. Могу посоветовать подумать над разделением/дифференциальным кодированием каналов.
3. «Цепочки одинаковых символов» != «повторяющиеся фразы». Кстати, шаг 6 с битовой картой выглядит весьма растратным.
4. На практике — бОльшая часть изображений уже с квантованием. А это уже можно использовать и в lossless режиме.
5. Можно взять «Kodak Lossless True Color Image Suite», кстати регионы для фильтров дают очень неплохой результат на «самолёте» и «африканке».
2. Тут вопрос не столько в практическом применении, сколько в универсальности алгоритма.
3. Часть LZMA это словарное (LZ) сжатие, я о том, что смыст в применении его после BWT как-то неочевиден.
4. Именно.
5. Для тестирование как-то не принято брать один файл из набора. Дабы ни у кого не возникало сомнений, что выбран самый удачный для конкретного алгоритма.
Насчёт VB — это не более чем моё личное вкусо-цвето-ощущение.
Главное, что «тема интересна». )
1. Paeth используется так же как и в PNG? Если да (побайтно) — то толку от него чуть.
2. Насколько я понял, Alpha не поддерживается. Плохо.
3. Зачем использовать LZMA после BWT? Понятно, что сжатие скорее всего будет, но с точки зрения и сжатия и распаковки черезчур затратно.
4. Если уж делать сжатие с потерями в YcbCr, то странно не учитывать разницу восприятия цветовых компонент.
5. Делать сравнение сжатия на самовыбранном изображении — то же что и просто назваться «лучшим сжатием». Для борьбы с «самопровозглашением» есть стандартные наборы тестовых изображений.
Вообще сжатие изображений это задача серьёзная, а в данной реализации это больше похоже на «а если взять PCX и сжать его ZIP будет ещё меньше».
И ещё, это конечно личное впечатление, но от использования VB для таких задач меня слегка покоробило.
Да, и последнее — не стоит воспринимать всё это как наезд, скорее это знак, что есть к чему стремиться.
Но всё равно нестабильно будет. Даже при макс. приоритете на тред.
1. Структура
2. [FieldOffset]
3. Поле Assert со своим Equal()
4. Переопределение полей как свойств
В в голове не появились (было выше):
5. Переопределение GetType
6. Тред с перезаписью значений
Да и ещё посмотрите, на какой версии и ос и ie всё происходило.
Всё это было бы понятно, происходи оно с безграмотной серкретаршей полуподвальной ИТ компании из двух человек.
При всём моём уважении к гугл, разговаривать после всего случившегося «о безопасности» им стоит как минимум шепотом.
Потому, что мне больше нравится именно такой «аккуратный» вариант, а не очередные заявления о «абсолютно защищённой системе» и «полном отсутствии вирусов», независимо от того, о какой системе/платформе идёт речь.
Разница не только в сложностях. Хотя они и отличается, пусть и не «на порядок».
Для большинства приложений сегодня безопасность не менее значительна чем производительность.
Ошибка при работе с указателями с C++ одна из наиболее распространённых «ошибко-дыр».
При работе в управляемой среде, незнание GC выльется в потерю производительности.
Но это я не к тому «что лучше, а что хуже». Просто у всего есть и плюсы и минусы.
И, таки да, всё надо «уметь готовить». Иначе даже самая трижды-рас-серебрянная пуля не поможет.
Может я и ошибаюсь, но похоже весь спор просто из-за разницы в точках зрения.
Судя по Вашей фразе, Вы ближе к точке зрения менеджера-архитектора.
А большинство оппонентов (я в их числе, каюсь) смотрят на это с точки хрения программиста.
Привязываться к конкретной настройке GC как-то… не нравится в общем.
И не сказал бы что я «не умею их готовить». Не нравится и всё тут.
Ну а проектирование вообще отдельная тема.
В большинстве (чужих) проектов, что довелось видеть, проектированием занимались люди практически не знакомые с платформой.
В результате, делалось всё это лишь для того, чтобы потом с гордостью сказать «над проектированием системы 3 месяца работали наши лучшие непонятно-кто».
… а потом ещё 3 месяца программисты придумывали сами-знаете-какие названия этим непонятно-кому.
В конце-концов плюнули и втихую за месяц «перепроектировали» всё сами, но дабы соотвествовало «изначальному проекту».
Лично мне так и не довелось поработать в _настоящей_ связке менеджер-архитектор-разработчик.
Вот так. «Грустнично-реалистично»…
Вот только причина не в «страшном тормозном GC», а (пардон) в уровне разработчиков.
Автоматическое управление памятью не значит, что об управлении последней можно вообще забыть.
Тем более это важно для проекта сложности выше среднего.
Ну, а если вдруг появились мысли в стиле «фу, какой гадкий этот C#», уточню — всё это актуально и для Java и практически для любой системы с управлением памятью.
Лействительно, в Silverlight нет DynamicResource.
Зато есть Binding и Converter'ы.
Sapienti sat