Неквадратные пикселы. это что за зверь?
всю свою сознательную жизнь думал что пикселы всегда квадратные.это ты неправильно думал
в телевизоре они изначально неквадратные
на нормальных DVD соотношение сторон почти всегда не соответствует разрешению, ибо стандарт разрабатывался для аналоговых теликов.
есть такая фишка в ФШ image>>pixel aspect ratio
> всю свою сознательную жизнь думал что пикселы всегда квадратные.
Значит, твоя сознательная жизнь началась после нашествия VGA.
---
...Я работаю антинаучным аферистом...
Значит, твоя сознательная жизнь началась после нашествия VGA.
---
...Я работаю антинаучным аферистом...
Гыгыгы.
А как ещё-то?
А как ещё-то?
видимо, ты никогда не конфигурировал mplayer или vlc =)
не особо, да...
просто как-то за тенденцией пошел
640х480
800х600
1024х768
...
1600х1200
и мониторы 4х3
1280х1024 конечно выпадает....
вот такая простая арифметика
просто как-то за тенденцией пошел
640х480
800х600
1024х768
...
1600х1200
и мониторы 4х3
1280х1024 конечно выпадает....
вот такая простая арифметика
да, именно.
это как?Все просто. Реально пикселей - 576x720, но в видеопотоке (а иногда это можно сделать и в контейнере, но не в каждом) прописано правильное AR. Нормальный декодер берет картинку и налету поризводит интерполяцию до этого AR, обычно в сторону увеличения с сохранением либо ширины, либо высоты. Кривой декодер на AR забивает и показывает картинку как есть.
Вообще, манипуляции с AR - один из способов запихивать по десятку фильмов на один ДВД - фильмы кодируются в формате 352 × 576 , но им прописывается AR 4:3 или 16:9, и многие люди не видят разницы, хотя объем уменьшается в 2 раза.
да, именно.На VGA-мониторе 256-цветные режимы были разрешений: 320x200, 320x240 и 360x400. ^_^
да, когда год назад я впервые начал смотреть фильмы на компе и пользовался каким-то говёным плеером типа media player classic, который двд-менюшки не держит нормально, удивлялся, почему с пиратских дисков "8 B-movies in 1" открываются в виде такой полосочки вдвое уже =)
У меня media player classic как минимум один такой диск показывает нормально (других просто нету); вообще, никаких проблем у него с сохранением AR и с менбюшками не замечал. Что я сделал не так 
хотя объем уменьшается в 2 раза.По-твоему, вдвое меньше пикселей при том же качестве - это вдвое меньше объём? Это справедливо только для несжатого видео
ты неправ, это неверно и для несжатого видео
потому что забываем про аудио =)
если же рассматривать только видеочасть, то всё правильно, если оценивать качество потока в "битах на пиксел".
потому что забываем про аудио =)
если же рассматривать только видеочасть, то всё правильно, если оценивать качество потока в "битах на пиксел".
если оценивать качество потока в "битах на пиксел".То есть, lossless-сжатие делает некачественный поток?
Я имею в виду то же, что происходит, когда сжимаешь неподвижную одноцветную картинку - никогда не замечал, что неподвижный чёрный экран сжимается гораздо сильнее при том же качестве, чем фильм (а при том же битрейте качество неподвижного чёрного экрана гораздо выше)?
Кодеку вообще-то есть разница, что жать - или это беспорядочный набор цветных пикселей, или картинка с сильно отличающимися пикселями, или картинка со слабо отличающимися пикселями
И за счёт выкидывания каждого второго пикселя ты в большинстве случаев выиграешь порядка 10-20% (как и за счёт выкидывания каждого второго кадра а никак не 50%
Я имею в виду то же, что происходит, когда сжимаешь неподвижную одноцветную картинку - никогда не замечал, что неподвижный чёрный экран сжимается гораздо сильнее при том же качестве, чем фильм (а при том же битрейте качество неподвижного чёрного экрана гораздо выше)?
При масштабировании разрешения в сторону уменьшения теряется часть деталей, и поэтому нельзя сказать однозначно действительно ли ухудшится качество картинки. Оно вполне может и улучшиться. Но в среднем можно говорить, что качество останется на том же уровне, и размер видеочасти уменьшится в 2 раза.
И за счёт выкидывания каждого второго пикселя ты в большинстве случаев выиграешь порядка 10-20% (как и за счёт выкидывания каждого второго кадра а никак не 50%
Ссылку? Это весьма неочевидное утверждение.
Может, за год он сильно развился? Тогда и vlc, скажем, херово поддерживал менюшки. А может, у меня не vlc был, а лайт-аллой какой-нибудь. Какак разница, все директшоу-быдлоплееры одинаковы.
Ссылку?Ссылку, к сожалению, не могу. Но есть личный опыт, довольно большой.
А поставить эксперимент слабо?
разница приблизительно в два раза, даже ближе к точным 50%, чем я ожидал.
Пережимал Irfan view, Lanczos filter
разница приблизительно в два раза, даже ближе к точным 50%, чем я ожидал.
Пережимал Irfan view, Lanczos filter
Оно вполне может и улучшитьсяНо размер уменьшится далеко не в два раза, а процентов на 10. За счёт того, что пиксели будут отличаться гораздо сильнее, чем раньше.
И за счёт выкидывания каждого второго пикселя ты в большинстве случаев выиграешь порядка 10-20% (как и за счёт выкидывания каждого второго кадра
Ниасилил. Ты в курсе, что у кодеков бывают регулируемые настройки?
сделай плз то же самое, но с какой-нибудь фоткой, это будет более достоверным
лучше в формате BMP, потом заархивированной чем-нибудь.
lossy-кодеки пока не рассматриваем
лучше в формате BMP, потом заархивированной чем-нибудь.
lossy-кодеки пока не рассматриваем
За счёт того, что пиксели будут отличаться гораздо сильнее, чем раньше.Спорное утверждение
Ты в курсе, что у кодеков бывают регулируемые настройки?Это ты к чему?
Если сжимать с другими настройками и с другим уровнем качества (и вообще другим кодеком то бессмысленно говорить о том, чем отличаются случаи с 720*576 и 360*576.
Давай уж лучше не будем менять настройки кодека и сожмём им две картинки - исходную 720*576 и ту же, с выкинутым каждым вторым пикселем 360*288; после чего и посмотрим на результат - как будет отличаться объём, если в кодеке настраивали уровень качества; или качество, если настраивали битрейт.
А поставить эксперимент слабо?Слабо, нет у меня под рукой несжатого куска фильма.
ПережималТы пережимал картинку, а не видео.
Впрочем, даже это несущественно перед лицом того факта, что мы говорили о фильмах, а ты жал скриншоты - это уже совсем другая история.
ЗЫ: А уровень качества чем выставлял?
у меня фоток несжатых на работе нет
Ну и не надо тут тогда примеры свои приводить
а мне лень прогу к своему Никону ставить =)
Какую прогу, вы о чём?
То есть, lossless-сжатие делает некачественный поток?Да, кстати, а о каком-таком lossless-сжатии мы говорим? Каким кодеком жмём?
прогу, нужную для перевода упакованного никоновского RAW в более удобоваримый формат, например, в BMP
Давай уж лучше не будем менять настройки кодека и сожмём им две картинки - исходную 720*576 и ту же, с выкинутым каждым вторым пикселем 360*288; после чего и посмотрим на результат - как будет отличаться объём, если в кодеке настраивали уровень качества; или качество, если настраивали битрейт.
Давай, попробуй. Только я не знаю, как мерять "качество" видео, тем более, разного размера. Кроме того, я не помню адекватных кодеков в которых можно напрямую сказать "закодируй с херовым качеством" или "закодируй с отличным качеством" и все параметры подберутся автоматически.
Самым разумным здесь является кодирование с одним и тем же bpp, а он даст соответственно вдвое меньший или больший объем.
Да, кстати, а о каком-таком lossless-сжатии мы говорим? Каким кодеком жмём?Да о каком угодно.
Мне не нравится твоё определение качества, как количество байт на пиксель. По твоему определению, если я сделаю, например, bmp 10000*10000, залитый чёрным цветом, и запихаю это в winrar - в том, что будет на выходе, никакого исходного качества вообще не останется.
он хочет кодирование lossless-кодеком
можно попробовать MSU_Lossless :
http://www.artmech.com/pavel/video/codecs_test/index.htm
можно попробовать MSU_Lossless :
http://www.artmech.com/pavel/video/codecs_test/index.htm
Да о каком угодно.Э, не. Существует не так много lossless-кодеков, и на практике мало кто ими пользуется. Так о каком речь?
Только я не знаю, как мерять "качество" видео, тем более, разного размераНа глаз. Хотя да, будет сложно.
Кроме того, я не помню адекватных кодеков в которых можно напрямую сказать "закодируй с херовым качеством" или "закодируй с отличным качеством" и все параметры подберутся автоматическиВ большинстве кодеков есть три варианта сжатия (если не учитывать огромное количество мелких настроек, которые могут быть свои для каждого варианта) - закодировать с указанным битрейтом; закодировать в два прохода с указанным размером выходного файла, или закодировать с указанным процентом потерь.
он хочет кодирование lossless-кодекомДа ничего я не хочу.
Тогда пользуйся понятием bpp и уменьшай размер видео в 2 раза.
Так о каком речь?Ты читать умеешь?
Ты решил определить качество, как количество байт на пиксель; я не согласился с твоим определением, потому что из него получается, что, если _сжать_ видео любым lossless-кодеком (какая разница, каким именно - хоть винраром сжать качество ухудшится, потому что размер будет меньше, чем у исходного несжатого. По твоему определению выходит, что кодеков, сжимающих видео без потери качества, не бывает в принципе, так что достаточно лишь знать, что они есть.
Тогда пользуйся понятием bppЯ тебе уже сказал, почему понятие bpp отличается от понятия качества.
Я с таким же успехом могу, как меру качества, ввести, например, количество пикселей вообще... или физический вес винчестера, на котором этот фильм лежит.
Ты решил определить качество, как количество байт на пиксель; я не согласился с твоим определением, потому что из него получается, что, если _сжать_ видео любым lossless-кодеком (какая разница, каким именно - хоть винраром сжать качество ухудшится, потому что размер будет меньше, чем у исходного несжатого.Ты не знаком с понятием bpp. Поэтому не так меня понял.
Поясняю. Выше определённого значения bpp становится избыточным и ненужным. Если же считать, что энтропия информации в нересайзенном видео в среднем (по множеству различных видеофайлов) такая же, как в ресайзенном (не вижу причин, почему это могло бы быть не так то получу, что при одном и том же кодеке конечный bpp в среднем будет одинаковый, и потому размер файла уменьшится в 2 раза (опять же, видеочасть).
Разумеется, всегда можно подобрать примеры, при которых энтропия информации в файле уменьшенного размера будет больше, чем в файле неуменьшенного, равно как и обратные.
На глаз. Хотя да, будет сложно.
Неа, на глаз не катит
В большинстве кодеков есть три варианта сжатия ... закодировать с указанным процентом потерь.
В мой моск не влезает понятие "процент потерь". Что это? Количество незакодированных пикселей?
Покопался в Xvid'е и не нашел. Уверен, что такая хрень есть "в большинстве кодеков"?
Считаю, что дольнейший разговор лишен смысла - реально тут ничего не доказать ни опровергнуть.
В мой моск не влезает понятие "процент потерь".попробуй всё же поместить.
это ещё называется коэффизиентом корелляции перекодированного и неперекодированного видео
Покопался в Xvid'е и не нашел.Плохо искал?
Там, где настраиваешь способ кодирования, есть три варианта, о которых я уже говорил выше (если быть точным, четыре - вместо двухпроходного кодирования там отдельно первый проход и второй).
Тебе и надо выбрать вариант "я укажу качество".
ЗЫ: Хотя у xvid-а, насколько я помню, там шкала не от 0% до 100%, а от 1 (лучшее качество) до 32 (худшее качество)...
попробуй всё же поместить.
это ещё называется коэффизиентом корелляции перекодированного и неперекодированного видео
Даже если существует некоторый алгоритм по его вычислению, это еще не значит, что такой алгоритм единственный, и какой-либо другой алгоритм не даст другой процент потерь. Причем, очевидно, что продвинутые алгоритмы этой тематики должны учитывать психовизуальную модель человеческого зрения, которая, в конце концов является сюжетно-зависимой -> трудноалгоритмизуемой.
Даже если существует некоторый алгоритм по его вычислению, это еще не значит, что такой алгоритм единственный, и какой-либо другой алгоритм не даст другой процент потерь. Причем, очевидно, что продвинутые алгоритмы этой тематики должны учитывать психовизуальную модель человеческого зрения, которая, в конце концов является сюжетно-зависимойВоистину так!
Но ведь это ещё не повод чтоб убрать из настроек кодера такую галочку
вообще же отношение числа несовпавших пикселей к общему числу пикселей вполне может являться таковым
пусть и совершенно убогим
Плохо искал?
Там, где настраиваешь способ кодирования, есть три варианта, о которых я уже говорил выше (если быть точным, четыре - вместо двухпроходного кодирования там отдельно первый проход и второй).
Тебе и надо выбрать вариант "я укажу качество".
ЗЫ: Хотя у xvid-а, насколько я помню, там шкала не от 0% до 100%, а от 1 (лучшее качество) до 32 (худшее качество)...
Ты про квантизер? Ну-ну.
вообще же отношение числа несовпавших пикселей к общему числу пикселей вполне может являться таковымЕсли ещё и учитывать, насколько несовпали (и ввести какую-то метрику для того, чтобы узнать, насколько далеки два цвета друг от друга - хотя бы (|r1-r2|+|g1-g2|+|b1-b2|).depth а потом разделить на количество пикселей - то вполне такое не самое убогое определение
пусть и совершенно убогим
Еще немного, и вы изобретете PSNR.
пиксели будут отличаться гораздо сильнее, чем раньше.Пинартур жжот!
соседние пиксели будут отличаться гораздо сильнее, чем раньше. Потому что раньше эти пиксели были не соседними, а через 1.
соседние пиксели будут отличаться гораздо сильнее, чем раньше. Потому что раньше эти пиксели были не соседними, а через 1.Ты сформулировал афигенную теорему. Теперь доказывай.
Чего тут доказывать?
Берём фотографию, берём горизонтальный кусок - если бы пиксели были непрерывными, то функция пиксель=>rgb была бы непрерывной; и, в общем-то, чем больше разница между пикселями - тем больше разница между их значениями.
Может, тебе ещё и не понятно, что, в общем случае, на фотографии 720*576 пиксель (0,0) отличается от пикселя (719б575) сильнее, чем от пикселя (0,1)?
Берём фотографию, берём горизонтальный кусок - если бы пиксели были непрерывными, то функция пиксель=>rgb была бы непрерывной; и, в общем-то, чем больше разница между пикселями - тем больше разница между их значениями.
Может, тебе ещё и не понятно, что, в общем случае, на фотографии 720*576 пиксель (0,0) отличается от пикселя (719б575) сильнее, чем от пикселя (0,1)?
Берём фотографию, берём горизонтальный кусок - если бы пиксели были непрерывными, то функция пиксель=>rgb была бы непрерывной; и, в общем-то, чем больше разница между пикселями - тем больше разница между их значениями.Сам-то понял что сказал?
Может, тебе ещё и не понятно, что, в общем случае, на фотографии 720*576 пиксель (0,0) отличается от пикселя (719б575) сильнее, чем от пикселя (0,1)?
Э, не, батенька, это уже не доказательство теоремы, а её впаривание.
Сам-то понял что сказал?А тебе что не нравится?
На фотографии, чем дальше мы от какого-то пикселя (в каких-то разумных пределах тем сильнее, в общем-то, будет отличаться цвет от цвета исходного пикселя (за этими пределами, цвет может быть уж совсем каким угодно, и близким к цвету исходного пикселя может оказаться только "случайно").
На пальцах, по аналогии - рассматриваем рельеф горной местности, фиксируем точку, чем дальше мы от неё удаляемся (в тех же разумных пределах тем сильнее (в общем случае) будет отличаться высота исходной точки от высоты текущей; а если мы удалимся слишком далеко - на сто километров или на другой конец Земли, сказать насчёт высоты уже вообще ничего будет нельзя, кроме того, что она попадёт в диапазон (-11000,9000).
Твои фотографии - это градиентные заливки?
Твои фотографии - это градиентные заливки?В общем-то, фотографии довольно близки к градиентным заливкам в большинстве мест... как и горная местность.
Тогда расслабься.
Кодеку, настроенному на кодирование градиентов, в общем-то пофигу с каким они там шагом - обычным или удвоенным.
А который их не понимает (что вряд ли) и на изначальную градиентность тоже класть.
Кодеку, настроенному на кодирование градиентов, в общем-то пофигу с каким они там шагом - обычным или удвоенным.
А который их не понимает (что вряд ли) и на изначальную градиентность тоже класть.
в общем-то пофигу с каким они там шагом - обычным или удвоеннымТипа, на один градиент - один объём, а сколько в нём пикселей - неважно?
как ни странно, да, для классического линейного градиента хватает двух пикселей - начального и конечного, а уж на сколько их растянуть - дело десятое =)
другое дело, что на реальной фотографии этот градиент обычно "снабжён" кучей иррегулярностей, на которые кодеку приходится отвлекаться
уменьшаем разрешение в 2 раза - уменьшаем число иррегулярностей
другое дело, что на реальной фотографии этот градиент обычно "снабжён" кучей иррегулярностей, на которые кодеку приходится отвлекаться
уменьшаем разрешение в 2 раза - уменьшаем число иррегулярностей
соседние пиксели будут отличаться гораздо сильнее, чем раньше.Пожалуйста, примени свое утверждение к следующей картине (по горизонтали отложена абсцисса пикселя, по вертикали - яркость):
_ _ _ _ _
_ _ _ _ _
Чтоб ты особо не мучался, могу сказать, что при уменьшении частоты оцифровки в два раза, в два раза сужается полоса частот. Что для FT-based алгоритмов сжатия (к каковым относится и JPEG, основанный на DCT) означает уменьшение в два раза количества информации - исходной!
Хоть я и не знаю математики, но скажу, что для вейвлетных алгоритмов это тоже верно.
для вейвлетных алгоритмов это тоже верно.знаю только один вейвлетный алгоритм сжатия видео - WMV9
ещё есть?
Indeo. Quicktime, по-моему.
Знаю вейвлетный алгоритм сжатия статических изображений - JPEG2000.
Вообще, в поезг.
Знаю вейвлетный алгоритм сжатия статических изображений - JPEG2000.
Вообще, в поезг.
Пожалуйста, примени свое утверждение к следующей картинеИзвини, но это нихуя не фотография, это решётка с шагом в один пиксель.
уменьшение в два раза количества информации - исходной!Исходной информации будет в два раза меньше, но сама эта информация будет хуже поддаваться сжатию.
Извини, но это нихуя не фотография, это решётка с шагом в один пиксель.Звёздное небо это.
Исходной информации будет в два раза меньше, но сама эта информация будет хуже поддаваться сжатию.
Поздравляю. Ты только что придумал универсальный метод увеличения энтропии информации. Срочно пиши патент.
Ты только что придумал универсальный метод увеличения энтропии информации.Ладно, вместо "информация" читай "объём"
Звёздное небо это.Ага, каждая звезда - один пиксель, и расстояние между звёздами - тоже один пиксель.
Да, в случае _нормального_ звёздного неба, можно сжимать информацию так - чёрное неебо размера а*б, n звёзд, координаты 1 звезды, координаты 2 звезды итд. Навряд ли можно как-то сильнее (если расположение звёзд случайно) сжать эту информацию, и тут ты при ужимании неба до (a/2)*b ничего не выиграешь - звёзд останется столько же, разве что их координаты будут на 1 бит короче.
Ты пишешь бред сивой кобылы, если уж откровенно говорить.
Если тебе не нравится слово "энтропия", поясняю на пальцах: ты имеешь наглость утверждать, что уменьшение разрешения на 50% приводит к уменьшению информации в снимке лишь на 20%, что есть бред.
Если тебе не нравится слово "энтропия", поясняю на пальцах: ты имеешь наглость утверждать, что уменьшение разрешения на 50% приводит к уменьшению информации в снимке лишь на 20%, что есть бред.
скорее полезной информации
ты имеешь наглость утверждать, что уменьшение разрешения на 50% приводит к уменьшению информации в снимке лишь на 20%, что есть бред.Да, я утверждаю именно это.
Почему ты считаешь это бредом?
координаты (из-за более-менее равномерного распределения) надо брать относительно предыдущей звезды - экономиться существенно больше
"полезная информация" - понятие сильно относительное.
Мне вот например может быть охота разглядеть листья на дереве, тогда как кому-то хватит просто дерева.
Мне вот например может быть охота разглядеть листья на дереве, тогда как кому-то хватит просто дерева.
Извини, но это нихуя не фотография, это решётка с шагом в один пиксель.Извини, но "решетка с шагом в один пиксель" - это экстремальный случай результата дизеринга.
в данном случае один черный пиксель не отличается от другого черного пикселя на картине черного неба, вот только если менять их местами энтропия будет увеличиваться
Даже такие координаты не станут занимать в два раза меньше места при уменьшении разрешения в два раза.
ЗЫ: Хотя, возможно, такой файл потом будет легче сжать.
ЗЗЫ: Кстати, а как ты собираешься упорядочить звёзды на плоском снимке, чтобы смещение относительно предыдущей попадало в узкие рамки?
ЗЫ: Хотя, возможно, такой файл потом будет легче сжать.
ЗЗЫ: Кстати, а как ты собираешься упорядочить звёзды на плоском снимке, чтобы смещение относительно предыдущей попадало в узкие рамки?
Почему ты считаешь это бредом?Потому что это не подтверждается на практике.
лучше энтропию полезной информации ввести - тогда все правильно
при уменьшении размера в два раза, кол-во полезной информации меняется не пропорционально размеру.
при уменьшении размера в два раза, кол-во полезной информации меняется не пропорционально размеру.
Потому что это не подтверждается на практике.Ты пробовал?
У меня опыта в этом деле уж всяко побольше твоего будет.
ты это о чём?
поясняю и тебе на пальцах: если операцию, подобную пенартуровскому "отрезанию" половины пикселей проделать с фоткой звёздного неба, можно смело рассчитывать что при этом потеряется инфа о половине звёзд.
поясняю и тебе на пальцах: если операцию, подобную пенартуровскому "отрезанию" половины пикселей проделать с фоткой звёздного неба, можно смело рассчитывать что при этом потеряется инфа о половине звёзд.
Ты пробовал?О да.
ступенчато
вообще, можно вычислить все координаты всех точек, а потом оптимизировать их относительными координатами ступенчато, т.е. для 70% брать n бит на координату, для остальных - n+2 и т.д.
вообще, можно вычислить все координаты всех точек, а потом оптимизировать их относительными координатами ступенчато, т.е. для 70% брать n бит на координату, для остальных - n+2 и т.д.
ложь
берем шахматную доску, уменьшаем размер в два раза - при одном алгоритме может получиться 32 черных квадрата, при другом 32 белых, а при третьем 31 черный и один белый.
берем шахматную доску, уменьшаем размер в два раза - при одном алгоритме может получиться 32 черных квадрата, при другом 32 белых, а при третьем 31 черный и один белый.
Мы тут рассматриваем нормальные фотографии, или фотографии, на которые наложена такая решётка?
Если эта решётка не нужна - убираем её нах, после чего такой нехорошести уже не будет (да и в любом случае, после уменьшения разрешения в два раза, у тебя по-прежнему останется сама фотография, а решётка, если различия между тёмными и светлыми пикселями в ней не сильно большие, особой погоды всё равно не делает).
Если она нужна - то разрешение просто нельзя уменьшить вдвое (не всякому понравится, если ясно видимая решётка вдруг превратится в серый/чёрный/белый фон, про потери от собственно компрессии тут говорить уже не имеет смысла, мы уже проимели все ключевые детали).
Если эта решётка не нужна - убираем её нах, после чего такой нехорошести уже не будет (да и в любом случае, после уменьшения разрешения в два раза, у тебя по-прежнему останется сама фотография, а решётка, если различия между тёмными и светлыми пикселями в ней не сильно большие, особой погоды всё равно не делает).
Если она нужна - то разрешение просто нельзя уменьшить вдвое (не всякому понравится, если ясно видимая решётка вдруг превратится в серый/чёрный/белый фон, про потери от собственно компрессии тут говорить уже не имеет смысла, мы уже проимели все ключевые детали).
О да.Чем, сколько раз, с какими настройками, на каком источнике?
В смысле - ступенчато
ты привёл пример против самого себя же
такое "разделение" приведёт к ещё большей потере информации, да оно ещё и использует априорное знание о распределении клеток на шахматной доске
думай что ли прежде чем писать
такое "разделение" приведёт к ещё большей потере информации, да оно ещё и использует априорное знание о распределении клеток на шахматной доске
думай что ли прежде чем писать
я с этим на практике имею дело, а не с абстракциями какими-то
по науке
на каком-нить просвечивающем микроскопе уменьшение разрешения в 2 раза к катастрофическим последствиям для получаемой инфы приводит
по науке
на каком-нить просвечивающем микроскопе уменьшение разрешения в 2 раза к катастрофическим последствиям для получаемой инфы приводит
на каком-нить просвечивающем микроскопеНа каком микроскопе?
Фильм, уважаемый , фильм, из тех, что пихают на диски "8в1"
Фото я имею в виду, дарагой друх, фото. Чёрно-белое даже. Тоже можно усмотреть градиенты, все дела. Сжимаемость отличная.
Только вот если разрешение мало - полный швах.
И в фильмах то же - уменьшаем разрешение в 2 раза, и опаньки, на лице главзлодея становится в 2 раза меньше прыщей, и не такой уж он и главзлодей получается. А то и просто краснокожий, если перестараться.
Только вот если разрешение мало - полный швах.
И в фильмах то же - уменьшаем разрешение в 2 раза, и опаньки, на лице главзлодея становится в 2 раза меньше прыщей, и не такой уж он и главзлодей получается. А то и просто краснокожий, если перестараться.
не расстраивайся, я тоже не особо умею кодировать фильмы.
я не правильно оформил мысль - каждый квадрат пронумеруем, т.е. совокупность черных квадратов - "полезная информация", белый фон - "излишняя".
Мы тут рассматриваем нормальные фотографии, или фотографии, на которые наложена такая решётка?Слушай, ты никогда не видал продизеренные рисунки? Это, к твоему сведению, любой цветной скан с типографского отпечатка. Ты не слыхал, что в фотографиях бывают шумы? Не сталкивался с мелкими деталями? Судя по всему, твое определение "нормальной фотографии" - это, короче, чтобы там ваще не было высоких частот, а то прям как не у пацанов...
существует огромное число способов (забыл комбинаторику) разбить шахматную доску на две части, и только 2 (который фактически 1) из них приведут к разделению на чисто чёрное и чисто белое поля
с учётом того, что обычно априори неизвестно их размещение (с шахматными досками всё же редко приходится иметь дело с наибольшей вероятностью доска делится на две половины с равным числом чёрных и белых клеток
с учётом того, что обычно априори неизвестно их размещение (с шахматными досками всё же редко приходится иметь дело с наибольшей вероятностью доска делится на две половины с равным числом чёрных и белых клеток
Да, забыл спросить - мы выкидываем половину пикселей, или какое-нибудь там bilinear делаем?
А то на лице главзлодея может остаться столько же прыщей, сколько и было, только прыщи обрезанными станут.
А то на лице главзлодея может остаться столько же прыщей, сколько и было, только прыщи обрезанными станут.
Не сталкивался с мелкими деталями?Я же там сказал - "если решётка нужна, то пиздец, потому что после ресайза мы её проимеем, и говорить о качестве уже не будет смысла".
Да, забыл спросить - мы выкидываем половину пикселей, или какое-нибудь там bilinear делаем?хехехехе
при таком подходе твоя позиция ещё более шаткая, потому как на глаз даже градиенты сохранятся.
никакая интерполяция не добавляет новой информации и нужна только потому, что глазу с ней приятнее, так что монопенисуально есть билинейка и иже с ней или нету.
вообще не два а 32!*32!*2, если считать, что клетки разные
да хоть как считай, только вероятность того, что тебе удастся с одной попытки из 32 + 32 шариков чёрного и белого цвета вынуть 32 белых (эквивалентная задача) крайне мала.
если просто выкинуть произвольно три четверти пикселей, то инфа не потеряется - звезды могут быть больше размером чем 1-2-3 пикселя
не пытайся подменять понятия, пожалуйста
речь шла о "цифровом" небе
0 - нет звезды
1 - есть
речь шла о "цифровом" небе
0 - нет звезды
1 - есть
32!/(64^32) хех
ок
тогда уж "наиболее вероятное"...
ладно, не буду становиться кохтпой
тогда уж "наиболее вероятное"...
ладно, не буду становиться кохтпой
при таком подходе твоя позиция ещё более шаткаяПри подходе выкидывания, прыщи не размажутся, а наоборот, будут сильнее торчать
Допустим, было _-^-_, а стало _^_; это хуже поддаётся сжатию
звезды могут быть больше размером чем 1-2-3 пикселяМы тут, вроде как, однопиксельные звёзды обсуждали
При подходе выкидывания, прыщи не размажутся, а наоборот, будут сильнее торчатьзлодея показывают издалека, прыщи однопиксельные - при выкидывании пловина и пропадёт
не всё ж в фильме крупные планы его рожи - в них я буду считать волосинки в бороде, которых при "выкидывании" станет опять же в 2 раза меньше
Допустим, было _-^-_, а стало _^_; это хуже поддаётся сжатию
это с одним так стало, а с другим стало — что даже сжимать не надо
Я все пытаюсь донести до тебя, что после даунсемплинга bandwidth сужается, поэтому твое заявление об увеличении "разницы" между соседними пикселями (разницы в чем? мягко говоря, бессодержательно...
Кажется, мне это не удастся.
Кажется, мне это не удастся.
0000000000000000
0000000000000000
0000111111110000
0000111111110000
0000111111110000
0000111111110000
0000000000000000
0000000000000000
без сжатия 256 бит
с сжатием
0111 0111 0111 0111 01111 0000
1111 1111 0111 0000
1111 1111 0111 0000
1111 1111 0111 0000
1111 1111
0111 0111 0111 0111 01111 0000
26*4 = 104бита
коэф сжатия = 2.46
00000000
00111100
00111100
00000000
было, несжатый размер 64бита
сжатый (stripe - полосками для 1и 0 макс размер полоски - 7)
0111 0000 0010 1100 0100 1100 0111 0011 - 32 бит
коэф сжатия = 2
(сжатие слово из 4х бит, в слове первый бит заполнение полосы, три следующих - длина, 0000 - один 0, 1111 - одна 1)
тут можно еще сжать, но уже видно, что чем больше информации, тем лучше она сжимается
0000000000000000
0000111111110000
0000111111110000
0000111111110000
0000111111110000
0000000000000000
0000000000000000
без сжатия 256 бит
с сжатием
0111 0111 0111 0111 01111 0000
1111 1111 0111 0000
1111 1111 0111 0000
1111 1111 0111 0000
1111 1111
0111 0111 0111 0111 01111 0000
26*4 = 104бита
коэф сжатия = 2.46
00000000
00111100
00111100
00000000
было, несжатый размер 64бита
сжатый (stripe - полосками для 1и 0 макс размер полоски - 7)
0111 0000 0010 1100 0100 1100 0111 0011 - 32 бит
коэф сжатия = 2
(сжатие слово из 4х бит, в слове первый бит заполнение полосы, три следующих - длина, 0000 - один 0, 1111 - одна 1)
тут можно еще сжать, но уже видно, что чем больше информации, тем лучше она сжимается
Попробуй посчитать то же самое, но не для 16*8, а, например, для 1600*800
А то этот результат я бы объяснил тем, что тут на эти заголовки что-то уходит, независимо от размера матрицы, и при таком размере эти заголовки постоянной длины и делают такую сильную разницу...
А то этот результат я бы объяснил тем, что тут на эти заголовки что-то уходит, независимо от размера матрицы, и при таком размере эти заголовки постоянной длины и делают такую сильную разницу...
ага, могу прогу написать, если совсем уж надо
дай матрицу тока
дай матрицу тока
(разницы в чем?Мы тут уже пытались ввести метрику на rgb
Да хотя бы то же самое, увеличенное в сто раз...
что-то лень сейчас
хотя прога - полпинка
хотя прога - полпинка
ты сначала еще дай условия ресайза
В смысле - "условия"?
ЗЫ: Вообще, все эти матрицы, конечно, имеют весьма отдалённое отношение к реальности...
ЗЫ: Вообще, все эти матрицы, конечно, имеют весьма отдалённое отношение к реальности...
тут можно еще сжать, но уже видно, что чем больше информации, тем лучше она сжимаетсяИ по-твоему эти примеры являются показательными?
Оставить комментарий
nas1234
всю свою сознательную жизнь думал что пикселы всегда квадратные.это как?