Видите ли вы разницу между понятиями "сжатие файла" и "сжатие изображения"

Привет.
Вот стало интересно видят ли люди разницу между понятиями "сжатие файла" и "сжатие изображения".
Навеяно вот этой темой: сжать фаил jpg
Никак не могу человеку объяснить что сжатие изображений допускает потери, а сжатие файлов нет.
Его основной аргумент - изображение тоже файл.
И раз алгоритм JPEG допускает сжатие с потерями, то и сам файл JPEG можно сжать с потерями.
Хотя изображение это не файл - это логическая интерпретация части данных файла.
Что что думает по этому поводу?

Думаю, что вы оба неправы

Т.к. и текстовый файл и изображение - это информация
А дальше есть куча разных алгоритмов сжатия, которые можно разделить на 2 категории: сжатие с потерей качества/информации и сжатие без потери качества/информации.
Собственно говоря никто не мешает взять RAW изображение, сжать его rar'ом, обозвать выходной файл SIA (Super Image Archive ), написать смотрелку, которая бы на лету распаковывала бы и показывала бы RAW (не будем вдаваться в вопросы быстродействия )

Так что вопрос поставлен некорректно
А если отвечать на

Цитата cppasm @ 14.02.09, 13:18

Видите ли вы разницу между понятиями "сжатие файла" и "сжатие изображения"

то разницы нет Т.к. и "сжатие файла" и "сжатие изображения" суть "сжатие информации" (просто разными алгоритмами)

Добавлено 14.02.09, 14:20
ЗЫ: не вижу разницы

Цитата Fester @ 14.02.09, 14:19

Думаю, что вы оба неправы

Что-то типа "Эй, вы трое, оба ко мне! - чего стоишь?"

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

Цитата cppasm @ 14.02.09, 13:18

Вот стало интересно видят ли люди разницу между понятиями "сжатие файла" и "сжатие изображения".

Разница есть только в алгоритмах сжатия. Всё. То, что 7-zip или Winrar не поддерживают сжатие с потерями не значит, что это - разные вещи.

Добавлено 14.02.09, 14:33

Цитата Демо @ 14.02.09, 14:25

Изображение - не информация.

ппц

Цитата Демо @ 14.02.09, 14:25

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

Вот только не надо "ля-ля"
Возьми RAW-изображение (файл!!! т.е. кучу байтов на файловой системе). Дальше ты можешь сжать этот файл используюя алгоритм JPEG, а можешь сжать используя RAR, в любом случае в результате у тебя получится файл (т.е. драгая последовательность байтов на файловой системе). Разница будет в том, что из RAR'а ты сможешь восстановить исходный RAW, а из JPEG'а - нет.

Вообще, только здраный смысл помешает какой-нибудь исполняемый файл пожать JPEG'ом

Так в чем разница?

Цитата

Т.к. и "сжатие файла" и "сжатие изображения" суть "сжатие информации" (просто разными алгоритмами)

Добавлено Сегодня, 17:20
ЗЫ: не вижу разницы

Алгоритмы не просто разные, а принципиально разные, т.к. природа сжимаемой информации разная и делается конкретное предположение о ее конечно виде (зрительная, визуальная, символьная и т.д.). Так, что ИМХО разница очевидна.

Добавлено 14.02.09, 14:37

Цитата

Разница есть только в алгоритмах сжатия. Всё. То, что 7-zip или Winrar не поддерживают сжатие с потерями не значит, что это - разные вещи.

Где там все? Сожми текстовый файл, алгоритмом сжатия используемом в JPG и попробуй потом прочесть его.

Цитата i++ @ 14.02.09, 14:33

т.к. природа сжимаемой информации разная и делается конкретное предположение о ее конечно виде (зрительная, визуальная, символьная и т.д.)

И что? Это просто узкоспециализировные алгоритмы. Вводить из-за них отдельные термины - себе дороже.

Сообщение отредактировано: Спящий - 14.02.09, 14:38

Цитата

И что? Это просто узкоспециализировные алгоритмы. Делать из-за них отдельные термины - себе дороже.

Так ты за какой вариант?

Добавлено 14.02.09, 14:41

Цитата

И что? Это просто узкоспециализировные алгоритмы.

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

Цитата i++ @ 14.02.09, 14:39

Так ты за какой вариант?

Я против терминов в том виде, в каком они представлены. Сущетсвует только сжатие файлов, а каким способом - уже другой вопрос.

Добавлено 14.02.09, 14:47

Цитата i++ @ 14.02.09, 14:39

Общее у них только слово "сжатие", да все они действительно делают файл поменьше.

Это понятно, но посуди:
1. Сжатие файлов
2. Сжатие растровых изображений
3. Сжатие векторных изображений
4. Сжатие звука
5. Сжатие обычных текстовых файлов (в принципе существовать может)
....
и т.д.

Оно надо?
Узкоспециализированых алгоритмов можно создать целую кучу. Часть из них - с потерей качества. И на каждый придумывать термин?

Добавлено 14.02.09, 14:48
Сжатие изображиния - это уменьшение его размеров (ширины и высоты). Не более.

Цитата

Я против терминов в том виде, в каком они представлены. Сущетсвует только сжатие файлов, а каким способом - уже другой вопрос.

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

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

Люди, ИМХО - с тем же успехом можно спорить на тему "Небо - оно голубое или синее?" Цвета разные, а содержание - одно.

Цитата

Оно надо?
Узкоспециализированых алгоритмов можно создать целую кучу. Часть из них - с потерей качества. И на каждый придумывать термин?

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

Цитата i++ @ 14.02.09, 14:51

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

Смысл работы этих двух сущностей един - сжать информацию Собственно именно поэтому у них один интерфейс

Цитата Спящий @ 14.02.09, 14:38

И что? Это просто узкоспециализировные алгоритмы. Вводить из-за них отдельные термины - себе дороже.

То что эти алгоритмы разрабатывались на основе восприятия человеком изображения.
Они не могут быть применены к произвольному файлу.
JPEG работает на уровне изображения - зрительного образа.
А RAR работает с битовым потоком - ему всё равно какие там данные.
Сжатие файла предполагает сжатие всех данных хранящихся в нём, а сжатие изображения нет.
В файле есть ещё заголовки, служебные данные и т.д., точно так же как в одном файле может быть несколько изображений.
И JPEG не работает на уровне файла.

Цитата i++ @ 14.02.09, 14:53

что мы не может сжимать текст с помощью алгоритмов сжатия звука например

Почему нет? Алгоритм же не знает что подается ему на вход Алгоритму пофиг текст там или звук Так что сжать текст с помощую алгоритмов сжатия звука пожно (вопрос целесообразности этого мы не рассматриваем )

Цитата Спящий @ 14.02.09, 14:43

Сжатие изображиния - это уменьшение его размеров (ширины и высоты). Не более.

Это resize вообще-то, а не сжатие...

Цитата i++ @ 14.02.09, 14:51

Сжатие без потерь, суть перекодирование, оно может применятся к любой битовой последовательности. Эффективное сжатие с потерями осуществляется путем предположений о природе сжимаемой информации.

Сжатие без потерь тоже может прекрасным образом делать предположения о природе сжимаемой информации, и часто делает.

Есть устоявшаяся терминология, которую пояснили Fester и Спящий. Зачем придумывать велосипед на треугольных колесах.

Цитата Fester @ 14.02.09, 14:58

Почему нет?

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

Опять же, давайте возьмем 2 файла - RAW-изображение и текстовый файл и сожмем их RAR'ом
В чем разница?

Цитата

Смысл работы этих двух сущностей един - сжать информацию Собственно именно поэтому у них один интерфейс

Да вот толко чтобы использовать виртуальный метод Сompress нужно в любом случае знать либо о конкретной его реализации, либо о типе входной информации.

Цитата Pourtous @ 14.02.09, 14:59

Сжатие без потерь тоже может прекрасным образом делать предположения о природе сжимаемой информации, и часто делает.

Например?

Добавлено 14.02.09, 15:03

Цитата Fester @ 14.02.09, 15:00

Опять же, давайте возьмем 2 файла - RAW-изображение и текстовый файл и сожмем их RAR'ом
В чем разница?

Ни в чём - потому что RAR работает на уровне файла.
А теперь возбмём те же два файла и сожмём JPEG.
Вообще говоря ко второму файлу это просто не применимо.

Цитата cppasm @ 14.02.09, 15:00

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

Пригодную к использованию кем? Для алгоритма распаковки тоже не важно, что идет на вход (я имею в виду хакартер данных, а не формат записи) и алгоритму распаковки пофигу что выходит в результате

Добавлено 14.02.09, 15:10

Цитата i++ @ 14.02.09, 15:01

Да вот толко чтобы использовать виртуальный метод Сompress нужно в любом случае знать либо о конкретной его реализации, либо о типе входной информации.

Ничего подобного У виртуального метода Сompress должен быть ипределен тип входных танных (имя файла/буфер/итд) и каждый наследник интерпритирует эти входные данные так, как ему хочется Интерфейсы для того и придуманы, чтобы использовать то, что за ними как черный ящик и ничего не знать о том, как эти черные ящики работают

Цитата cppasm @ 14.02.09, 15:02

Ни в чём - потому что RAR работает на уровне файла.

Только не на уровне файла RAR сжимает данные (читай "массив байтов").

Цитата cppasm @ 14.02.09, 15:02

А теперь возбмём те же два файла и сожмём JPEG.
Вообще говоря ко второму файлу это просто не применимо.

Почему? только из-за того, что ты не можешь восстановить? Ну так это издержки алгоритма

Цитата

Ничего подобного У виртуального метода Сompress должен быть ипределен тип входных танных (имя файла/буфер/итд) и каждый наследник интерпритирует эти входные данные так, как ему хочется Интерфейсы для того и придуманы, чтобы использовать то, что за ними как черный ящик и ничего не знать о том, как эти черные ящики работают

Предлагаешь подавать видеокомпрессору на вход битовый поток из текстового файла?

Добавлено 14.02.09, 15:21

Цитата

Почему? только из-за того, что ты не можешь восстановить? Ну так это издержки алгоритма

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

Добавлено 14.02.09, 15:23

Цитата

Пригодную к использованию кем? Для алгоритма распаковки тоже не важно, что идет на вход (я имею в виду хакартер данных, а не формат записи) и алгоритму распаковки пофигу что выходит в результате

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

Цитата i++ @ 14.02.09, 15:20

Предлагаешь подавать видеокомпрессору на вход битовый поток из текстового файла?

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

Цитата

Ничего подобного У виртуального метода Сompress должен быть ипределен тип входных танных (имя файла/буфер/итд) и каждый наследник интерпритирует эти входные данные так, как ему хочется Интерфейсы для того и придуманы, чтобы использовать то, что за ними как черный ящик и ничего не знать о том, как эти черные ящики работают

Я к тому, что для нормальной работы все равно придется вводить интерфейсы IVideoStream b IVideoCompressor (если даже не вводить явно, то все равно подразумевать и следить, чтобы компрессор соответствовал входных/выходным данным) и т.п., а раз уж мы имеем разные интерфейсы, то и сущности не идентичны.

Цитата

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

Эту очевидную вещь по-моему никто и не оспаривает.

Да, алгоритму всё равно что паковать и что распаковывать.
Но есть алгоритмы предназначенные для сжатия произвольных данных, а есть узкоспециализированные.
Fester - как по твоему, JPEG найл допустимо сжимать с потерями или нет?
Не изображение хранимое в этом файле, а именно сам файл.

Сообщение отредактировано: cppasm - 14.02.09, 15:31

Цитата i++ @ 14.02.09, 15:20

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

На входе был битовый поток и на выходе битовый поток. В чем разница? А разница только в смысловой нагрузке.

Опять же я не говорю, что тексты надо жать JPEG'ом
Я говорю, что есть имеет смысл говорить о алгоритмах сжатия информации.
И в зависимости от смысловой нагрузки, которую несет сжимаемая информация, имеет смысл применять тот или другой алгоритм сжатия информации.

Цитата Fester @ 14.02.09, 15:31

Я говорю, что есть имеет смысл говорить о алгоритмах сжатия информации.

Это более абстракный уровень.
Потому что информация - это может быть весь файл, может быть какая-то его часть.
Спор изначально начался с того, что для произвольных файлов недопустимо сжатие с потерями.
Они не будут никому нужны просто после распаковки.

Вернёмся к началу. Есть файл JPEG.
Я утверждаю, что изображение, хранимое в нём, допустимо сжимать с потерями.
Сам файл целиком - нет. С чем ты не согласен.
Имеется ввиду не гипотетическая возможность, а именно практическая - т.е. файл после распаковки должен быть пригоден к использованию.

Сообщение отредактировано: cppasm - 14.02.09, 15:37

Цитата

Я говорю, что есть имеет смысл говорить о алгоритмах сжатия информации.

Зачем мелочиться, давай просто говорить об алгоритмах обработки информации. Есть машина Тьюринга, лента, головка, алфавит, система команд, что еще надо?

Цитата

И в зависимости от смысловой нагрузки, которую несет сжимаемая информация, имеет смысл применять тот или другой алгоритм сжатия информации.

Именно, и они называются алгоритмами сжатия изображений, видео, текста и т.д.

Цитата cppasm @ 14.02.09, 15:30

JPEG найл допустимо сжимать с потерями или нет

Вот она двойственность используемых терминов

Когда ты говорить "JPEG файл" ты что имеешь в виду?

Сообщение отредактировано: Fester - 14.02.09, 15:38

Цитата Fester @ 14.02.09, 15:36

Когда ты говорить "JPEG найл" ты что имеешь в виду?

Имею ввиду файл хранимый на диске. Полностью - с заголовками и всем остальным.

Цитата cppasm @ 14.02.09, 15:34

Есть файл JPEG.
Я утверждаю, что изображение, хранимое в нём, допустимо сжимать с потерями.
Сам файл целиком - нет. С чем ты не согласен?
Имеется ввиду не гипотетическая возможность, а именно практическая - т.е. файл после распаковки должен быть пригоден к использованию.

Сообщение отредактировано: cppasm - 14.02.09, 15:40

Цитата

Когда ты говорить "JPEG файл" ты что имеешь в виду?

Графическое изображение сжатое по алгоритму JPEG (или хз как он так конкретно называется), вестимо.

Цитата

Когда ты говорить "JPEG файл" ты что имеешь в виду?

1)

Цитата cppasm @ 14.02.09, 15:39

Имею ввиду файл хранимый на диске. Полностью - с заголовками и всем остальным.

2)

Цитата i++ @ 14.02.09, 15:43

Графическое изображение сжатое по алгоритму JPEG (или хз как он так конкретно называется), вестимо.

бу-га-га
Вот об этом и речь

Добавлено 14.02.09, 15:46

Цитата cppasm @ 14.02.09, 15:39

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

Это ты потом дописал

Добавлено 14.02.09, 15:47
А хреновина такая из-за того, что вы неправильно определили терминологию
Говорить надо на одном языке и тогда не будет такого разброда

Добавлено 14.02.09, 15:48
Мне кажется, что на этом разговор можно завершить

Fester, ты так красиво съехал, что никто ничего не понял из твоего поста.

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

Цитата cppasm @ 14.02.09, 15:02

Например?

Самое простое --- loseless кодеки, png.

Цитата i++ @ 14.02.09, 15:54

Fester, ты так красиво съехал, что никто ничего не понял из твоего поста.

А что тут не понятного?
Был использован один термин "JPEG файл" при этом 2 разных человека, отстаивающие одну точку зрения, под этим термином понимают 2 совершенно разные вещи

Joint Photographic Experts Group

Цитата Pourtous @ 14.02.09, 16:01

Самое простое --- loseless кодеки, png.

Они не делают никаких предположений о характере входных данных.

Цитата Fester @ 14.02.09, 15:46

Это ты потом дописал

Ну смотря что такое потом Отредактировал практически сразу.

Цитата i++ @ 14.02.09, 15:54

Fester, ты так красиво съехал, что никто ничего не понял из твоего поста.

Он про то, что я написал что "JPEG файл" это файл на уровне файловой системы, содержащий изображение сжатое алгоритмом JPEG, так же как заголовки и другие служебные данные.
А ты написал что это сжатое алгоритмом JPEG изображение.

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

Опять же, сжатое RAW-изображение алгоритмом RAR - это сжатый файл или сжатое изображение?
А сжатый JPEG'ом текст - это сжатый текст или уже сжатое изображение? (увидеть-то что-то можно будет в конце концов "Черный квадрат" тоже не все понимают )

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

Добавлено 14.02.09, 16:13

Цитата Fester @ 14.02.09, 16:10

Опять же, сжатое RAW-изображение алгоритмом RAR - это сжатый файл или сжатое изображение?

Файл.

Цитата Fester @ 14.02.09, 16:10

А сжатый JPEG'ом текст - это сжатый текст или уже сжатое изображение?

Текст не жмётся JPEG-ом. Совсем (не в смысле степени сжатия, а в смысле применимости).
Для того чтобы сжать текст JPEG-ом ты должен его тем или иным образом интерпретировать как изображение.

Цитата cppasm @ 14.02.09, 16:09

По сути весь спор из-за того что в моём понимании файл и хранимое в нём изображение - это разные вещи.

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

Цитата

Опять же, сжатое RAW-изображение алгоритмом RAR - это сжатый файл или сжатое изображение?

Это сжатое нечно на уровне нулей и единиц.

Цитата

А сжатый JPEG'ом текст - это сжатый текст или уже сжатое изображение? (увидеть-то что-то можно будет в конце концов "Черный квадрат" тоже не все понимают )

Это сжатая графическая информацию, которую в ее графическом виде и будут использовать, смотреть, распечатывать и т.д. Именно особенности человеческого восприятия позволяют использовать принципиально иные технологии сжатия. Более того во многих случаях, в исходном входном потоке нужно выделять пикселы т.е. работать с группами битов.

Цитата

А ты написал что это сжатое алгоритмом JPEG изображение.

По-моему я JPEG вообще не поминал.

Добавлено Сегодня, 19:19

Цитата

Именно, а на самом деле и то и другое - просто набор байтов, к которым по разным соображения применяют разные алгоритмы компрессии

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

Цитата

И строить стену между разными алгоритмами сжатия данных несколько странно, т.к. в итоге это все равно сжатие данных.

В итоге все равно алгоритмы как ни крути. Зачем вообще эти нелепые классификации?

Цитата cppasm @ 14.02.09, 16:11

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

Потери при сжатии изображения могут быть таким, что потом ничего не увидишь/не разберешь. И что, такое сжатие перестанет быть сжатием ижображения?

Цитата cppasm @ 14.02.09, 16:11

Цитата

Опять же, сжатое RAW-изображение алгоритмом RAR - это сжатый файл или сжатое изображение?

Файл.

Почему файл? А если RAR'ом сожмешь только "картинку", прилепишь какие-нибудь информационные хидеры и обзовешь это безобразие *.SIA ?
Как ты определяешь что получится "файд" или "изображение"?

Добавлено 14.02.09, 16:31

Цитата i++ @ 14.02.09, 16:19

Зачем вообще эти нелепые классификации?

Видишь ли, "багги", "родстер", "джип", "лимузин" - все это автомобили.
Вот только в одном случае говорят "дядю Васю сбил автомобиль", а в другом "еду я на джипе" И при этом и в первом и по втомо случае все понимают, что речь идет об автомобиле

Цитата Fester @ 14.02.09, 16:23

Почему файл? А если RAR'ом сожмешь только "картинку", прилепишь какие-нибудь информационные хидеры и обзовешь это безобразие *.SIA ?

Потому что RAR работает с битовым потоком. Ему безразлична его структура.
Он не рассматривает данные как изображение, не использует никакие его характеристики.
JPEG оперирует с характеристиками изображения - яркость, цветоразность и так далее.
Для его работа битовый поток так или иначе должен интерпретироваться именно как изображение.

Добавлено 14.02.09, 16:34

Цитата Fester @ 14.02.09, 16:14

И строить стену между разными алгоритмами сжатия данных несколько странно, т.к. в итоге это все равно сжатие данных.

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

Сообщение отредактировано: cppasm - 14.02.09, 16:36

Цитата cppasm @ 14.02.09, 16:31

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

А теперь вернемся к вопросу топика: Видите ли вы разницу между понятиями "сжатие файла" и "сжатие изображения"?
Итак. (барабанная дробь)... Разница - в том, каким алгоритмом сжатия данных воспользовался человек.

Добавлено 14.02.09, 16:44
Ну, блин, нафлеймили

Сообщение отредактировано: Fester - 14.02.09, 16:44

Цитата cppasm @ 14.02.09, 13:18

Видите ли вы разницу между понятиями "сжатие файла" и "сжатие изображения"

Для меня она очевидна. НО(!), правда, с поправочкой. Про сжатие файла говорить не буду , наверное и так понятно, что, например, текстовые файлы сжимаются очень хорошо - без всяких потерь.
А вот по поводу изображения есть различия. Если это, скажем, BMP формат - то он очень даже хорошо сжимается, так как там просто каждый пиксель записывается - значит может быть много одинаковых значений, а каких-то значений (из возможно допустимых) не быть вообще - значит можно сжать. А вот формат JPEG сам по себе уже является сжатием (причем уже с потерями, как правило) - значит дальнейшее его сжатие возможно только с потерями

Цитата Fester @ 14.02.09, 16:43

Итак. (барабанная дробь)... Разница - в том, каким алгоритмом сжатия данных воспользовался человек.

И к какому набору данных применил.
Повторюсь, что под сжатием файла лично я понимаю сжатие абстрактной (случайной) последовательности данных, хранимых в этом файле.
Но сжатие всех данных, хранимых в этом файле.
Сжатие изображения это несколько более высокий логический уровень, важна интерпретация входных данных.

Цитата Fester @ 14.02.09, 16:43

А теперь вернемся к вопросу топика: Видите ли вы разницу между понятиями "сжатие файла" и "сжатие изображения"?
Итак. (барабанная дробь)... Разница - в том, каким алгоритмом сжатия данных воспользовался человек.

Разница не в алгоритмах, а в подходе, в назначении данных.

Изображение (а также видео) предназначено для визуального отображения и восприятия человеческим глазом.
А человеческий глаз не способен заметить отличие исходного изображения от изменённого при небольших искажениях.
Для этого и производится сжатие изображений.
Сжатие изображений может происходить за счёт более компактного хранения информации, либо за счёт ухудшения качества изображениё путём уменьшения количества этой информации(не архивации!).

К этой же категории относится и видео.

Любые другие данные сжимаются с другой целью - с целью минимизации объёмов хранения и передачи информации.

Вот это и есть принципиальное и несомненное отличие от сжатия изображений и файлов.

----------------
PS.
К понятию "сжатие файлов" применим аналог - "архивация файлов".
К изображениям этот такой аналог неприменим.

Сообщение отредактировано: Демо - 14.02.09, 18:43

Демо, я не знаю зачем использовать сжатие изображений, если не для инимизации объёмов хранения видео контента

Вобщем-то есть ряд требований, например для видео:
1) минимальная потеря качества
2) максимальное сжатие
3) возможность распаковывать сдажиты данные "на лету" (т.е. быстродествие)

Для архивации данных с целью хранения (любой контент):
1) максимальное сжатие

Таким образом, если мы хотим сохранить RAW-изображение в архиве, то может быть имеет смысл воспользоваться RAR'ом (надо провести тесты и сравнить), а если хотим иметь возможность быстро просматривать это изображение, то следует воспользоваться чем-то заточеным для картинок.

Цитата Демо @ 14.02.09, 18:34

Любые другие данные сжимаются с другой целью - с целью минимизации объёмов хранения и передачи информации.

Все данные сжимаются с одной целью Если тебе не надо миминизировать объемы хранения, то не сжимай

Цитата Fester @ 14.02.09, 18:51

Все данные сжимаются с одной целью Если тебе не надо миминизировать объемы хранения, то не сжимай

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

А зачем сжимают изображение? Чтобы качество было похуже?

Цитата Fester @ 14.02.09, 19:03

А зачем сжимают изображение? Чтобы качество было похуже?

Ты не видишь отличия в том, чтобы "сжать данные (уменьшить объём), чтобы потом восстановить" от "сжать данные(уменьшить объём) без возможности восстановления"?

Добавлено 14.02.09, 19:12

Цитата Fester @ 14.02.09, 19:03

А зачем сжимают изображение? Чтобы качество было похуже?

Чтобы изображение занимало меньше места на диске. Вот только восстановить первоначальное состояние изображения не удастся в большинстве случаев.

Демо, смотри пост #50, все то, что ты говоришь - это список требований для "ужимальщика" данных А требования можно придумывать долго и можно понапридумывать кучу всего, но суть - уменьшить объем исходных данных.


Ладно, становлюсь читателем, а то меня в этой теме слишком много

Цитата Fester @ 14.02.09, 19:22

все то, что ты говоришь - это список требований для "ужимальщика" данных

Это не требования. Это свойства. Как уже говорил раньше - главное цель использования данных(назначение).
Цель и определяет средства и свойства.

Цитата cppasm @ 14.02.09, 16:09

Они не делают никаких предположений о характере входных данных.

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

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

Сообщение отредактировано: Pourtous - 14.02.09, 21:29

Цитата cppasm @ 14.02.09, 14:55

Цитата Спящий @ 14.02.09, 14:38

И что? Это просто узкоспециализировные алгоритмы. Вводить из-за них отдельные термины - себе дороже.

То что эти алгоритмы разрабатывались на основе восприятия человеком изображения.
Они не могут быть применены к произвольному файлу.
JPEG работает на уровне изображения - зрительного образа.
А RAR работает с битовым потоком - ему всё равно какие там данные.
Сжатие файла предполагает сжатие всех данных хранящихся в нём, а сжатие изображения нет.
В файле есть ещё заголовки, служебные данные и т.д., точно так же как в одном файле может быть несколько изображений.
И JPEG не работает на уровне файла.

согласен, посему п.1
если взять рисунок BMP и сжать его раром -> размер уменьшиться, затем распаковать его -> размер вернется обратно, качество изображения при этом не пострадает.
если взять все тот же рисунок и сжать его в JPG (преобразовать) -> размер уменьшится, вместе с качеством, если потом его обратно преобразовать в BMP первоначально качество изображения не вернется

Цитата Pourtous @ 14.02.09, 21:28

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

Lossless кодек RGB данные пожмёт, так же как и PNG пожмёт аудиопоток.
Да, пожмёт хуже чем "родные" данные, для которых алгоритм предназначен.

Хм. Речь идет о несколько разных вещах, и получается, что сравнивается теплое с мягким. Под "сжатием файла" понимается уменьшение объема (т. е. архивация) неких абстрактных данных. Под "сжатием изображения" понимается выбор некоего способа кодирования растровой графической информации. Это, все же, разные вещи. Изображение (т. е. растр) можно закодировать десятком способов. От простого (в виде RAW-RGB-триплетов), до JPEG и фракталов. Аналогично со способами кодирования аудио- и видео-потоков данных. А "кодирование" (в данном контексте) не есть "архивация".

Цитата Flex Ferrum @ 14.02.09, 23:31

А "кодирование" (в данном контексте) не есть "архивация".

Это, вроде, только подготовительная часть к сжатию. Модификация данных под конкретный алгоритм сжатия.

Fester, прав!

Цитата Спящий @ 15.02.09, 03:28

Это, вроде, только подготовительная часть к сжатию. Модификация данных под конкретный алгоритм сжатия.

Ну, положим, не для всех кодеров изображений это верно - это раз, второе - в ряде случаев конкретный алгоритм сжатия используется на финальном этапе для уменьшения энтропии полученного набора данных (т. е. сказав А, надо сказать и Б ). Возьми тот же JPEG. Да, там в самом конце используется хаффман. Но для какого набора данных? Для растра, преобразованного в Lab-схему, потом пофрагментно пропущенного через дискретное косинусоидальное преобразование (отдельно для каждой плоскости), результат которого пропускается через низкочастотный фильтр (отдельно, опять же, для каждой плоскости и с разными параметрами, в L-компоненте оставляется вдвое больше высоких частот, чем в a и b). Т. е. на вход хаффману подается пофрагментный-поплоскостной отфильтрованный спектр изображения с отрезанными высокими частотами. Попробуй ты такое проверни для обычного абстрактного файла с данными. Так к тому же jpeg-алгоритм будет работать чуть-чуть по-разному для черно-белых и для цветных изображений. Можно, конечно, это считать "хитрым способом архивации файла", да вот только такое утверждение неверно. Т. к. алгоритм применим только к растровым изображениям и, вообще говоря, как таковой "архивацией" не является. А хранишь ты непосредственно растр, или его частотный спектр - это лишь способ представления одной и той же информации, т. к. одно однозначно преобразуется в другое.

Во, Flex Ferrum наконец выразил словами то, что собственно я никак не могу объяснить

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

Сообщение отредактировано: Ahil - 16.02.09, 14:35

Ahil, "файл", вообще-то переводится как "напильник". Нафига под пресс ложить напильники я лично не понимаю.