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