Тройное сжатие и я только сохраняем 1% в пространстве?

Не использовать xhost +. Это открывает все виды дверей и прерываний.

Лучший способ состоит в том, чтобы позволить ssh соглашение со все это, также - чем-то вроде этого на Вашей локальной машине

$ ssh -X remote.machine.net

и однажды там, протестируйте с быстрым

$ xlock &
$ xterm &

который должен открыться на Вашем локальном поле. Крупные приложения как Firefox берут намного дольше.

2
10.04.2013, 20:12
8 ответов

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

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

Если я супер волнуюсь по поводу пространства, я просто делаю "bzip2 - 9" и называю его хорошим. Я услышал хорошие вещи об отношении на XZ все же. Я не использовал XZ сам (кроме распаковать материал других людей), но он, как предполагается, имеет лучшее отношение, чем bzip2, но берет немного дольше для сжимания/распаковывания.

32
27.01.2020, 21:48
  • 1
    Каждый раз, когда я использовал xs, он дал намного лучшее сжатие, но намного медленнее сжиматься. Например, 50% к 25%, но 20 секунд к 4 минутам (на тексте). –  OrangeDog 11.04.2013, 14:49
  • 2
    xz по сравнению с bzip2 обычно дает лучшее отношение и более быструю распаковку, но занимает больше времени для сжатия вещей, который делает его лучше для чего-то, что будет распаковано более затем одно время, как что-либо, что Вы планируете распределить среди многих пользователей. –  gelraen 12.04.2013, 13:12
  • 3
    Не "bzip2 - 9" настройка по умолчанию? Для bzip2 - 1 к-9 просто указывают размер "блоков", сжимаемых от 100k до 900k. –  Baard Kopperud 12.04.2013, 17:52

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

Вот пример, повторно сжимающий все изображения JPEG с помощью imagemagick. Обратите внимание, что это перезапишет Ваши файлы.

find image_directory -type f -name "*.jpg" -exec mogrify -quality 75% {} \+
13
27.01.2020, 21:48
  • 1
    +1 для того, чтобы быть единственным ответом, который говорит о с потерями и без потерь. спасибо –  Konerak 11.04.2013, 11:09

Наиболее распространенные форматы изображения уже сжаты (как jpg, png, gif), таким образом, Вы не получаете очень сбережения. 1%-е звуки о праве.

Добавление большего количества сжатия может на самом деле сделать результат (немного) больше, потому что алгоритм сжатия не обладает никаким преимуществом на сжатых данных, и затем формат (например, gzip) должен добавить заголовок и/или информацию о структуре к выводу.

Прошу прощения! При использовании pngs можно попытаться уменьшить файлы с помощью pngcrush.

10
27.01.2020, 21:48

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

2) Это обычно - плохая идея попытаться сжать те же данные неоднократно; сжимает ли это уже оптимизированный тип файла (например, gziping jpeg-файл) или применяет другое или те же программы сжатия в тот же файл в последовательном (как Вы сделали).

3) При сжатии файла Вы иногда будете заканчивать с большим файлом, чем Вы первоначально имели (используйте касание, чтобы сделать пустой файл и попробовать к bzip2 его). Это должен быть тот путь; потому что еще Вы смогли бы взять некоторые данные, сжать их снова и снова, пока ничто не оставили, но пустой файл, и все еще смочь распаковать назад к исходным данным позже - но это звучит логичным?

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

4) Лучший способ сохранить данные, должен найти программу сжатия, которая дает лучшее усиление для любых данных, которые Вы имеете (поскольку усиление может варьироваться в зависимости от данных); и используйте только, что программа сжатия и использует его только однажды - но с он является лучшим (часто самый медленный и большая часть требования ресурса) установка. В настоящее время "лучшее" (предоставление большей части усиления) программа сжатия, вероятно, xzip, хотя bzip2 не далек позади. Удостоверьтесь, что Вы выбираете лучший уровень сжатия.

5) Для изображений (как jpeg) Вы часто используете сжатие "с потерями" - т.е. Вы освобождаете некоторые данные (в отличие от этого, при использовании программ как xzip, bzip2 и gzip, которые не с потерями). Неоднократно сжатие JPEG, изображение для этого сделает изображение меньшим каждый раз, оно использовало (в отличие от использования чего-то как bzip2 дважды), но Вы освободите детали в изображении. Существуют также другие вещи, которые можно сделать к изображениям - как изменение размера (делающий это меньший) или разрешение (меньше пикселей на дюйм) - это сделает это "меньшим", но снова данные будут потеряны.

Таким образом, если качество изображений не настолько важно, и Вы абсолютно хотите оставить свободное место, с помощью программы как ImageMagic, чтобы пакетно обработать все изображения и делая их, меньшее, менее подробное и/или использующее более высокое jpeg-сжатие может сохранить Вас партия пространства. Это будет с потерями, хотя, и Ваши изображения освободит детали.

6) Немного OT, но Вы посмотрели на материал как каталоги миниатюр - как ~/.thumbnails? Если Вы имеете много изображений в своих каталогах и используете файловые браузеры с предварительным просмотром изображения, .thumbnails может содержать много миниатюр изображений, которые Вы просмотрели в некоторое время. Лично я получил большое дисковое пространство путем стандартного удаления файлов под различными убежищами для миниатюр...

6
27.01.2020, 21:48

Другая точка, которую стоит повысить: использование нескольких инструментов/алгоритмов сжатия может на самом деле вызвать Ваш конечный результат расшириться в размере и стать больше, чем это должно быть. Значение, сжимаете ли Вы 100 ГБ вниз до 10 ГБ и затем пытаетесь сжать его снова, можно закончить с ~15GB в зависимости от того, что Вы сжимаете и с чем Вы сжимаете его.

Лично я никогда не делаю что-то большее чем tar cjvf container.tar.bz2 /target просто, потому что количество дискового пространства, сохраненного двойным сжатием, миниатюрно.

4
27.01.2020, 21:48

Форматы изображения такой как png и jpeg уже сжаты. Усиление от сжатия их снова минимально.

4
27.01.2020, 21:48

Как математик, я чувствую, что должен вмешаться и уточнить немного. Вопрос сводится к сжатию с потерями по сравнению со сжатием без потерь. Сжатие изображения как jpeg является сжатием с потерями, и архивирование без потерь.

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

Без потерь - с этим Вы не потеряете информации вообще и когда Вы "распакуете" Вас, будет иметь исходный файл точно. Но здесь компромисс - то, что сокращение размера не гарантируется (легко доказанное использование принципа ящика). Таким образом, некоторый файл уменьшится в размере. Некоторые останутся тем же. И да некоторые могут на самом деле увеличиться в размере. Таким образом, алгоритмы без потерь разработаны/оптимизированы для определенного вида данных, таким образом, они работают при сжатии (без потерь) одного вида данных очень хорошо и абсолютно сосут в других.

Это - то, где мое незнание информатики умирает. Я думаю, что файл, архивирующий Вас, использует, оптимизирован для текста, не для изображений, таким образом, они не помогают с изображениями. Изображения уже (с потерями) сжатый, и затем сжатие их снова не поможет. Если Вы хотите к (с потерями), сжимают их снова, Вы могли бы разрушить изображения и потерять слишком много информации..., которая похожа на сохранение их как jpeg с большим акцентом на размер, чем качество.

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

4
27.01.2020, 21:48
  • 1
    Нет никакого преимущества, которое будет получено от оптимизации алгоритма к определенному виду данных. В конечном счете это - все слова по алфавиту 2 букв. Если существуют шаблоны, они могут быть найдены, или текст или titty. Однако может быть эвристическая оптимизация для структуры данных. Я однажды записал немного что-то, что интерпретирует составной PDF (т.е. PDF с изображениями PDF) и устранит избыточные определения шрифта и метаинформацию. С этим я могу сжать в среднем 20% от своего PDFs без потери данных, даже при том, что исходные PDFs уже сжаты. –  Bananguin 20.05.2016, 10:57
  • 2
    И только обстоятельно объяснить принцип pidgeon-дыры: если какая-либо строка могла бы быть сжата в более короткую строку w/o потеря данных, в конечном счете каждая строка могла быть сжата в строку длины 1. Поскольку количество символов ограничено (например, 8 битов), в то время как длина входных строк не, имея |available символы | + 1 строка (например, 257) все с попарными различными длинами, привел бы по крайней мере к одной сжатой строке, появляющейся дважды, и алгоритм распаковки не может знать который исходная строка восстановить от него. => Не каждая строка может быть сжата в более короткую строку w/o потеря данных. –  Bananguin 20.05.2016, 11:09

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

1
27.01.2020, 21:48
  • 1
    TIFF может быть или с потерями или без потерь сжат. Форматы Camera Raw часто сжимаются (легко показанный путем рассмотрения размеров файла; если они отличаются больше, чем миниатюрная сумма, относящаяся к метаданным и возможной встроенной миниатюре, то необработанные данные очень вероятно сжаты до некоторой степени). –  a CVn 12.04.2013, 12:00

Теги

Похожие вопросы