Pull to refresh

Comments 20

Да, сразу видна работа нейросети. Сложный объект в виде номера комнаты размазался и замылился, как нечто инородное и нетипичное для фотографий. А косые линии под разными углами передаются отлично. Возможно, в библиотеку обучения нужно добавить побольше текстов, чтобы нейросеть лучше узнавала их не пыталась смазывать.
Поддерживаю!
JPEG сжал нормально, номер оказался читабельным, а нейросеть смылила всё, даже непонятно, что это номер.
А ведь это уже не та же самая картинка с огрехами компрессии, а другая, просто очень похожая. А вообще, конечно, очень круто.
Где же это он читаемый у JPEG? Разве что на максимальном битрейте (2 бита на пиксель — последняя строчка) но на нем он и у нейросети тоже такой же «условно читаемыей», по крайней мере у первых 2х вариантов (без энтропии).
Не знаю, мой парсер находит там цифры, может когнитивные способности поднатасканы чуть более ваших, не знаю…
Издеваетесь что-ли? Вот тут вот видите цифры не «подглядывая» в оригинал?
image

Если и ведите, то разве что «видите» в кавычках — их мозг по памяти дорисовывает. Любит он такие штуки выкидывать и часто «видишь», то чего глаза на самом деле не видят.
Чтобы от таких «глюков» избавиться — нужно слепой тест проводить: показывать картинку людям не видевшим оригинала и спрашивать, что они там видят.
Как и JPEG, это сжатие не очень подходит для мелких особенностей. Особенно странно выглядела бы попытка взять цифры толщиной 1 пиксель на фоне.
З.Ы. Нашел свои образцы ч/б картинок — с цифрами все нормально.
Хм… а почему сравнивали JPEG, а не какой-нить JPEG2000 или ещё что-нить из новенького? Тот же JPEG2000 даёт гораздо лучшее изображение, а артефакты гораздо приятнее для глаза.
Как ни забавно, наилучших результатов в сжатии картинок добиваются даже не wavelet-кодеки типа JP2K, а натравленный на одиночный кадр H265.
Может целесообразнее использовать нейронные сети для ускорения фрактального сжатия? Там основная проблема в поиске похожих блоков без учёта афинных преобразований. Вроде нейронные сети как раз сильны в поиске шаблонов?
Из занудства: может, стоит всё-таки писать RD-кривая вместо «скорость-искажение»? Скорости там вообще ни в каком виде нет.
Дома какие-то, буковки- лучше бы показали как она шакала сжимает.
В начале 2000хх (примерно 1999-2003) натыкался на программку фрактального сжатия картинок.
Огромнейший минус был один — без нее открыть фото потом было невозможно.
Помнится 400кб картинку без особых потерь сжимали до как бы не 10кб, на экране разницы особо заметно не было.
Ну и второй — «разжимала» она ее потом до 4Мб что ли… (для jpg)
Иначе были огромные потери качества.
Т.е. сжимала нормально, но обратно… Уже тогда я понял что держать коллекцию картинок в формате непонятного ПО смысла нет, поэтому наигравшись забросил.
Тоже помню такую. Еще формат файлов у нее был .fif (Fractal Image Format)
Шутка про Крысолов.
Всё-таки за прототип Холли нужно было взять Гугл, а не Мелкомягких
Некогда (еще в конце 90-х, примерно одновременно с рождением mp3) подобный трюк попытались проделать японцы (то ли Yamaha, то ли еще круче кто-то). Формат VQF придумали. А суть, как я понял, была такая: «А давайте проанализируем много-много музыки, разобъем на небольшие фреймы, и из самых часто встречающихся сделаем что-то типа словаря. Ну и писать в файл будем ссылку на этот „словарный сэмпл“, плюс сжатую (с потерями) дельту от него. „Словарь“ вышел небольшой — около 2 Мб, ЕМНИП. Звучало недурно, и что характерно, на тот момент декодирование было менее ресурсоемко чем для mp3. Но… Не взлетело. А мне вот запомнилось. Красота идеи. И да, плеер еще такой был, который в это умел. Я это к чему: история — она же по спирали, может у Google получится.
kJofol GUI - девяностые, на минуточку!
image
Круть. Нонешным дизайнерам бы поучиться.
А для меня эталоном дизайна плеера остаётся никсовый Rhythmbox, такой себе iTunes без свистелок и перделок, и при этом не требующий доработки напильником, в отличие от виндового foobar2000.
Sign up to leave a comment.

Articles