Как работает JPEG-сжатие? Разбор | Droider.ru
Сегодня для нас нет ничего необычного в том, чтобы отправить фотку другу и не волноваться по поводу того, какое устройство, браузер или операционную систему он использует. Все это благодаря формату JPEG, который может уменьшить размер исходного файла в 10, 50 и даже в 100 раз. Изображения формата JPEG встречаются повсюду в нашей жизни в интернете, но за простотой и удобством использования скрываются алгоритмы, устраняющие детали, не воспринимаемые человеческим глазом. В итоге получается высочайшее визуальное качество при наименьшем размере файла.
Вы когда-нибудь задумывались, сколько места фотки на наших устройствах?
Давате посмотрим на этот снимок:
Его разрешение 12.
2 мегапикселя или 4032 × 3024 точек. Сколько он должна бы весить? Давайте посчитаем. Как известно, цвет каждого пикселя определяется тремя составляющими: красным, зелёным и синим. Каждая составляющая кодируется восьмибитным числом. Получим, что такое изображение будет весить 8х3х4032×3024 = 292 626 432 бит, то есть почти 300 мб!!!
В реальности же она весит 7.36 мб. То есть в 40 раз МЕНЬШЕ! А если пожать через Whatsapp, будут какие-то 200 килобайт. Все благодаря формату JPEG, с которым мы сталкиваемся постоянно.
Конечно, присутствует небольшая потеря качества, но по сравнению с тем, что размер файла был уменьшен в несколько десятков раз, это уже не играет большой роли. И новые форматы отвоевывают рынок — тот же hevc. JPEG все еще остается королем индустрии. Так что давайте разберемся, как конкретно всё это работает? Причем здесь психология зрения, и как хитрая математика экономит место.
К началу 80-х годов прошлого столетия компьютеры умели хранить и показывать цифровые изображения, однако для воплощения этого существовало множество различных решений.
Например, нельзя было просто отправить изображение с одного компьютера на другой. Для решения этой проблемы в 1986 году был собран комитет экспертов со всего мира под названием «Объединённая группа экспертов по фотографии» (Joint Photographic Experts Group, JPEG). Эта группа людей и создала стандарт сжатия цифровых изображений JPEG в 1992 году, который спасает нас до сих пор.
Прежде всего давайте разберёмся, почему вообще возможно сжать изображение так, чтобы наши глаза при этом не замечали изменений, вносимых форматом в фотографию. JPEG удаляет информацию, которую человеческий глаз плохо воспринимает.
Теперь стоит поговорить о том, как устроено наше зрение. Как известно, в глазу есть два типа восприимчивых к свету клеток: палочки и колбочки (rods and cones). Палочки плохо восприимчивы к свету, но играют решающую роль для зрения в условиях низкой освещенности, в то время как колбочки имеют цветовые рецепторы. Именно они обеспечивают нашим глазам цветное зрение. В каждом глазу имеется около 100 миллионов палочек и всего лишь 6 миллионов колбочек.
Как следствие, глаз гораздо более восприимчив к изменениям в яркости изображения и менее восприимчив к изменению в цвете. Поэтому при сжатии картинки можно использовать такую хитрость: во первых, отделить цвет от яркости, во вторых, убрать немного цвета, и в таком случае никто ничего не заметит. Именно на данной хитрости и основывается первый и очень важный этап сжатия, называемый цветовой субдискредитацией.
Но как именно нам отделить яркость от цвета? Как известно, каждый пиксель характеризуется тремя компонентами: R,G,B — по одной переменной для каждого цвета, которые могут принимать значения в диапазоне от 0 до 255.
Хитрость в том, что эту же информацию мы можем сохранить, используя другие три переменные: Y, Cb, Cr. Тогда мы без проблем можем преобразовать изображение с пикселями формата RGB в новый формат с другими компонентами Y,Cb,Cr. Здесь Y отвечает за яркость, а Cb и Cr- цветовые каналы. Таким образом, вычислив эти переменные, мы получаем три новых изображения, составленных из этих трех компонент.
Вычисление происходит по таким мудреным формулам, если интересно.
Такое разделение необходимо, чтобы дальше мы могли убрать часть деталей из цветовых каналов (составленных из Сb и Cr).Пока что никакие данные мы не удаляли, а математические преобразования из одного формата в другой являются обратимыми. Данные действия, конечно же, проделываются над всеми пикселями изображения.
Теперь мы и будем использовать особенность нашего зрения: воспринимать изменения в цвете хуже, чем изменения в яркости. Ранее мы получили из исходной картинки 2 цветовых переменных и одну яркостную.
Теперь делается еще один ход: каждые 4 пикселя в обоих цветовых изображениях объединяются в 1, тем самым удаляется повторяющаяся информация. В результате, детали, плохо воспринимаемые нашими глазами, т.е. обе цветовые составляющие (Cr и Сb), уменьшаются до ¼ своего исходного размера, а яркостная составляющая остаётся прежней. Таким образом, всего за два шага изображение становится в 2 раза меньше исходного размера
Было: 1+1+1=3
Стало: ¼+¼+1=1,5
При этом если сейчас собрать эти 3 составляющие в одно исходное изображение, то невооруженным глазом разницу между оригиналом и сжатым изображением заметить будет невозможно.
Теперь выполняется подготовка к самому важному, сложному и умному этапу. Для этого каждая из 3 наших картинок, составленных из яркостного и двух цветовых каналов, разбивается на блоки пикселей 8×8. Теперь алгоритмы сжатия должны каким-то образом понять, насколько много деталей в каждом из таких блоков. Если деталей мало, то можно закодировать меньшим количеством бит, уменьшая размер файла, а если деталей много, то наоборот.
Иными словами, если бы картины в музеях хранились в джипеге, то любая картина Ван Гога занимала бы меньше места, чем черный квадрат Малевича.
Такой анализ и производится с помощью штуки со страшным названием — дискретное косинусное преобразование. Прежде, чем переходить к нему, рассмотрим такой простой пример. У нас есть разноцветные полупрозрачные стеклышки. Накладывая их друг на друга, мы можем получить тот цвет, который нам нужен, т.е., например,чтобы получить фиолетовый цвет, нужно наложить синее стеклышко на красное. Такая же ситуация и в случае с алгоритмом.
Рассмотрим один из блоков 8х8. Все последующие действия будут выполняться для каждого из таких блоков. Такой блок содержит 64 пикселя. Оказывается, что любое простое монохромное изображение можно представить в виде комбинации вот таких 64 базовых картинок.
То есть, накладывая их друг на друга с разной степенью прозрачности, можно получить любую простую картинку 8х8 примерно так же, как и в примере со стеклышками.
Именно таким образом мы и можем перестроить любой наш блок 8х8 путём наложения этих базовых картинок друг на друга. При этом каждый из узоров умножается на число, являющееся показателем того, какая его часть используется при построении определенной картинки.
Суть алгоритма дискретного косинусного преобразования и заключается в вычислении данных чисел. На выходе получаем матрицу 8х8, состоящую из чисел, отображающих, насколько большой или не очень вклад каждого узора в данное изображение 8х8. Выглядит это примерно так. Прикольно, да?
Чем больше число, тем больший вклад базового изображения (узора), соответствующего данному числу.
Коэффициенты, находящиеся в левой верхней части матрицы отвечают за плавные переходы и более общие черты, а коэффициенты, лежащие в правой нижней части- за частые переходы, т.е. за тонкие детали. Если деталей в данном блоке оказывается мало, то коэффициенты, отвечающие за них (находящиеся в правой нижней части матрицы) будут равны нулям или близким к нулю значениям. (Именно на данном этапе отбрасывается огромная часть информации, не видимой человеческим глазом.) Это важный момент запомним.
Это немного напоминает составление фоторобота: нос номер 9, рот номер 13, глаза среднее между нумером 6 и 42.
Прежде, чем идти дальше, подведем промежуточные итоги. Что мы имеем на данный момент?
У нас есть матрица из 64 чисел, содержащих информацию о том, как именно нужно использовать базовые изображения. Если не считать этап цветовой субдискредитации, то пока что мы не отбрасывали существенное количество информации, а только определяли, что нужно отбросить.
Как это делается?
Для этого этапа используется вот такая таблица.
Называется таблица квантования. К квантовым компьютерам не имеет отношения. Не пугайтесь, какждется это послдений сложный термин на сегодня. Если по простому: она определяет какую часть из полученной прежде информации мы возьмем в итоговый файл. Смотрите: это матрица 8х8, содержащая коэффициенты, на которые мы делим числа из нашей исходной матрицы. Степень сжатия задаётся характеристиками таблицы квантования, т.е. чем больше коэффициенты в этой таблице, тем меньше будут числа в новой матрице. В зависимости от характеристик таблицы квантования мы можем уменьшить размер изображения до 95% от первоначального размера, но в таком случае, конечно, качество сжатого изображения будет далеко не самым высоким. Именно эта таблица и является основной настройкой jpeg, регулирующей степень сжатия.
Теперь переходим к квантованию, т.е. этапу, на котором будет производиться наибольшее сжатие. Здесь происходит сначала деление чисел из матрицы, которую мы получили на прошлом этапе, на определенные коэффициенты, соответствующие таблице квантования, а затем происходит округление полученных чисел до ближайшего целого (например: делим 560/4=140; -41/3=-13,7- округляем до целого, получаем -14 и т.
- Исходная матрица
- Таблица квантования
- Новая матрица
Если посмотреть на таблицу квантования, то можно увидеть, что самые большие числа расположены в правой нижней части таблицы. Это значит, что большего всего отбрасываются высокочастотные данные, т.е. отвечающие за те детали, которые наши глаза хуже всего воспринимают.
В результате этого процесса получается, что большая часть чисел нашей исходной матрицы стала равной нулю, так как числа, близкие к правому нижнему углу матрицы были слишком малы и после деления и округления обнулились. Остаются только числа, близкие к левому верхнему углу матрицы. На этом этапе и происходит самое существенное сжатие изображения, т.е. практически все данные, к которым наши глаза плохо восприимчивы, отбрасываются.
Далее используется зигзагообразное сканирование матрицы чисел, в результате чего получается числовая строка, в начале которой ненулевые значения, а в конце — нулевые.
Затем вместо того, чтобы перечислять все числа строки по порядку, мы используем алгоритм кодирования длин серий, благодаря которому можно не перечислять все нули, а просто назвать их количество.
Далее уже сжатая последовательность кодируется с помощью алгоритма Хаффмана. Это достаточно сложный процесс, но если говорить кратко, то нули кодируются меньшим количеством бит, а ненулевые элементы последовательности кодируются большим количеством бит.
Процесс сжатия завершён. Мы получили сжатое изображение в виде последовательности чисел.
Как же теперь вывести его на экран? Для этого необходимы все те же самые действия, но уже проделанные в обратном порядке: 1. Декодирование с помощью алгоритма Хаффмана, 2. Декодирование по методу длин серий, 3. Заполнение матрицы 8х8 коэффициентами зигзагообразным методом для каждого из блоков 8х8, 4. Умножение каждого числа матрицы на соответствующий коэффициент согласно таблице квантования, 5. Масштабирование компоненты цветов, 6.
Преобразование полученных значений Y, Cb и Cr для каждого пикселя в RGB и 7. Вывод изображения уже в формате JPEG на экран. Готово!
Подведём итоги. Как видите, при работе JPEG используется огромное количество нюансов: особенности строения глаза, математические методы сжатия, разложение в спектр.
Конечно, у JPEG есть достаточно большое количество недостатков: невозможность качественного сжатия текстовых изображений, ухудшение качества при повторном сохранении, но несмотря на все его многочисленные недостатки и почтенный возраст, он по сей день остаётся самым популярным форматом изображений в интернете, хотя сейчас ему на смену начали приходить другие, гораздо более продвинутые форматы, такие как HEIC, AV1, WebP и другие. Причины популярности JPEG в настоящее время, конечно, есть: он очень хорошо изучен за 30 лет существования, является бесплатным, а также всем понятен и привычен.
Post Views: 1 957
rle, lzw, по Хаффману. Сжатие с потерями.
Основные критерии выбора формата — совместимость с программами и компактность записи. Существует множество форматов для записи изображений. Условно их можно разделить на три категории: хранящие изображение в растровом виде (BMP, TIFF, PCX, PSD, JPEG), хранящие изображение в векторном виде (WMF) и те, что могут совмещать оба представления (EPS, PICT, CDR, AI, FH7 и др.).
Все форматы графических файлов можно разделить на два типа: растровые и векторные. Друг от друга они отличаются принципом формирования изображения.
В растровых
изображениях картинка складывается наподобие мозаики,
из отдельных точек (пикселей), каждая
из которых исчерпывающе определяется
2 основными параметрами: координатами
расположения и цветом. Наиболее близкой
аналогией растрового изображения
является изображение на экране
компьютерного монитора (или обычного
телевизора), которое создает электронный
луч, пробегающий последовательно по
каждой строке формируемого кадра
изображения (растра). Многие растровые
форматы обладают способностью нести
дополнительную информацию: различные
цветовые модели изображения, вектора,
альфа-каналы (дополнительный канал, с
помощью которого можно сохранять
выделенные или прозрачные области
изображения), слои различных типов,
интерлиньяж (возможность чересстрочного
показа изображения), анимацию, возможности
сжатия и многое другое.
Векторное изображение представляет собой совокупность отрезков кривых линий, которые описываются математическими выражениями, и цветных заливок. Проще говоря, чтобы компьютер нарисовал прямую линию, нужны координаты двух точек, которые соединяются по кратчайшему пути, для дуги задаются координаты центра окружности и радиус и т.д. Таким образом, векторная иллюстрация — это набор геометрических примитивов (простейших объектов, таких как линии, окружности, многогранники и тому подобное), использующихся для создания более сложных изображений.
Отсюда
и основное достоинство векторных
форматов — компактность полученных
файлов, а также высокое качество
полученных изображений, причем независимо
от разрешающей способности устройства
отображения.
В качестве недостатка
можно отметить определенную трудоемкость
при создании и редактировании сложных
элементов изображений, а также проблемы,
возникающие при распечатке векторных
изображений на некоторых принтерах.
BMP Формат BMP (от слова bitmap) был создан компанией Microsoft и широко используется в ОС Windows для растровой графики. Вам необходимо записать изображение в этом формате, если вы хотите использовать его в качестве фона вашего рабочего стола. Хотя в этом формате может применяться компрессия, большинство программ ее не используют. BMP-файлы с компрессией могут иметь расширение RLE. Без компрессии размер файла оказывается близок к максимальному. Такой же размер будет и у файла в формате PCX, предложенном компанией Z-Soft в программе PhotoFinish. Оба эти формата достаточно известны и могут быть использованы на платформе Macintosh, хотя были написаны для PC.
GIF Популярный
формат GIF разработан фирмой CompuServe как
не зависящий от аппаратного обеспечения.
Он предназначен для хранения растровых
изображений с компрессией. В одном файле
этого формата может храниться несколько
изображений, но обычно эта возможность
не используется. GIF-формат позволяет
записывать изображение «через строчку»
(In-terplaced), благодаря чему, имея только
часть файла, можно увидеть изображение
целиком, но с меньшим разрешением. Эта
возможность широко применяется в Сети.
Сначала вы видите картинку с грубым
разрешением, а по мере поступления новых
данных ее качество улучшается. Основное
ограничение формата GIF состоит в том,
что цветное изображение может быть
записано только в режиме 256 цветов. Для
полиграфии этого явно недостаточно.
JPEG Компрессия,
используемая в формате JPEG, необратимо
искажает изображение. Это, как правило,
не заметно при простом просмотре, но
становится явным при последующих
манипуляциях. Зато размер файла получается
от 10 до 500 раз меньше, чем BMP! Если вы
решили записать изображение в этом
формате JPEG, то лучше выполнить все
необходимые операции перед первой
записью файла.
При записи обычно
предлагается выбрать степень компрессии.
Здесь надо искать компромисс: чем сильнее
компрессия, тем больше искажения.
Кодирование длин серий (англ.
Run—length encoding, RLE) или Кодирование повторов — простой алгоритм сжатия данных, который оперирует сериями данных, то есть последовательностями, в которых один и тот же символ встречается несколько раз подряд. При кодировании строка одинаковых символов, составляющих серию, заменяется строкой, которая содержит сам повторяющийся символ и количество его повторов.Очевидно,
что такое кодирование эффективно для
данных, содержащих большое количество
серий, например, для простых графических
изображений, таких как иконки и графические
рисунки. Однако это кодирование плохо
подходит для изображений с плавным
переходом тонов, таких как фотографии.
Несмотря на это, JPEG
довольно эффективно его использует на
коэффициентах, которые остаются после
преобразования и квантования блоков
изображения.
Алгори́тм Ле́мпеля — Зи́ва — Ве́лча (
Описание.
Данный алгоритм при сжатии (кодировании)
динамически создаёт таблицу преобразования
строк: определённым последовательностям
символов (словам) ставятся в соответствие
группы бит фиксированной длины (обычно
12-битные). Таблица инициализируется
всеми 1-символьными строками (в случае
8-битных символов — это 256 записей). По
мере кодирования, алгоритм просматривает
текст символ за символом, и сохраняет
каждую новую, уникальную 2-символьную
строку в таблицу в виде пары код/символ,
где код ссылается на соответствующий
первый символ.
После того как новая
2-символьная строка сохранена в таблице,
на выход передаётся код первого символа.
Когда на входе читается очередной
символ, для него по таблице находится
уже встречавшаяся строка максимальной
длины, после чего в таблице сохраняется
код этой строки со следующим символом
на входе; на выход выдаётся код этой
строки, а следующий символ используется
в качестве начала следующей строки.Алгоритму
декодирования на входе требуется только
закодированный текст, поскольку он
может воссоздать соответствующую
таблицу преобразования непосредственно
по закодированному тексту.
Алгоритм
1. Инициализация словаря всеми возможными односимвольными фразами.Инициализация входной фразы w первым символом сообщения.
2. Считать очередной символ K из кодируемого сообщения.
3. Если КОНЕЦ_СООБЩЕНИЯ, то выдать код для w, иначе
4.
Если фраза wK
уже есть в словаре, то присвоить входной
фразе значение wK
и перейти к Шагу 2, иначе выдать код w,
добавить wK
в словарь, присвоить входной фразе
значение K
и перейти к Шагу 2.
Конец
Применение. На момент своего появления алгоритм LZW давал лучший коэффициент сжатия, для большинства приложений, чем любой другой хорошо известный метод того времени. Он стал первым широко используемым на компьютерах методом сжатия данных.Алгоритм был реализован в программе compress, которая стала более-менее стандартной утилитой Unix-систем приблизительно в 1986 году. Несколько других популярных утилит-архиваторов также используют этот метод или близкие к нему.В 1987 году алгоритм стал частью стандарта на формат изображений GIF. Он также может (опционально) использоваться в формате TIFF.В настоящее время, алгоритм содержится в стандарте PDF.
Huffman —
Сначала кажется что создание файла
меньших размеров из исходного без
кодировки последовательностей или
исключения повтора байтов будет
невозможной задачей. Но давайте мы
заставим себя сделать несколько
умственных усилий и понять алгоритм
Хаффмана ( Huffman ). Потеряв не так много
времени мы приобретем знания и
дополнительное место на дисках.
Сжимая файл по алгоритму Хаффмана первое что мы должны сделать — это необходимо прочитать файл полностью и подсчитать сколько раз встречается каждый символ из расширенного набора ASCII. Если мы будем учитывать все 256 символов, то для нас не будет разницы в сжатии текстового и EXE файла.
После подсчета частоты вхождения каждого символа, необходимо просмотреть таблицу кодов ASCII и сформировать мнимую компоновку между кодами по убыванию. То есть не меняя местонахождение каждого символа из таблицы в памяти отсортировать таблицу ссылок на них по убыванию. Каждую ссылку из последней таблицы назовем «узлом». В дальнейшем ( в дереве ) мы будем позже размещать указатели которые будут указывает на этот «узел».
Сжатие
данных с потерями — это метод сжатия данных, когда
распакованный файл отличается от
оригинального, но «достаточно близок»
для того, чтобы быть полезным каким-то
образом. Этот тип компрессии часто
используется в Интернете, особенно в
потоковой передаче данных и телефонии.
Эти методы часто называются кодеками
в этом контексте
Компрессия изображений
* Снижение глубины цвета
* Метод главных компонент
* Фрактальное сжатие (Существуют алгоритмы для сжатия изображения с помощью фракталов. Они основаны на идее о том, что вместо изображения можно хранить отображение сжатия, для которого это изображение является неподвижной точкой.)
* JPEG (При сжатии изображение переводится в цветовую систему Jpeg. Далее каналы изображения Cb и Cr, отвечающие за цвет, уменьшаются в 2 раза (по линейному масштабу). Уже на этом этапе необходимо хранить только четверть информации о цвете изображения.
Реже
используется уменьшение цветовой
информации в 4 раза или сохранение
размеров цветовых каналов как есть.
Количество программ, которые поддерживают
сохранение в таком виде, относительно
невелико.Далее цветовые каналы
изображения, включая черно-белый канал
Y,
разбиваются на блоки 8 на 8 пикселей.
Каждый блок подвергается дискретно-косинусному
преобразованию.
Полученные коэффициенты
подвергаются квантованию и упаковываются
с помощью кодов Хаффмана.Матрица,
используемая для квантования коэффициентов,
хранится вместе с изображением. Обычно
она строится так, что высокочастотные
коэффициенты подвергаются более сильному
квантованию, чем низкочастотные. Это
приводит к огрублению мелких деталей
на изображении. Чем выше степень сжатия,
тем более сильному квантованию
подвергаются все коэффициенты.)
* Вэйвлетная компрессия (Вейвлетное сжатие — общее название класса методов кодирования изображений, использующих двумерное вейвлет-разложение кодируемого изображения или его частей. Обычно подразумевается сжатие с потерей качества.Вейвлеты (от англ. wavelet), всплески (написание вэйвлеты уже почти не употребляется) — это математические функции, позволяющие анализировать различные частотные компоненты данных.)
— JPEG 2000 (—
графический формат, который вместо
дискретного косинусного преобразования,
характерного для JPEG,
использует технологию вейвлет-преобразования,
основывающуюся на представлении сигнала
в виде суперпозиции некоторых базовых
функций — волновых пакетов.
n
Иначе говоря, преобразование называется аффинным, если его можно получить следующим образом:
1. Выбрать «новый» базис пространства с «новым» началом координат v;
2. Каждой точке x пространства поставить в соответствие точку f (x), имеющую те же координаты относительно «новой» системы координат, что и x в «старой».
Свойства
* При аффинном преобразовании прямая переходит в прямую.
o Если размерность пространства n>= 2, то любое преобразование пространства (то есть биекция пространства на себя), которое переводит прямые в прямые, является аффинным. Это определение используется в аксиоматическом построении аффинной геометрии
* Частным случаем аффинных преобразований являются движения и преобразования подобия.
Преобразования координат в явном и
неявном виде широко используются в
компьютерной графике с целью описания
графического объекта в наиболее удобных
координатных системах, для изменения
масштаба элементов чертежа, построения
проекций пространственных образов,
направленной деформации объектов.
Аффинное преобразование (affine maping) – точечное взаимно-однозначное отображение плоскости на себя, при котором трем точкам, лежащим на одной прямой, соответствуют три точки, также лежащие на одной прямой. Аффинное преобразование переводит пересекающиеся прямые в пересекающиеся, параллельные — в параллельные. Плоскости в трехмерном пространстве при этом также остаются плоскостями, параллельные плоскости – параллельными. За исключением вырожденных случаев все точки первичной плоскости (или пространства) преобразуются и заполняют все точки вторичной плоскости.
Рассмотрим метод однородных координат. В основе этого метода лежит представление о том, что каждая точка в N-мерном пространстве может рассматриваться как проекция точки из (N+1)-мерного пространства. В частности, точка в трехмерном пространстве представляется четырьмя составляющими, например, ее координаты будут заданы как V=(x, y, z, w). Если w не равно 1, то декартовы координаты точки (X,Y,Z) получаются из соотношения6:
[
X Y Z 1 ] = [ (x/w) (y/w) (z/w) 1 ].
(IV.3)
Свойства однородных координат позволяют выражать с помощью единой матрицы все преобразования: сдвиги, повороты и даже проекции, а также любые сочетания преобразований в виде произведения матриц. Использование однородных координат позволяет применять единых математический аппарат для пространственных преобразований (поворотов, масштабирования, переноса) точек, прямых, квадратичных и бикубических поверхностей и линий (рис. IV.1).
В виде формулы:
В матричном виде:
JPEG — формат файла JPEG JFIF — документация GDAL
Краткое имя драйвера
JPEG
Зависимости сборки
(предоставлен внутренний libjpeg)
Формат JPEG JFIF поддерживается для чтения и пакетной записи, но
не обновлять на месте.
Файлы JPEG представлены в виде одной полосы (оттенки серого).
или трехканальные (RGB) наборы данных с байтовыми полосами.
Драйвер автоматически преобразует изображения с цветовым пространством YCbCr, CMYK или YCbCrK в RGB, если для параметра GDAL_JPEG_TO_RGB не задано значение NO (ДА По умолчанию). Когда преобразование цветового пространства в RGB выполнено, исходный цвет пробел указывается в метаданных SOURCE_COLOR_SPACE файла IMAGE_STRUCTURE домен.
Метаданные EXIF можно считывать из файлов JPEG (но это не приведет к изображение с географической привязкой, даже если EXIF_GPSLatitude и EXIF_GPSLongitude теги установлены). Но если файл привязки ESRI существует с расширением .jgw, .jpgw/.jpegw или .wld суффиксы будут прочитаны и использованы для установления геотрансформация изображения. Если доступен файл MapInfo .tab, также будет использоваться для географической привязки. Обзоры могут быть построены для файлов JPEG как внешний файл .ovr.
Драйвер также поддерживает «сжатую маску zlib, добавленную к файлу».
подход, используемый несколькими поставщиками данных для добавления битовой маски для идентификации
пиксели, которые не являются действительными данными. Дополнительную информацию см. в RFC 15: Band Masks.
подробности.
Драйвер может работать с битовой маской, где биты упорядочены со старшим битом первым (тогда как обычно по соглашению младший значащий бит идет первым). Водитель постарается автоматически определить эту ситуацию, но эвристика может дать сбой. В этом обстоятельство, вы можете установить параметр конфигурации JPEG_MASK_BIT_ORDER к МСБ. Битовую маску также можно полностью игнорировать, указав JPEG_READ_MASK на НЕТ.
Драйвер GDAL JPEG создан с использованием технологии jpeg от Independent JPEG Group.
библиотека. Также обратите внимание, что драйвер GeoTIFF поддерживает мозаичный TIFF с JPEG.
прессованные плитки. Это можно использовать для применения сжатия JPEG к наборам данных.
которые превышают максимальные размеры 65 535 x 65 535 пикселей для одного
изображение в формате JPEG.
Драйвер JPEG также можно использовать с libjpeg-turbo, версия libjpeg, API и ABI, совместимая с IJG libjpeg-6b, которая использует инструкции MMX, SSE и SSE2 SIMD для ускорения базового JPEG компрессия/декомпрессия.
Начиная с GDAL 3.4, поддержка чтения и записи для изображений JPEG с 12-битной выборкой включен по умолчанию (если также включена поддержка JPEG), используя внутреннюю библиотеку GDAL libjpeg (на основе IJG libjpeg-6b с дополнительными изменениями для поддержки 12-битных образцов). Поддержка JPEG с 12-битной выборкой не зависит от того, Поддержка 8-битного JPEG включается через внутреннюю IJG libjpeg-6b или внешнюю libjpeg. (например, libjpeg-турбо)
Метаданные XMP могут быть извлечены из файла, и будет храниться как необработанный XML-контент в домене метаданных xml:XMP.
встроенных эскиза EXIF (со сжатием JPEG) могут использоваться в качестве обзоров и генерируются GDAL.
Возможности драйвера
Поддерживает CreateCopy()
Этот драйвер поддерживает операцию GDALDriver::CreateCopy()
Поддерживает географическую привязку
Этот драйвер поддерживает географическую привязку
Поддерживает VirtualIO
Этот драйвер поддерживает операции виртуального ввода-вывода (/vsimem/ и т.
д.)
Метаданные цветового профиля
GDAL может работать со следующим цветовым профилем метаданные в домене COLOR_PROFILE:
Обратите внимание, что это свойство метаданных можно использовать только в исходном необработанном файле. данные пикселей. Если было выполнено автоматическое преобразование в RGB, цвет информация профиля не может быть использована.
Этот тег метаданных можно использовать в качестве параметров создания.
Управление ошибками
При декодировании libjpeg устойчив к некоторым ошибкам в JPEG datastream и попытается восстановить из них как можно больше. О таких ошибках сообщается как GDAL. Предупреждения, но при желании могут считаться истинными ошибками, установив Параметр конфигурации GDAL_ERROR_ON_LIBJPEG_WARNING имеет значение TRUE.
Открыть опции
Доступны следующие открытые опции:
USE_INTERNAL_OVERVIEWS=YES/NO : Использовать ли частичную декомпрессию DCT для создания обзоров.
По умолчанию ДА.APPLY_ORIENTATION=YES/NO : (GDAL >= 3.7) Использовать ли EXIF_Orientation элемент метаданных, чтобы повернуть/отразить изображение, чтобы применить ориентацию сцены. По умолчанию НЕТ (то есть изображение будет возвращено с ориентацией сенсора).
По умолчанию ДА.Опции создания
Файлы JPEGсоздаются с использованием кода драйвера «JPEG». Только байтовая полоса типы поддерживаются.
Только 1 (оттенки серого), 3 канала (ввод должен быть в цветовом пространстве RGB.
драйвер автоматически преобразует его в цветовое пространство YCbCr для хранения, и
выставит его обратно как RGB при чтении) или 4-полосный
(ввод уже должен быть в цветовом пространстве CMYK. Он будет отображаться как RGB при чтении
по умолчанию, если только GDAL_JPEG_TO_RGB параметр конфигурации
установлено значение НЕТ).
Создание файла JPEG реализовано пакетным методом (CreateCopy).
Цветовое пространство YCbCrK не поддерживается при создании.
Если источник
набор данных имеет маску без данных, он будет добавлен как сжатая маска zlib
в файл JPEG.
WORLDFILE=YES : Принудительное создание связанного мира ESRI файл (с расширением .wld).
КАЧЕСТВО=n : По умолчанию флаг качества установлен на 75, но это можно использовать для выбора других значений. Значения должны быть в диапазон 10-100. Низкие значения приводят к более высоким коэффициентам сжатия, но хуже качество изображения. Значения выше 95 не намного лучше качество, но может, но существенно больше.
PROGRESSIVE=ON : Включено создание прогрессивных JPEG. В некоторых случаях они будут отображать изображение с уменьшенным разрешением в таких средствах просмотра, как как Netscape и Internet Explorer, прежде чем полный файл будет скачал. Однако некоторые приложения не могут читать прогрессивные файлы JPEG. вообще. GDAL может читать прогрессивные JPEG, но не использует преимущества их прогрессивный характер.
INTERNAL_MASK=YES/NO : По умолчанию, при необходимости, внутренняя маска в написан подход «сжатая маска zlib, добавленная к файлу». для идентификации пикселей, которые не являются допустимыми данными. Это можно отключить, установив для этой опции значение NO.
АРИФМЕТИКА=ДА/НЕТ : Включить арифметику кодирование. Не включено во всех сборках libjpeg из-за возможных юридических ограничения.
БЛОК=1…16 : (libjpeg >= 8c) Блок DCT размер. Возможны все значения от 1 до 16. По умолчанию 8 (базовый формат). Значение, отличное от 8, приведет к созданию файлов, несовместимых с версии до libjpeg 8c.
COLOR_TRANSFORM=RGB или RGB1 : (libjpeg >= 9). Установите значение RGB1 для RGB без потерь. Примечание: это создаст файлы несовместим с версиями до libjpeg 9.
SOURCE_ICC_PROFILE=значение : профиль ICC, закодированный в Base64.
COMMENT=строка : Строка для встраивания в комментировать маркер JPEG. При чтении такие строки выставляются в Элемент метаданных COMMENT.
EXIF_THUMBNAIL=ДА/НЕТ : Следует ли создать миниатюру EXIF (обзор), сам сжатый JPEG. По умолчанию НЕТ. Если включено, максимальный размер миниатюры будет 128, если ни THUMBNAIL_WIDTH, ни THUMBNAIL_HEIGHT не указано.
THUMBNAIL_WIDTH=n : Ширина эскиза. Учитывается, только если EXIF_THUMBNAIL=YES.
THUMBNAIL_HEIGHT=n : Высота миниатюра. Учитывается, только если EXIF_THUMBNAIL=YES.
WRITE_EXIF_METADATA=YES/NO : (Начиная с GDAL 2.3). Стоит ли записывать элементы метаданных EXIF_xxxx в сегмент EXIF. По умолчанию ДА.
Метки EXIF и GPS
В приведенных ниже таблицах перечислены теги EXIF и GPS, которые можно записать.
В столбце «Имя элемента метаданных» представлено имя метаданных.
элемент для присоединения к исходному набору данных.Столбец «Шестнадцатеричный код» представляет собой значение соответствующего TIFF EXIF/GPS тег (только для справки)
Столбец «Тип» связан с типом TIFF.
ASCII для текстовых значений, заканчивающихся NUL (для фиксированного тег длины, длина включает в себя эти завершающие NUL символы). например EXIF_Make=the_make
BYTE/UNDEFINED для значений, которые могут быть сделаны из любого значения байта. Значение соответствующего элемента метаданных GDAL должно быть строкой. значений в шестнадцатеричном формате, например EXIF_GPSVersionID=0x02 0x00 0х00 0х00. GDAL также принимает строку ASCII: например. EXIF_ExifVersion=0231
SHORT для целочисленных значений без знака в диапазоне [0,65535]. Некоторый теги могут принимать несколько значений, и в этом случае они должны быть разделены пробелом.
LONG для целочисленных значений без знака в диапазоне [0,4294967295].
Некоторые теги могут принимать несколько значений, и в этом случае они должны быть
разделены пробелом.RATIONAL для положительных значений с плавающей запятой. Некоторые теги могут принимать несколько значений, и в этом случае они должны быть разделены пространство. например EXIF_GPSLatitude=492 3,5
SRATIONAL для положительных или отрицательных значений с плавающей запятой. Некоторый теги могут принимать несколько значений, и в этом случае они должны быть разделены пробелом.
Когда элемент принимает фиксированное количество значений и больше при условии, что они будут усечены с предупреждением. В случае, если они предоставлено меньше значений, чем необходимо, они будут дополнены соответствующие пробелы/нули
Столбец «Количество значений» — это количество значений для элемента. Может быть «переменным», если нет ограничений, или фиксированным значением. За Type=ASCII, фиксированное значение включает завершающий NUL байт, поэтому количество фактических печатных символов равно количеству значений — 1.
Столбец «Необязательно» указывает, должен ли пункт присутствовать («Обязательно»), является «Рекомендуемым» или «Необязательным». GDAL не применяет это.
элемент для присоединения к исходному набору данных.
Некоторые теги могут принимать несколько значений, и в этом случае они должны быть
разделены пробелом.
Многие элементы имеют дополнительные ограничения на действительный контент, которые не выражены в нижеприведенных таблицах. Обратитесь к спецификации EXIF для получения дополнительной информации. Информация.
Имя элемента метаданных | Шестнадцатеричный код | Тип | Количество значений | Дополнительно |
|---|---|---|---|---|
EXIF_Document_Name | 0x010D | ASCII | переменная | Дополнительно |
EXIF_ImageDescription | 0x010E | ASCII | переменная | Рекомендуемый |
EXIF_Make | 0x010F | ASCII | переменная | Рекомендуемый |
EXIF_Model | 0x0110 | ASCII | переменная | Рекомендуемый |
EXIF_ориентация | 0x0112 | КОРОТКИЙ | 1 | Рекомендуемый |
EXIF_XРазрешение | 0x011A | РАЦИОНАЛЬНЫЙ | 1 | Обязательно |
EXIF_YРазрешение | 0x011B | РАЦИОНАЛЬНЫЙ | 1 | Обязательно |
EXIF_ResolutionUnit | 0x0128 | КОРОТКИЙ | 1 | Обязательно |
EXIF_TransferFunction | 0x012D | КОРОТКИЙ | 768 | Дополнительно |
EXIF_Software | 0x0131 | ASCII | переменная | Дополнительно |
EXIF_DateTime | 0x0132 | ASCII | 20 | Рекомендуемый |
EXIF_Artist | 0x013B | ASCII | переменная | Дополнительно |
EXIF_WhitePoint | 0x013E | РАЦИОНАЛЬНЫЙ | 2 | Дополнительно |
EXIF_PrimaryChromaticities | 0x013F | РАЦИОНАЛЬНЫЙ | 6 | Дополнительно |
EXIF_YCbCrКоэффициенты | 0x0211 | РАЦИОНАЛЬНЫЙ | 3 | Дополнительно |
EXIF_YCbCrПозиционирование | 0x0213 | КОРОТКИЙ | 1 | Обязательно |
EXIF_ReferenceBlackWhite | 0x0214 | РАЦИОНАЛЬНЫЙ | 6 | Дополнительно |
EXIF_Авторское право | 0x8298 | ASCII | переменная | Дополнительно |
EXIF_ExposureTime | 0x829A | РАЦИОНАЛЬНЫЙ | 1 | Рекомендуемый |
EXIF_FNumber | 0x829Д | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_ExposureProgram | 0x8822 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_SpectralSensitivity | 0x8824 | ASCII | переменная | Дополнительно |
EXIF_ISOSРейтинги скорости | 0x8827 | КОРОТКИЙ | переменная | Дополнительно |
EXIF_OECF | 0x8828 | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_SensitivityType | 0x8830 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_StandardOutputSensitivity | 0x8831 | ДЛИННЫЙ | 1 | Дополнительно |
EXIF_RecommendedExposureIndex | 0x8832 | ДЛИННЫЙ | 1 | Дополнительно |
EXIF_ISOSpeed | 0x8833 | ДЛИННЫЙ | 1 | Дополнительно |
EXIF_ISOSpeedLatitudeyyy | 0x8834 | ДЛИННЫЙ | 1 | Дополнительно |
EXIF_ISOSpeedLatitudezzz | 0x8835 | ДЛИННЫЙ | 1 | Дополнительно |
EXIF_ExifVersion | 0x9000 | НЕОПРЕДЕЛЕНО | 4 | Обязательно |
EXIF_DateTimeOriginal | 0x9003 | ASCII | 20 | Дополнительно |
EXIF_DateTimeDigitized | 0x9004 | ASCII | 20 | Дополнительно |
EXIF_OffsetTime | 0x9010 | ASCII | 7 | Дополнительно |
EXIF_OffsetTimeOriginal | 0x9011 | ASCII | 7 | Дополнительно |
EXIF_OffsetTimeDigitized | 0x9012 | ASCII | 7 | Дополнительно |
EXIF_ComponentsConfiguration | 0x9101 | НЕОПРЕДЕЛЕНО | 4 | Обязательно |
EXIF_CompressedBitsPerPixel | 0x9102 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_ShutterSpeedValue | 0x9201 | SRATIONAL | 1 | Дополнительно |
EXIF_ApertureValue | 0x9202 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_BrightnessValue | 0x9203 | SRATIONAL | 1 | Дополнительно |
EXIF_ExposureBiasValue | 0x9204 | SRATIONAL | 1 | Дополнительно |
EXIF_MaxApertureValue | 0x9205 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_SubjectDistance | 0x9206 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_MeteringMode | 0x9207 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_LightSource | 0x9208 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_Flash | 0x9209 | КОРОТКИЙ | 1 | Рекомендуемый |
EXIF_FocalLength | 0x920A | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_SubjectArea | 0x9214 | КОРОТКИЙ | переменная | Дополнительно |
EXIF_MakerNote | 0x927С | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_UserComment | 0x9286 | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_SubSecTime | 0x9290 | ASCII | переменная | Дополнительно |
EXIF_SubSecTime_Original | 0x9291 | ASCII | переменная | Дополнительно |
EXIF_SubSecTime_Digitized | 0x9292 | ASCII | переменная | Дополнительно |
EXIF_FlashpixВерсия | 0xA000 | НЕОПРЕДЕЛЕНО | 4 | Обязательно |
EXIF_ColorSpace | 0xA001 | КОРОТКИЙ | 1 | Обязательно |
EXIF_PixelXDimension | 0xA002 | ДЛИННЫЙ | 1 | Обязательно |
EXIF_PixelYDimension | 0xA003 | ДЛИННЫЙ | 1 | Обязательно |
EXIF_RelatedSoundFile | 0xA004 | ASCII | 13 | Дополнительно |
EXIF_FlashEnergy | 0xA20B | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_SpatialFrequencyResponse | 0xA20C | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_FocalPlaneXResolution | 0xA20E | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_FocalPlaneYResolution | 0xA20F | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_FocalPlaneResolutionUnit | 0xA210 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_SubjectLocation | 0xA214 | КОРОТКИЙ | 2 | Дополнительно |
EXIF_ExposureIndex | 0xA215 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_SensingMethod | 0xA217 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_FileSource | 0xA300 | НЕОПРЕДЕЛЕНО | 1 | Дополнительно |
EXIF_SceneType | 0xA301 | НЕОПРЕДЕЛЕНО | 1 | Дополнительно |
EXIF_CFAPattern | 0xA302 | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_CustomRendered | 0xA401 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_ExposureMode | 0xA402 | КОРОТКИЙ | 1 | Рекомендуемый |
EXIF_WhiteBalance | 0xA403 | КОРОТКИЙ | 1 | Рекомендуемый |
EXIF_DigitalZoomRatio | 0xA404 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_FocalLengthIn35mmFilm | 0xA405 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_SceneCaptureType | 0xA406 | КОРОТКИЙ | 1 | Рекомендуемый |
EXIF_GainControl | 0xA407 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_Контраст | 0xA408 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_Saturation | 0xA409 | КОРОТКИЙ | 1 | Дополнительно |
EXIF_Sharpness | 0xA40A | КОРОТКИЙ | 1 | Дополнительно |
EXIF_DeviceSettingDescription | 0xA40B | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_SubjectDistanceRange | 0xA40C | КОРОТКИЙ | 1 | Дополнительно |
EXIF_ImageUniqueID | 0xA420 | ASCII | 33 | Дополнительно |
EXIF_CameraOwnerName | 0xA430 | ASCII | переменная | Дополнительно |
EXIF_BodySerialNumber | 0xA431 | ASCII | переменная | Дополнительно |
EXIF_LensSpecification | 0xA432 | РАЦИОНАЛЬНЫЙ | 4 | Дополнительно |
EXIF_LensMake | 0xA433 | ASCII | переменная | Дополнительно |
EXIF_LensModel | 0xA434 | ASCII | переменная | Дополнительно |
EXIF_LensSerialNumber | 0xA435 | ASCII | переменная | Дополнительно |
GPS-метки:
Имя элемента метаданных | Шестнадцатеричный код | Тип | Количество значений | Дополнительно |
|---|---|---|---|---|
EXIF_GPSVersionID | 0x0000 | БАЙТ | 4 | Дополнительно |
EXIF_GPSLatitudeRef | 0x0001 | ASCII | 2 | Дополнительно |
EXIF_GPSLatitude | 0x0002 | РАЦИОНАЛЬНЫЙ | 3 | Дополнительно |
EXIF_GPS LongitudeRef | 0x0003 | ASCII | 2 | Дополнительно |
EXIF_GPSДолгота | 0x0004 | РАЦИОНАЛЬНЫЙ | 3 | Дополнительно |
EXIF_GPSAltitudeRef | 0x0005 | БАЙТ | 1 | Дополнительно |
EXIF_GPSВысота | 0x0006 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_GPSTimeStamp | 0x0007 | РАЦИОНАЛЬНЫЙ | 3 | Дополнительно |
EXIF_GPSСпутники | 0x0008 | ASCII | переменная | Дополнительно |
EXIF_GPSStatus | 0x0009 | ASCII | 2 | Дополнительно |
EXIF_GPSMeasureMode | 0x000A | ASCII | 2 | Дополнительно |
EXIF_GPSDOP | 0x000B | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_GPSpeedRef | 0x000C | ASCII | 2 | Дополнительно |
EXIF_GPSскорость | 0x000D | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_GPSTrackRef | 0x000E | ASCII | 2 | Дополнительно |
EXIF_GPSTrack | 0x000F | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_GPSImgDirectionRef | 0x0010 | ASCII | 2 | Дополнительно |
EXIF_GPSImgDirection | 0x0011 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_GPS MapDatum | 0x0012 | ASCII | переменная | Дополнительно |
EXIF_GPSDestLatitudeRef | 0x0013 | ASCII | 2 | Дополнительно |
EXIF_GPSDestширота | 0x0014 | РАЦИОНАЛЬНЫЙ | 3 | Дополнительно |
EXIF_GPSDestLongitudeRef | 0x0015 | ASCII | 2 | Дополнительно |
EXIF_GPSDestLongitude | 0x0016 | РАЦИОНАЛЬНЫЙ | 3 | Дополнительно |
EXIF_GPSDestBearingRef | 0x0017 | ASCII | 2 | Дополнительно |
EXIF_GPSDestBearing | 0x0018 | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
EXIF_GPSDestDistanceRef | 0x0019 | ASCII | 2 | Дополнительно |
EXIF_GPSDestDistance | 0x001A | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
Метод обработки EXIF_GPS | 0x001B | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_GPSAreaInformation | 0x001C | НЕОПРЕДЕЛЕНО | переменная | Дополнительно |
EXIF_GPSDateStamp | 0x001D | ASCII | 11 | Дополнительно |
EXIF_GPSDдифференциал | 0x001E | КОРОТКИЙ | 1 | Дополнительно |
EXIF_GPSHPositioningError | 0x001F | РАЦИОНАЛЬНЫЙ | 1 | Дополнительно |
Метаданные FLIR
Новое в версии 3.
3.
, закодированные в соответствии с соглашением FLIR (инфракрасные изображения).
в домене метаданных FLIR .
Поддерживаются метаданные из следующих разделов:
Заголовок
Необработанные данные
Информация о камере
Информация о палитре
GPSИнформация
Подробную информацию см. на странице https://exiftool.org/TagNames/FLIR.html.
Данные теплового изображения, сохраненные либо в виде необработанных данных, либо в формате PNG, отображаются как
Поднабор данных GDAL с именем JPEG:"filename.jpg":FLIR_RAW_THERMAL_IMAGE
См. также
Независимая группа JPEG
libjpeg-турбо
GTiff — формат файла GeoTIFF
EXIF v2.31 спецификация
404: Страница не найдена
Страница, которую вы пытались открыть по этому адресу, похоже, не существует.
Обычно это результат плохой или устаревшей ссылки. Мы приносим свои извинения за доставленные неудобства.
Что я могу сделать сейчас?
Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:
Поиск- Пожалуйста, свяжитесь с нами, чтобы сообщить, что эта страница отсутствует, или используйте поле выше, чтобы продолжить поиск
- Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, WhatIs.com.
- Посетите нашу домашнюю страницу и просмотрите наши технические темы
Просмотр по категории
Сеть
- межсоединение центра обработки данных (DCI)
Технология соединения центров обработки данных (DCI) объединяет два или более центров обработки данных для совместного использования ресурсов.
- Протокол маршрутной информации (RIP)
Протокол маршрутной информации (RIP) — это дистанционно-векторный протокол, в котором в качестве основной метрики используется количество переходов.
- доступность сети
Доступность сети — это время безотказной работы сетевой системы в течение определенного интервала времени.
Безопасность
- кража учетных данных
Кража учетных данных — это тип киберпреступления, связанный с кражей удостоверения личности жертвы.
- суверенная идентичность
Самостоятельная суверенная идентификация (SSI) — это модель управления цифровой идентификацией, в которой отдельные лица или предприятия владеют единолично …
- Сертифицированный специалист по безопасности информационных систем (CISSP)
Сертифицированный специалист по безопасности информационных систем
(CISSP) — это сертификат информационной безопасности, разработанный …
ИТ-директор
- рассказывание историй о данных
Рассказывание историй о данных — это процесс перевода анализа данных в понятные термины с целью повлиять на деловое решение.
.. - оншорный аутсорсинг (внутренний аутсорсинг)
Оншорный аутсорсинг, также известный как внутренний аутсорсинг, представляет собой получение услуг от кого-то вне компании, но в пределах …
- FMEA (анализ видов и последствий отказов)
FMEA (анализ видов и последствий отказов) представляет собой пошаговый подход к сбору сведений о возможных точках отказа в …
..HRSoftware
- самообслуживание сотрудников (ESS)
Самообслуживание сотрудников (ESS) — это широко используемая технология управления персоналом, которая позволяет сотрудникам выполнять множество связанных с работой …
- платформа обучения (LXP)
Платформа обучения (LXP) — это управляемая искусственным интеллектом платформа взаимного обучения, предоставляемая с использованием программного обеспечения как услуги (…
- Поиск талантов
Привлечение талантов — это стратегический процесс, который работодатели используют для анализа своих долгосрочных потребностей в талантах в контексте бизнеса .
Структура jpeg файла: Visual Basic с нуля. Формат графического файла JPG (JFIF).
