Комментарии 42
Потому что гладиолус. Почему бы не в txt, а картинки псевдографикой? Ну вот так вот, каждый извращается в меру своих сил
Конечно, но я точно так же черным по белому написал, что пользователь не хочет больше ничего пережимать. Постановка задачи такая, ну мало ли бывает в жизни, я ж не предлагаю всем использовать. Вот захочется поизвращаться, а метод-то уже есть!
Нет никакой конвертации, фото остаются фото. f5ar — это дополнительный файл, хранящий всю необходимую для извлечения информации, сами файлы хранятся и открываются как и до этого. Довольно ясно же написал, что изменяется только их содержимое немного для эффективного кодирования дополнительной информации
Все это собирается 'make''ом, поэтому пользователи Windows для оценки хотят установить себе какой-нибудь Cygwin, либо разбираться с Visual Studio и библиотеками самостоятельно.
А использовали бы CMake — и виндоюзеры бы заплакали от восторга.
Смотря на все эти сложности, купить жесткий диск или залить все в облако может показаться куда более простым решением проблемы.
Меня всю статью не покидала мысль об архиваторах. Жаль, картинки и видео сжимаются плохо, а они — основной сжиратель места на винтах.
Cmake генерирует файлы для того же make
Не знал, последний вижак видел в версии 8го года, тогда таких фич еще не было. В любом случае, уж из обычного мейка на три файла любой справится сделать проект в вижаке
Так-то, конечно, накидать файлов в проект может любой, но есть один нюанс. Когда система сборки кроссплатформенная, подразумевается, что автор не прочь бы собрать свой проект на всяких платформах — а значит, будет не против патчей, исправляющих ошибки сборки под виндой. Ну а когда система сборки — *nix-only, то сразу понятно, что код под виндой даже не пытались собирать, а значит, придется разгребать ошибки. При этом не факт, что автор потом патчи примет.
Конечно отдельный, но с два-нуль-нуль-восьмой версией вижака он подобного не умел еще, временная шкала-то общая. Ну либо я не знал об этом уже тогда, просто пытаюсь прояснить причину
автор не прочь бы собрать свой проект на всяких платформах
Я сам использую MSYS и Cygwin на винде, в обеих средах все собирается и обычным мейком, куда уже кросс-платформеннее. Желания делать отдельно для вижака систему сборки не нашел, учитывая, что все равно натыкаюсь на стену непонимания в лице "пересжать лучши"
Я сам использую MSYS и Cygwin на винде, в обеих средах все собирается и обычным мейком, куда уже кросс-платформеннее.
Это не кроссплатформенность, это эмулятор юниксов в винде. Так-то и «блокнот» виндовый можно под линуксом запустить через wine, но это не делает его кроссплатформенным. :)
Желания делать отдельно для вижака систему сборки не нашел,
Вы не понимаете смысла термина «кроссплатформенная система сборки», да? :)
Кроссплатформенная — значит, одна на все платформы. Не «отдельно для вижака», а одна на все.
MSYS'ом можно собрать чисто виндовый экзешник, который работает где угодно сам по себе. С вот cygwin'ом потребуется таскать dll"ку для запуска
Кроссплатформенная — значит, одна на все платформы
Именно. Вижак — не платформа, платформой является Windows. На ней можно собирать экзешники, используя makefile. То, что одна IDE на этой платформе требует совершенно отдельного подхода, дело десятое
CMake позволяет использовать любой тулчейн из поддерживаемых. Вы же таскаете за собой всю экосистему — ну такая себе кроссплатформенность. :)
С каких пор make — экосистема? Простая консольная утилита для автоматизации базовых действий, не более
Показалось, наверное. :)
Ну нужен еще компилятор и стандартная библиотека, конечно же. К слову, тот же мсис их не содержит по умолчанию, надо самому ставить руками. Суть в том, что с их помощью компиляция является довольно тривиальным процессом, а вот вижаком даже зависимости (официально компилирующиеся им) без поллитра не скомпилить
Я предпочитаю всякие gcc и cmake, потому что пишу на си, поэтому в глубине души верю, что си-люди за пределами юникс-сред не обитают. Тот же вижак не поддерживает нормально даже C99, поэтому не знаю, кто вообще этим всем заниматься с ним
Я тут еще вспомнил, что в 10й версии есть подсистема убунтовская, так что теперь вообще не вижу даже отблеска проблемы, столько альтернатив
части, отвечающей за секретность (парольной перестановки)
Мне кажется перестановка там не только для безопасности — она еще позволяет размазать вносимые искажения по изображению.
И еще — поясните поподробнее метод внедрения данных. Фраза «Сами изменения при этом сводятся к уменьшению абсолютного значения коэффициентов на единицу в определенных условиях (то есть, не всегда)» не дает понимания техники встраивания данных. Можно этот момент чуть подробнее?
Мне кажется перестановка там не только для безопасности — она еще позволяет размазать вносимые искажения по изображению
Так точно, сэр. Но это требуется только когда происходит работа над одним файлом, если же встраивание производится во все множество сразу, то значения и так будут распределены околоравномерно внутри каждого его элемента, кроме разве что последнего
Можно этот момент чуть подробнее
Подробнее — это описывать сам алгоритм F5. В статье я оставил ссылку на хорошую статью о нем
Разница между снижением качества пересжатием и таким методом коллосальна, их рядом даже ставить нельзя
Все необходимое для обоснование уже есть в посте. Работа производится над квантованными DCT-коэффициентами, из которых в самом-самом (крайне редком) худшем случае модифицируется половина только у одной компоненты. Визуально такие изменения малозаметны
При перекодировании ДК преобразование и квантование с "более оптимальной" матрицей происходят заново, тем самым модифицируя в худшую сторону все (зачастую на дельту >1) коэффициенты в файле. Тем самым оно дает и больший выигрыш в размере, но и более заметную потерю качества
О какой матрице идет речь? До перевода в растр мы имеем дело лишь с последовательностью коэффициентах в блоках 8х8, и все способы уменьшения размера манипуляциями с ними приводят к большим потерям из-за все тех же вероятностей.
При встраивании инородной информации значение меняется лишь с определенным шансом. Как я написал в самом начале поста, две случайных битовых последовательности совпадают в среднем на 50%. Точно так же и здесь при встраивании изменяется лишь часть коэффициентов (заметно меньше этих 50%).
При их же оптимизации они выбираются и изменяются по детермерированному алгоритму, который (если специально не добавить в него ГСЧП) изменит бОльшую их часть в силу строгости критериев (не существует более мягкого для оптимизации JPEG-файла, чем выбор случайного с небольшой вероятностью)
Кроме того, после прогона им информация в изображении теряется впустую. При встраивании же она не просто исчезает, но начинает кодировать собой некоторую другую информацию
Одно дело убрать стереть пыль с машины, и совсем другое — написать на ней что-нибудь. Процессы схожи, но имеют разную цель
Предлагаю рассмотреть такой вариант работы: вместо замены битов обнулим те же самые биты, JPEG точно так же изменится ненамного, всего 50% битов-«контейнеров» будут обнулены, но взамен данные будут лучше сжиматься за счёт более низкой энтропии, файл уменьшится, и освободившееся место можно будет использовать для своей информации. На мой взгляд, это места займёт столько же, но не нужно будет ничего упаковывать-распаковывать.
Так я это и делаю! Только вместо "простого" обнуления внутрь еще и информация кодируется, это как 2 в 1!
Ну кроме шуток, я думал над этим как отдельным методом, даже код частично написал (для оптимизации RLE, до Хаффмана не добрался, но там и выхлоп меньше), но в процессе тестирования выяснил, что шумы заметны глазу при практически любых не вероятностных стратегиях выбора коэффициентов. Те, что не заметны, не дают почти никакого выхлопа :(
А что как не по русски то написано, читать как то не приятно. Очень плохо объясняется, даже узко специализированному читателю мне кажется на очень то и ясно. Самое главное очень размыта именно сама суть алгоритма — откуда же там берется место и как это вообще работает.
Первый пост был с деталями, но по комментариям и сообщениям быстро понял, что люди все равно читают пятой точкой, а лишние буквы их только смущают. Поэтому отсутствие объяснений целенаправленное. Тем не менее, информации для специалистов более чем достаточно. Если что-то все-таки не понятно, то могу ответить на любые вопросы тут, в личке или где-нибудь еще
Все это собирается 'make''ом, поэтому пользователи Windows для оценки хотят установить себе какой-нибудь Cygwin, либо разбираться с Visual Studio и библиотеками самостоятельно.
Нет, пользователи Windows этого не хотят. А вот вы хотите оформить кросс-платформенный проект как полагается, через Cmake.
Тут всем так нравится костыли вместо ног использовать? Самое смешное, что проект собирается им в частности просто потому, что кривой CLion не умеет иначе подсвечивать синтаксис нормально. Мейк же пришлось писать отдельно как раз для того, чтобы от этих костылей избавиться и собирать нормально нормально на всех системах
P.S. Я не имею ничего против cmake в больших проектах с кучей зависимостей и логикой при сборке, но навязываение его использования ради компиляции всего тройки файлов напоминает лишь о микроскопе и гвоздях
Плюс CMake позволяет расширять проект гораздо проще и единообразнее, чем даже automake (не говоря уже о голом make).
Единственное неудобство — надо аж две разных команды выучить: «cmake -G имя_генератора .» и «cmake --build .».
О странном методе экономии места на жестком диске