Comments: |
Покопайся в ImageJ, может там что подходящее будет. А вообще я бы натравил какой-нибудь алгоритм определения контуров, а потом бы сгруппировал найденный контуры по размеру и отфильтровал самые маленькие и самые большие. Вот ещё неплохая бумажка нагуглилась http://nagoya.uchicago.edu/~dmcallester/curves.pdf
проблема в том (я тоже находил) что оно пытается искать не «регулярности в картинке», а «выпирающие элементы». это, в общем-то, несколько другая задача, с другими решениями. мне не надо «границы тайлов для построения карты проходимости», мне надо повторяющиеся фрагменты картинки для построения атласа. карта проходимости — это всё отдельно.
Ну, у меня была такая мысль, что элементы платформера должны достаточно сильно выделяться на фоне, и следовательно хорошо ловиться контурными алгоритмами. Взаимооднозначное соответствие между контуром и куском картинки сделать несложно же.
А сжатие текстур таким способом кмк сейчас уже никто не делает.
не обязательно. к тому же совсем не обязательно, чтобы алгоритм делил по тем же тайлам, из которых построено — мало ли, как алгоритму покажется лучше паковать. может, он кусок стены с градиентом найдёт, который везде напихан.
>А сжатие текстур таким способом кмк сейчас уже никто не делает. мало ли, что там кто делает/не делает сейчас. фи. а вот есть двигатель, и ему лучше бы порезать именно так, например. допиливать туда поддержку мегатекстур не вариант. и срать в память видеокарты порезаной на куски текстурой тоже.
а художник, я считаю, не должен забивать себе голову такой ерундой, как ебля с техническими аспектами двигателя. задача художника — художничать. рисовать, ставить свет, пидорасить пиксели. всё остальное дожна делать программа, потому что иначе нахер она нужна?
чтобы алгоритм делил по тем же тайлам, из которых построено — мало ли, как алгоритму покажется лучше паковать. может, он кусок стены с градиентом найдёт, который везде напихан. О, я-то как раз думал, что тебе интереснее готовые тайлы вытащить. Ну тогда да, либо бить сеткой и играть в морской бой, либо брать нейронную сеть и обучать её.
мало ли, что там кто делает/не делает сейчас. Я про не делают в том ключе, что вряд ли можно будет найти готовый алгоритм, заточенный под такую задачу.
С художником соглашусь, но с уточнением: если его художества приводят нас к NP-полной задаче, их лучше всё-таки ограничить.
>в том ключе, что вряд ли можно будет найти готовый алгоритм, заточенный под такую >задачу я на готовый и не надеюсь. но наверняка кто-нибудь что-то такое думал раньше, статью написал, ещё что-нибудь.
>брать нейронную сеть и обучать её зачем? как один из вариантов решения — я написал, вроде: использовать тот же алгоритм, например, который imgseek использует для определения «похожести» картинок, и пробовать варианты, разбивая картинку на всё более мелкую сетку, попутно пробуя варианты ячейки сетки со сдвигами. в теории, это ещё и захэшировать можно.
но я чую, что это далеко не лучший вариант, и всё равно сильно тормозной.
>но с уточнением: если его художества приводят нас к NP-полной задаче, их лучше >всё-таки ограничить. это не проблема художника, это наша недоработка, да. мы тут сидим чтобы учить технику решать задачи, а не чтобы учить художников делать технике хорошо. ;-) ну, вот эта задача — явно решаемая техникой, например.
то есть, задача (см. упд) такая, что есть ОГРОМНЫЙ битмап с повторяющимися кусками. заранее неизвестно, есть ли такие куски, какого они размера, как расположены, etc. надо их найти и вместо огромного битмапа построить атлас и карту блитов кусков. чисто задача для ужимания мегатекстуры, чтобы она не занимала 100500 памяти.
nu eto vsego lish variacija na temu "grep". pochetaj slovo "agrep"
да вообще хуйня эти все спецалгоритмы, надо почитать на тему битов. всё равно в итоге оно только биты туда-сюда меняет.
ty sejchas glupostj skazal. jestj algoritmy bystrogo grepa, izvini zabyl tochnoje nazvanije, i oni podxodjat.
vozjmi pervuju stroku iskomogo shablona, i po nej tupo grepj. jesli pervaja stroka shablona ne sovpala s chem-libo to eto chto-libo tochno NE jestj pervaja stroka tajla. ulavlivajesh kak eto skorachivajet tvoj poisk. i eto samoje lobovoje predlozhenije.
tojestj taki da poisk podstroki tebja spasjot. pogugli "fast substring matching" chto-to tipa etogo, potomuchto vot etot perebor kotoryj ja tebe predlozhil mozh siljno ukorotitj.
>iskomogo shablona а ничего, что «искомый шаблон» — это от одного до как минимум ПОЛОВИНЫ пикселей битмапа, и перебирать их надо ВСЕ? O сам прикинь, ага.
> а ничего, что «искомый шаблон» — это от одного до как минимум ПОЛОВИНЫ пикселей битмапа
absoljutno nichego! vybrasyvajesh shoblon pri pervom zhe nesovpadenii. tojestj da slozhnostj kubicheskaja v idealje, no prakticheski, nalozhitj shablon ne ravno proveritj vse jego piksely.
ага, квадратичная. заебись легче стало, теперь-то заживём.
ещё раз повторю: никакие алгоритмы «поиска подстрок» тут не стоят того, чтобы написать хотя бы `void main ()`.
короче говоря: варианты lz-компрессора — это не сильно лучше брутального перебора в лоб. теоретически они задачу решают, но практически я лучше напишу тогда: «утюги не поддерживаются, желаю понтовую видеокарту с поддержкой текстур 65536x65536!».
то есть, если ты ещё не понял: не линейный перебор типа «берём первый пиксель. потом два первых пикселя.» а все возможные варианты прямоугольников, с любой координаты, любых размеров.
lz работает только тогда, когда надо найти уже заданый паттерн. а когда даже паттерн неизвестен, любые поиски подстрок (aka lz) — нафиг бесполезны.
> а когда даже паттерн неизвестен,
tojestj tebe vpadlu skazatj mashinke odin raz kakoj pattern ty shukajesh? eto dazhe ne smeshno, chuvak sekonomil odin crop.
откуда, блядь, я знаю, что ищется? вот без Ценной Мысли про lz я бы никак не сообразил, как мне искать известный паттерн, ага. я, конечно, очень тупой, и обязательно бы это спросил.
вот это вот — мышление говнокодера: «зачем машина должна делать работу, которую за неё может сделать человек?»
net. ty delajesh etu rabotu ZA SEBJA. vopros v tom mozhno li s vygodoj poruchitj etu rabotu moshine.
ты, может, удивишься, но любая автоматизация — это «пусть машина работает за меня». в данной задаче меня интересует только такой вариант, все остальные — нет.
ne vse investicii v oftamatizaciju opravdany. kak tebe verno zametili nado prosto zastavitj xudozhnega risovatj kak nado (eto tozhe mashina).
tebe zhe nado ne prosto rezuljtat (ja uzhe nachinaju ponimatj) a rezuljtat kotoryj glazam prijatno -- nu tak mashina ponjatija ne imejet kak tvoji glaza chitajut kartinku.
>nado prosto zastavitj xudozhnega risovatj kak nado говнокодер детектед.
ty prosto dumajesh chto xudozhnek eto ne mashina.
если вдруг не дошло: мягко намекаю, что регулярные выражения здесь неприминимы уже в силу того, что НАХУЙ НЕИЗВЕСТНО, ЧТО ИСКАТЬ. привет, O(N^M*N^M) начальная фаза, ага.
From: | (Anonymous) |
Date: | May 21st, 2017 - 01:27 pm |
---|
| | | (Link) |
|
По-моему, ты какой-то нездоровой хуетой занимаешься. Собрался жать с потерями поиском "почти похожих", но не 100% похожих кусков? Что это за сумасшествие вообще?
это художник рисует карту, а она разбивается на куски для весьма ограниченого двигателя. «почти похожий» — это «визуально неразличимый». rgb(100, 100, 100) и rgb(101, 101, 101) визуально не различимы, например, но не одинаковые. однако отлично уложатся в один общий тайл, и разницы никто не заметит.
i da, poprobuj prosto tupo OKRUGLITJ bity pered poiskom, pomojemu eto dast tebe tovojo ponjatije poxozhesti. ili tam musornyje piksely tozhe mogut?
могут. хочется дать возможность рулить параметрами похожести — может, художника устроит «более униформный» вариант, мало ли.
ну и да, «округлять» rgb нельзя, конечно, надо как минимум сналача преобразовать в XYZ (linear RGB), а лучше и вовсе в Y*. то есть, «похожесть цветов» как раз нифига не проблема. проблема — это быстрое нахождение похожих кусков заранее неизвестного размера, количества и положения. lz, как я писал тебе в другом каменте, справляется с этим крайне херово. моя попытка сперва побить на сетку, и оценить «похожесть» каждого куска сетки через frequency map — чуть лучше, но тоже не очень. но уже лучше.
From: | (Anonymous) |
Date: | May 21st, 2017 - 02:12 pm |
---|
| | | (Link) |
|
Если двигатель ограниченный - придется художника ввести в курс ограничений, иначе он нахуярит картинку без единого повторяющегося элемента. Не лучше ли тогда сразу тайлы рисовать?
не лучше. двигатель может, но облегчить ему задачу — дело полезное.
From: | (Anonymous) |
Date: | May 21st, 2017 - 02:28 pm |
---|
| | | (Link) |
|
Что за двигатель такой, который может клипнуть большую полноцветную картинку на весь экран, но которому легче заполнить его десятком маленьких?
Или это 3Д?
легче не ему, а древним видеокартам. если можно ужать картинку для утюгов — хочется это сделать.
From: | (Anonymous) |
Date: | May 21st, 2017 - 02:36 pm |
---|
| | | (Link) |
|
Порезать на равные куски.
From: | (Anonymous) |
Date: | May 21st, 2017 - 02:47 pm |
---|
| | | (Link) |
|
Не понимаю. Сам же сказал, что дело в видюхе.
From: | (Anonymous) |
Date: | May 21st, 2017 - 02:49 pm |
---|
| | | (Link) |
|
Речь идет о подгрузке кусков, естественно.
речь не идёт об изменении двигателя. он не умеет.
From: | (Anonymous) |
Date: | May 21st, 2017 - 02:57 pm |
---|
| | | (Link) |
|
Ну хуй знает, я бы вручную тайлы для поиска задал. А то ведь и до квадратиков 2x2 доискаться можно.
задание вручную ничем не отличается от: «эй, художник, тайловай!» какая разница, кто делает ручную работу — её не должно быть в принципе.
а 2x2 — да на здоровье. софтина попробует, увидит, что «упакованый» вариант стал больше оригинального — и забьёт на такую упаковку.
From: | (Anonymous) |
Date: | May 21st, 2017 - 03:06 pm |
---|
| | | (Link) |
|
Будто написание этой фигни - не ручная работа. В фотошопе есть инструмент knife - дезигнеры испокон веков режут свои высеры и не жужжат - работы на пять минут. Ок, видюхе текстура велика, но может быть, ей от кучи мелкой геометрии ещё больше поплохеет?
а у дидов вообще этих бесовских компьютеров не было!
когда человек выполняет работу, которую должна и может делать машина — мы объебались.
и нет, с кучей геометрии всё ок, она кулится по вьювпорту.
From: | (Anonymous) |
Date: | May 21st, 2017 - 03:34 pm |
---|
| | | (Link) |
|
Так "мы" кругом объебались, computer science сто лет в обед - автоматизация до сих пор нулевая, на уровне "процедур с параметрами". Какие там, в пизду, тайлы - 2017 год на дворе, а я не могу своему компьютеру на человеческом языке объяснить простейшую задачу на поиск и замену текста без вот такенного регекспа. ИИ - сплошная бутафория: "слушаюсь и повинуюсь, хозяин, вот тебе страница результатов из гугла".
так это ни разу не причина продолжать объёбываться и дальше. пока «а, и так сойдёт» — оно и будет так идти.
From: | (Anonymous) |
Date: | May 21st, 2017 - 03:37 pm |
---|
| | | (Link) |
|
Ну будет у тебя очередная "процедура с параметрами" для узкого случая. Тут всю систему менять надо.
пока что у меня есть конкретная задача, которую надо решать не сменой системы, а конкретно.
From: | (Anonymous) |
Date: | May 21st, 2017 - 03:40 pm |
---|
| | | (Link) |
|
Я хуею вообще от количества recurring проблем в софте. Вот, казалось бы, решили вопрос "натуральной" сортировки файлов с циферками в файлменеджере - нет, блять, обязательно следующий высер будет с 1, 10, 100... и следующий тоже.
да нихера не решили, к сожалению. ты очень правильно написал: мы оперируем слишком низкоуровневыми понятиями, поэтому и повторяем одну и ту же хуйню постоянно.
а благодаря горячо любимому юникоду «правильная сортировка» невозможна вообще, потому что юникод нихера не умеет в нормальное различие между буквой и символом.
«квадратики 2x2», кстати — вполне нормальный вариант. если у тебя длинная стена из chequered pattern, например — упаковать её в повторяющийся тайл очень даже вариант.
From: | (Anonymous) |
Date: | May 21st, 2017 - 03:46 pm |
---|
| | | (Link) |
|
Вощем, я думаю, что задачка из разряда каттинг-эдж нейросеток, а в лоб она будет считаться дольше, чем вручную порезать. Такие дела.
а я нутром чую, что нейросетки тут как японской школьнице катана: красиво, стильно и нахер ненужно. но доказать не могу.
ne nado dokazyvatj. Nejrosetj eto imja pustoty.
лол. как раз вчера вечером говорили с хорошим человеком на эту тему. хайп, хайп, overestimations и хайп.
From: | (Anonymous) |
Date: | May 22nd, 2017 - 09:18 am |
---|
| | | (Link) |
|
А чего в вашем сонном болоте не хайп? По-моему, всё, что можно было высосать из идеи дискретных алгоритмов, уже высосано. Скоро придет лесник с какой-нибудь программируемой аналоговой квантовой зеленой хуйней и разгонит всех к едрене фене. Вот смеху-то будет.
пусть приходит. нам, в общем, пофигу, что ломать.
алсо, в том-то и дело, что «картинка без единого повторения» — это очень маловероятная ситуация. в подавляющем большинстве уровней повторения есть. но они не обязательно сделаны из целых тайлов, например. вот я хочу, чтобы софтина искала повторения сама, не напрягая художников всякой ерундой.
From: | (Anonymous) |
Date: | May 21st, 2017 - 05:38 pm |
---|
| | | (Link) |
|
Как-то сюда сразу думается в суффиксные деревья и нечеткий поиск, только вместо какого-нибудь расстояния Левенштейна воткнуть свою функцию для достаточно похоже/недостаточно похоже.
проблема в том, что битмапы БОЛЬШИЕ. восемь тыщ на восемь тыщ точек — так, запросто. оно ж не просто всю память засрёт, но ещё и заебётся там искать и сравнивать.
From: | (Anonymous) |
Date: | May 21st, 2017 - 05:59 pm |
---|
| | | (Link) |
|
дык, попробовать, а дальше уже оптимизировать, если что :) например, размер алфавита -- это наш bpp. почему бы его первым нелом не понизить прямо на входе?
а что у нас «символ»? тайлы не имеют фиксированых размеров.
From: | (Anonymous) |
Date: | May 21st, 2017 - 06:14 pm |
---|
| | | (Link) |
|
Символ -- цвет точки. Сравнятор -- упрощенное расстояние Левенштейна (оставляем только замену в допустимом диапазоне, остальное выбрасываем). А дальше план возник такой: мыж дерево строим на строке и в процессе поиска не можем бегать по столбцу, но нам этого и не надо -- если это два тайла, которые потенциально удовлетворяют условиям, то у них и первая строка удовлетворяет. Задача: искать все подходящее по первой строке точек, а дальше уже по этому относительно небольшому списку опорных подстрок, через тот же сравнятор, пробежать уже по самому битмапу, достраивая тайл вниз.
так это обычный lz-компрессор, зачем тут дерево, там хэшами обходятся. и тормозит оно адово, сука.
From: | (Anonymous) |
Date: | May 21st, 2017 - 06:40 pm |
---|
| | | (Link) |
|
а есть битмап для поиграться?
да возьми любой уровень от какого-нибудь более-менее современного платформера, где больше 12 цветов.
From: | (Anonymous) |
Date: | May 21st, 2017 - 07:05 pm |
---|
| | | (Link) |
|
легко, только вот у меня нет современных платформеров, экстракторов уровней, etc .(
ну, укради где-нибудь. у меня под рукой тоже нет — я ж пока думаю, а не делаю.
в смысле, восемь тыщ — это небольшой битмап.
slushaj, jesli tebe nado chisto teksturu reguljarizovatj, to ty mozhesh predpolozhitj chto ona samopodobna; i vmesto kopanija vnutyrj ty mozhesh pojti naruzhu, i poprobovatj vsju kartinku schitatj tajlom, umenjshitj i soglasovatj kraja.
нет. я же ясно написал: порезать большую мегатекстуру на атлас.
a jesli etu megateksturu accki zabljuritj vnej budut vidny regiony raznyx cvetov?
поскольку это пиксельарт, то сократить количество проверок это поможет в среднем на нихуя.
From: | (Anonymous) |
Date: | May 22nd, 2017 - 02:25 pm |
---|
| | | (Link) |
|
А откуда там разброс цветов, если пикселярт? По-моему, ты в каком-то говне ковыряешься - двигло писал дегенерат, уровни рисовал дегенерат.
в следующий раз я попрошу заспавнить меня в нормальном мире, а не в этом. но в этот раз есть то, что есть.
From: | (Anonymous) |
Date: | May 22nd, 2017 - 02:45 pm |
---|
| | | (Link) |
|
А вдруг, вот это и есть самый нормальный из всех?
тогда удалю нахуй аккаунт, игра говно.
ochenj dazhe doxuja! primeni LJUBUJU funkciju kotoraja "sglazhivajet" po ljubomu pokazatelju (blur prosto samyj nagljadnyj dlja razgovora slovami)
ty poluchish neskoljko maksimumov etogo sglazhenogo pokazatelja.
ty mozhesh utverzhdatj chto jesli kakoj-to tajl lezhit blizko k centru "krasnogo" pjatna to on tochno ne lezhit v okresnosti "sinego" pjatna.
eto utverzhdenije fakticheski razrezajet tvoj bitmap na neskoljko MENJSHIX bitmapov. k kotorym ty mozhes podojti s polnym pereborom a summa kubov menjshe kuba summy DOXUJA KAK.
vygodu u tebja spizdjat OVERLAPY regionov. poetomu k regionam mozhno tozhe neskoljko raz primenitj etot podxod prezhde chem morochitj perebor.
a potom mozhno proveritj chto ty projebal: tak kak ty pomnish GDE ty naxodil tajly ty mozhesh iz najdenyx tajlov vozstanovitj izxodnuju kartinu zatem vychestj vozstanovlenuju kartinu iz izxodnoj, i xujnutj poisk najdennyx tajlov sredi vot etoj raznicy.
где-то в каментах я об этом писал. только ты ж не пиши совсем уж для яслей, пиши «преобразуй во frequency domain» — и сразу станет ясно, что ты в виду имел. потому что откуда я знаю, может ты именно на блуре настаивать хочешь — и тогда не работает, конечно.
> пиши «преобразуй во frequency domain»
sovershenno ne objazatejno! mozhet bytj chto ugodno chto djot tebe ljubuju xarakteristiku regiona pikselej.
По идее сетка будет где-то в модах fourier transform.
не обязательно фурье — любые вэйвлеты пойдут, по идее: всё, что в тот или иной frequency domain транслирует.
А какие вэйвлеты способны трансилровать в глобальный frequency domain?
То есть, по-моему это по определению лучшэ всего делают вэйвлеты e^(iPx), которые по определению являются преобразованиями Фурье.
а я хуй знает. мне настолько лень в этом всём разбираться, что я как раз и надеялся, что кто-то уже сделал это за меня, а мне останется только бережно спиздить и радоваться.
tak tebe atlas tajlov ili kompresiju? kompresiju mozhno i lz sdelatj, jesli porezatj kortinku na kvodrategi i sovatj v potok ne bitmap a posledovateljnostj maaaalenjkix kvadratnyx bitmapikov. (jesli ty praviljno opisal xarakter isxodnogo bitmapa, to povtorimostj kvadratikov opredeljonnogo razmera budet vpolne godnaja dlja lz)
«исхотдный битмап» совершенно любой.
может и нет. а может и есть, потому что некие повторения в уровнях возникнут неизбежно — да хоть одинаково покрашеный кусок стены.
ну и, само собой, атлас тайлов — это и есть компрессия же.
net. v atlase boljshe infy chem v kopressii
чего? нет, конечно. это всего лишь 2д-расширение 1д-lz.
net. semantika blokov najdenyx N-mernym lz ne sootvetsvujet slovu "tajl"
конечно, соответствует. регулярно повторяющиеся участки фиксированого размера — это, вообще-то, тайлы. и то, что в атласе есть наборы тайлов разных размеров — не делает их «нетайлами», как не делает двигатели, которые умеют в тыйлы разных размеров нетайловыми.
kogda ty govorish pro igru i pro tajly, to v etom kontekste "tajl" eto prakticheski izpoljzujemyj UNIT KARTY kotoryj soznateljno sozdan kak unit i imejet cennostj otdeljnuju ot okruzhenija.
eto unit tvojej raboty, a ne prosto kombinacija iz dvux pikselov popavshaja na kartiku boljshe odnogo raza.
извини, я не в курсе твоих словарных нюансов. тайл — это то, что я написал. какое отношение к этому имеет «сознательность создания», «юниты работы» и прочие странные штуки — я не знаю.
ja inogda prosto oxujevaju kagbuta ja razgovarivaju s durakom!!! a potom ponimaju chto prosto russkij dlja tebja ne rodnoj, i nado prosto ob'jasnitj tebe smysl slov.
для меня все ваши человеческие языки неродные: вы всегда в простые определения тащите некие «подразумеваемые сущности», взятые совершенно от балды.
pixel traverse order:
01 02 05 06 17 18 21 22 itd 04 03 07 08 20 19 24 23 13 14 09 10 29 30 25 26 16 15 12 11 32 31 28 27 49 50 53 54 33 34 37 38 52 51 56 55 36 35 40 39 61 62 57 58 45 46 41 42 64 63 60 59 48 47 44 43 itd
itd itd
jesli ty takoj umnyj kak vsem skazyvajesh to ty ponjal.
как я тебе уже говорил, бесконечного времени и бесконечной памяти в наличии нет. ты усердно мне рассказываешь, как мне искать уже известные повторения. а я тебе каждый раз повторяю, что одна из самых важных частей задачи — это как раз найти эти самые повторения автоматически, и что в силу размера битмапов техники lz-поиска будут сжирать памяти больше, чем размеры винтов, и адово тормозить.
> уже известные повторения
net.
да. или это, или механическое растягивание 1д случаев на 2д — где они неизбежно превращаюются из «приемлемого варианта» в «поный пиздец».
bljatj! ja tebe pokazal kak sdelatj negljadja 2D-lz kotoryj zavedomo dast prijemlemuju kompressiju.
ты показал, как «развернуть» 2д lz в 1д lz. а я тебе говорю, что это не отменяет ни квадратичного времени, ни полного неумения lz работать адаптивно — то есть, находить на уже известном датасете наилучшие участки с точки зрения минимизации выхлопа.
ty otvergajesh ochenj deshovyj i ochenj zabavnyj eksperiment na osnovanii neponjatnyx jevristik. "adaptivno"... xujeptivno! ja predskazyvaju chto takoj obxod dast tebe potok pikselov kotoryj lz budet ljubitj.
а я тебе в очередной раз говорю, что lz тут вообще не при чём, потому что он умеет искать только уже известные паттерны. главная же часть задачи состоит как раз в том, чтобы сначала эти паттерны автоматически определить. любая попытка научить даже одномерный lz чуть-чуть (совсем чуть-чуть!) лучше определять, какие паттерны стоит рассматривать, сразу же тормозит компрессоры до еле-еле юзабельного состояния (см. все попытки улучшить deflate, например).
poxuj zhe! gzip, rar chto ugodno.
когда мне будет похуй, я возьму жопег. за эту задачу мне не платят, поэтому мне хочется решить её изящно, а не как-нибудь.
kogda u tebja propadjot nastrojenije trollitj, prixodi sprashivaj.
я и спросил в посте. ты предлагаешь неизящные минимум-квадратичные решения, которые кое-как решают задачу компрессии, но абсолютно игнорируют остальные части задачи. это интересно, но это не то, о чём я спрашивал.
выделить повторения, заранее неизвестные, то бишь. что в lz всё равно является как минимум степенным O.
bljatj ja nixuja neponimaju CHEGO TEBE V ITOGE NADO?! tebe odin raz etot bitmap pozhatj i ty jebjosh mozg slozhnostju kompressii.
чтобы оно умело адаптироваться к картинке (нет, lz-производные не умеют, они потоковые по определению), и при этом не занимало три мясяца, требуя ферму с терабайтами ram.
ja tebe pokazal porjadok obxoda kotoryj zamenjajet "adaptivnostj"
а я тебе сказал, что это минимум квадратичное решение, которое нереально посчитать за приемлемый бюджет на персоналке. | |