Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Извини чел. Я вообще ничего не понял. Ты можешь дать краткое описание своей разработки?
Ну типа это - такая-то утилита. На вход идет тото. На выходе - это.
17 янв 19, 16:49    [21788139]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6179
exp98
А вообще, за тобой иногда замечается заносчивость. Что ж, сейчас наверное это доблесть.
майтон просто зайчик =)

Если что, я тоже невкурил, проведи ликбез плз

ЗЫ.Хотя я не верю в кибернетическую археологию
17 янв 19, 23:14    [21788356]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Да. Тяжко нам, зайцам.

Я вот опубликую мысль над которой я иногда думаю. Рассеянно.
Раскачиваясь на стуле и глядя в потолок.
Вот если взять черно-белую картинку с факсмильным текстом.

Типа такой (внизу).

И предположим что мы ее хотим оптимально хранить. Разобъем
ее на две половинки по вертикали. И будем рассматривать половинки как 2 независимых картинки.
Слева допустим будет полу-картинка которая будет сжата стандартым факсимильным CCITT Group 4 compression.
Ну неважно чем. Главное что чем-то уже известным. Не суть.

Далее правая половинка - это документ который имеет характеристики сходные с левой.
У них - одинаковый растеризованный шрифт. У них - одинаковая высота строк. И много
похожих статистических характеристик.

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

image = load("file.ttf")
imageLeft = lefthalf(image)
imageRightOriginal = righthalf(image)

imageRightRecovered = clearImage(image.x / 2,image.y)

while(isDiffer(imageRightOriginal,imageRightRecovered) {
   frame = getFirstDifferFrame(...) // Здесь много эвристики надо думать
   apply(frame, imageRightRecovered) // Здесь не обязательно XOR. Можно рассмотреть AND/OR тоже как операции
   addTo(setOfDifferFrames, frame)
}

save(imageLeft, withCCITTcompression)
save(setOfDifferFrames)
/// Здесь в качестве полезного эффекта я расчитываю получить сет
// изменений в виде некоторого лога действий который в общем
// сериализованном виде будет компактнее чем правый оригинальный image


Далее. Можно попробовать применить рекурсивно этот-же подход к левой картинке разбив еще на две
четвертинки.

Вобщем расчитываю получить некий профит.

P.S. Никакой имплементации пока у меня нет.

К сообщению приложен файл. Размер - 39Kb
18 янв 19, 14:51    [21788795]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
Dima T
Member

Откуда:
Сообщений: 13672
ИМХО может не повторы с одной половины искать на другой, а просто повторы.
Например нашли прямоугольник с буквой O и по всему оставшемуся документу делаем поиск аналогичной катринки.
Затем в конечный файл записываем картинку исходного прямоугольника и координаты всех ее включений.
И т.д. пока не обработаны все места картинки.

Для текстов может и сойдет, и то не факт если это скан.
Даже без повторов может пожаться при большом количестве белого, если в прямоугольники брать только фрагменты с черным.
18 янв 19, 15:33    [21788850]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Ну... я предполагаю что 80% это как раз и будут тексты.
18 янв 19, 15:37    [21788854]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Так. Ту картинку нафик. Она - полутоновая. Вот более правильная.

К сообщению приложен файл. Размер - 40Kb
18 янв 19, 22:36    [21789122]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7654
mayton
Так. Ту картинку нафик. Она - полутоновая. Вот более правильная.

Вы случайно не
https://en.wikipedia.org/wiki/Group_4_compression
пытаетесь по новой изобрести ?

ну или
https://en.wikipedia.org/wiki/JBIG2

+

Ideally, a JBIG2 encoder will segment the input page into regions of text, regions of halftone images, and regions of other data. .... Textual regions are compressed as follows: the foreground pixels in the regions are grouped into symbols. A dictionary of symbols is then created and encoded...
19 янв 19, 21:50    [21789401]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Итак дорогие мои Бабушкины. Я продолжу субботний поток сознания.

Немного цифр.

Оригинальное изображение имеет разрешение 1728x2339. Это главная цифра.

Я сохранил ее в 256 цветное индексное изображение но я был неправ. Цель - архивировать
bi-tonal images поэтому я чуть позже все переделаю. Но не суть. Сейчас это не имеет значения.
Считайте что мы работает только с чёрным и белым цветом без градаций серого.

Под катом - сведенья которые выдает imagemagic.
+
Image: ccitt01.png
  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: PseudoClass
  Geometry: 1728x2339+0+0
  Resolution: 28.35x28.35
  Print size: 60.9524x82.5044
  Units: PixelsPerCentimeter
  Type: Bilevel
  Base type: Grayscale
  Endianess: Undefined
  Colorspace: Gray
  Depth: 8-bit
  Channel depth:
    gray: 1-bit
  Channel statistics:
    Pixels: 4041792
    Gray:
      min: 0 (0)
      max: 255 (1)
      mean: 248.376 (0.974024)
      standard deviation: 40.5613 (0.159064)
      kurtosis: 33.5236
      skewness: -5.96017
      entropy: 0.173792
  Colors: 2
  Histogram:
    104990: (  0,  0,  0) #000000 gray(0)
   3936802: (255,255,255) #FFFFFF gray(255)




Вводная. Термины.

Сжатие-архивирование.
В топике суть одно и тоже.

Raw-size - несжатый объем картинки в байтах. При этом предполагаем что бит 1 и бит 0 в байте определяют
черный и белый цвет соотв.

Для нашей картинки:

1728 x 2339 = 4041792 pixels

В байтах 4041792 / 8 = 505224 = 493 килобайта. Прошу запомнить цифру. Я буду часто на нее ссылаться как
на некий эталон или стартовую точку отсчета. Именно стольно информации хранит наша харнтинка в raw-size.

Спрайт - некий фрагмент картинки (возможно прямоугольной формы) с которым мы работаем. Ищем. Сопоставляем.
И применяем к результату.

Имеющиеся на рынке алгоритмы.

Имеющиеся в наличии сегодня алгоритмы которые архивируют подобные bi-tonal (bi-level) картинки
- CCITT Group 4. Документация пишет что достигает сжатия 20:1

- JBIG2 (Joint Bi-level Experts Group)
Все эти алгоритмы (CCITT, JBIG) очень быстро работают. Некоторые (для факсимильной связи) не видят всю картинку
в целом а обрабатывают только строку независимо от других строк. Это разумно, беря во внимание
возможности железа в 70-80х когда эти алгоритмы только создавались

Чуть позже я соберу цифры как архивируется оригинальная картинка на них всех + еще в различных
конфигурациях параметров алгоритма если таковые будут.

- GIF/PNG - уже известны. Работают хорошо с индексным цветом (2,4,8,16,256 цветов)
но не учитывают особенности bi-tonal. Грубо говоря есть куда расти.

- Архиваторы WinRar/WinZip/Bzip2 .... e.t.c. Работают хорошо применительно к general информации
но также не анализируют пространственные свойства картинок. Хотя на дельта-кодах и на много-цветных (true-color)
картинках WinRar может быть очень эффективен.

Для нашего эксперимента архиваторы не интересны. Хотя могут быть полезны для "дожатия" цифрового потока
который получен например после применения нашего алгоритма который мы создаем.


Цель


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

По сути - разработать компрессор.

Компрессия должна нести в себе полезный эффект превышающий пользу от JBIG, CCITT*

compressed-size << compressed-size-JBIG/CCITT << raw-size


Несколько предположений по реализации.

1) Если поставить задачу чуть подольше анализировать картинку то можно поднять больше сведений
о закономерностях которые в нем есть. Ограничений на время нет. Можно анализировать хоть целый день.

2) Если рассмотреть некие атомы из которых состоит данная факсимильная картинка то можно
заметить что это буквы. И всякие символы вокруг букв.

3) Буквы имеют дефекты сканирования. Тоесть одна и та-же буква будет не похожа сама на себя.

4) Разумно рассматривать не целую букву а фрагмент (спрайт? Фрейм?). Есть большая вероятность что ему будет найден
похожий образец.

5) Разумно брать спрайт небольшого размера 3x3, 4x4, 5x5 pix. Слишком большой размер просто сгенерирует
уникальный справочник который по размеру будет эквивалентен raw-size. Слишком мелкий (2х2) годится
но не даст полезного эффекта сжатия т.к. информация по индексу справочника также будет равна самому элементу
по объему занимаемых данных.

6) Разумно сегментировать картинку. Выделить в ней абзацы и строки хотя-бы для облегчения поиска спрайтов.

7) Разумно индексировать картинку. Выделить в ней области которые имеют какие-то признаки для быстрого
поиска.

8) Разумно создавать дополнительные структуры данных (плоскости оригинального изображения) где помечать
уже обработанные пикселы.

9) Разумно рассматривать рекурретное самоподобие восстанавливаемой картинки. Тоесть после того как мы
начали процесс реконструкции у нас кроме справочника могут появлятся новые детали которые также
можно рассматривать как новый справочник.

10) Язык программирования - любой. Ограничений по времени компрессии - нет. Однако желательно чтобы
декомпрессия была по сложности близка к распаковке архива. Как-то так.

Что в топике мы не будем обсуждать.

Сжатие алгоритмами JPEG/JPEG2000/LuraWave и прочие которые вносят
необратимые потери. Сжатие с потерями - отдельная тема и ее можно
обсудить отдельно.

Классические архиваторы. По причинам которые я описал выше.

Всё что здесь написано - безо всяких копирайтов. Вы можете спокойно брать и юзать. Я не против.
20 янв 19, 00:01    [21789461]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Leonid Kudryavtsev
mayton
Так. Ту картинку нафик. Она - полутоновая. Вот более правильная.

Вы случайно не
https://en.wikipedia.org/wiki/Group_4_compression
пытаетесь по новой изобрести ?

ну или
https://en.wikipedia.org/wiki/JBIG2

+

Ideally, a JBIG2 encoder will segment the input page into regions of text, regions of halftone images, and regions of other data. .... Textual regions are compressed as follows: the foreground pixels in the regions are grouped into symbols. A dictionary of symbols is then created and encoded...

Уже ответил походу.
20 янв 19, 00:03    [21789462]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
exp98
Member

Откуда:
Сообщений: 1638
Давненько не брал я в руки факсов. Кажется мне,что такими ровными и белыми могут быть только электронные факсы. В моём прошлом строчки на бумаге гуляли как волны, перемежаясь с площадями серой грязи.
На факсах м.б. логотипы и печати.

Просто находить линии, когда они прямые, легко. Файнридер так делает. В целом - это "преимущественные" направления.

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

Вообще же, если предполагать разброс % черноты в пределах 10 - 90%, универсальный фрактальный метод тоже ж придумали. Там универсальный словарь графических примитивов.
Вспоминая, что некий нулевой вариант фрактального метода, тоже был когда-то в моей археологии, могу быть уверенным, что однотонные площади он закодирует как надо. На степень сжатия будет влиять размер нарезки.
Жпег конечно разрывные функции приближает косинусами, но бесконечным их кол-вом (согласно теории Ф), и сжатие слабое.

А насчёт зайцев щас найду ....
20 янв 19, 00:05    [21789463]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
exp98
Просто находить линии, когда они прямые, легко. Файнридер так делает. В целом - это "преимущественные" направления.

+1

Это мысль. Что здесь в помощь? Фурье?

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

Цветные картинки и градации серого я отметаю. Не интересно пока. Не буду заниматься.
Вообще большинство книг эпохи 90х были оцифрованы именно в bi-tonal. Я может
быть хотел свою библиотеку перецифровать. Да мало-ли...

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

Я вспоминаю что-то в compression.ru или в книжках Ратушняка и Ватолина про фрактальный метод. И где-то даже
был исходник на VisualC++ который сжимал очень ограниченное изображение (квадрат) в grayscale.
Но я-бы хотел подойти к этому методу чуть позже. Хочу вычерпать свои мысли сначала.
20 янв 19, 00:18    [21789472]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
exp98
Жпег конечно разрывные функции приближает косинусами, но бесконечным их кол-вом (согласно теории Ф), и сжатие слабое.

К чорту JPEG.
20 янв 19, 00:21    [21789474]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
exp98
Member

Откуда:
Сообщений: 1638
Siemargl
проведи ликбез плз
Для начала согласно правилам: ридми прочтён? там написано немного сумбурно, но перечислены входные параметры и 2 выходных массива (1 для изучения, как бы основной промежуточный параметр, 2-й реально выходной - картинка).
Ну и вообще распаковка входных параметров прозрачнее некуда.
Запись в файл WriteDz() - тоже.
Собственно расчёт формулы - тоже - те 20 строчек после
/*** Вычислить Dz[] методом DARM ***/


Какие ожидания или конкретные вопросы ?

Непараметрическую регрессию всегда нужно понимать как формулу сглаживания с плавающим окном.
Единственно необычного, что стандартно регрессия используется, чтобы найти коэфф-ты уравнения по значениям, минимизирующие невязку, а тут в обратную сторону.
20 янв 19, 00:26    [21789478]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
exp98
Member

Откуда:
Сообщений: 1638
mayton
Фурье?
В топку, это же гармоники, приближающие 2-мерную поверхность, а она кусочно постоянная. И волны ничего не знают про геометрию площадей.
Я же подразумевал преимущественные направления текстовых строк. По сути - это куда и на сколько повернуть рисунок. Методы выдумывать уже не буду, наверняка описаны. Например можно приспособить типа "векторизации" для нахождения строк или пучки прямых (кол-во чёрных точек по направлению для равномерной выборки из файла)
Если не этого хотелось, то ссори.

Но книги сканировать лучше всё же в полутоне - меньше потерь и артефактов.
20 янв 19, 00:41    [21789481]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Полностью согласен насчёт того как правильно сканировать книги.

Но вернёмся к bi-tonal.
20 янв 19, 00:47    [21789483]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
exp98
Member

Откуда:
Сообщений: 1638
В пучках прямых ещё можно дополнительно использовать кластеризацию черноты. Например, если поперёк текста или по кляксе. Характеристики кластеров (размер на прямой, функция распределения по размерам кластера ...)

Ладно,печалька, думал, что в прорубь сегодня, блин ((( термос заварил ....
20 янв 19, 00:48    [21789484]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Почитал вики по Преобразованию Хафа. Интересно. Может пригодится.
20 янв 19, 00:59    [21789488]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Хаф использует выделение границ как промежуточный шаг.

Интересно. Можно ли обойтись без него. Для bi-tone картинки границы между строками букв достаточно четкие.
20 янв 19, 10:42    [21789537]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Чорт. Этот Хаф уводит меня сильно далеко. Кроме того надо ещё и имплементации поискать.
По ссылкам Хабра нашёл под C#.

И ещё вродебы OpenCV поддерживает.

Форкну отдельно. В профильных форумах.
20 янв 19, 16:31    [21789711]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7654
mayton
- GIF/PNG - уже известны. Работают хорошо с индексным цветом (2,4,8,16,256 цветов)
но не учитывают особенности bi-tonal. Грубо говоря есть куда расти.

LZW для bi-tonal вроде не очень подходит. Всю жизнь считал, что bi-tonal значительно лучше сжимается Хаффманом. Был уверен, что TIFF для Bi-tonal именно Хаффман использует, но Wiki пишет про CCITT

Кто ошибается, мой маразм или Wiki - не знаю.

mayton
exp98
Просто находить линии, когда они прямые, легко. Файнридер так делает. В целом - это "преимущественные" направления.

+1

Это мысль. Что здесь в помощь? Фурье?

Плохо разбираюсь в математике, но вроде Фурье апроксимирует ф-ции (!), а bi-tonal назвать не прерывной функцией можно только с большого перепоя. Т.ч. JPEG и Фурье для bi-tonal и вообще любых картинок с резкими границами - зло. AFAIK

mayton
Для bi-tone картинки границы между строками букв достаточно четкие.

Если изобретать свой простой велосипед, то IMHO вполне достаточно XOR'ить соседние строки. Т.к. скорее всего они будут повторяться (вертикальные линии), а горизонтальные линии и Хаффман и LZW хорошо пожмет. В принципе, к велосипеда можно еще приделать квадратные колеса, где в начале каждой обрабатываемой строки или использовать или не использовать "пред обработку" (по аналогии с PNG). Но не думаю, что по качеству сжатия это сильно уйдет от CCIT

А если велосипед не изобретать, то читать про то, как сделал JPEG Independent Group. Работа над JPEG 2000 шла черти сколько времени + в процессе работы отовсюду торчали ушы военных (т.е. бабло). Первые демки по FOI (Future of Interest) в JPEG 2000 вообще были снимки Ирака с пусковыми установками ))), даже уши не прятали ))).

Не думаю, что в форуме можно изобрести нормальные алгоритмы распознавания изображений.

В крайнем случае, можно посмотреть на набор алгоритмов в Open CV. Насколько я помню, там были и алгоритмы для выделения границ, и алгоритмы для поиска FOI, и нейронные алгоритмы поиска похожих (плюс нечувствительные к масштабу и поворотам).

Но мне кажется, это из пушки по воробьям. Даже DjVu настолько не заморачивается (а это коммерческий продукт)
20 янв 19, 16:43    [21789719]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Leonid Kudryavtsev
Плохо разбираюсь в математике, но вроде Фурье апроксимирует ф-ции (!), а bi-tonal назвать не прерывной функцией можно только с большого перепоя. Т.ч. JPEG и Фурье для bi-tonal и вообще любых картинок с резкими границами - зло. AFAIK

Я имел в виду детектирование частот и фаз. Ну да бох с ним. Я уже отказался от Фурье.
Пока что Hough transform - актуален.
20 янв 19, 17:46    [21789752]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
exp98
Siemargl
проведи ликбез плз
Для начала согласно правилам: ридми прочтён? там написано немного сумбурно, но перечислены входные параметры и 2 выходных массива (1 для изучения, как бы основной промежуточный параметр, 2-й реально выходной - картинка).
Ну и вообще распаковка входных параметров прозрачнее некуда.
Запись в файл WriteDz() - тоже.
Собственно расчёт формулы - тоже - те 20 строчек после
/*** Вычислить Dz[] методом DARM ***/


Какие ожидания или конкретные вопросы ?

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

Я с вашего позволения сделаю копи-паст с вашего readme.txt и приаттачу в форум для удобства.

+
Очень кратенько описание в начальном приближении.

Все файлы подразумеваются в одном каталоге.
Darm-m.cpp  - Основная программа, проверялась для C++(11) в режиме debug,
    часть переменных осталась от предыдущих моделей, они не вычищены, т.к.
    файл сделан со старой распечатки, но имевшей версию близкую к окончательной.
    Полезные сочетания параметров модели для хороших картинок надо подбирать.
    Основная идея модели в том, чтобы сформировать корреляционное поле со спец. св-вами.
    Эти св-ва визуально могут выглядеть в виде протяжённых либо компактных регионов,
    к-рые можно интерпретировать на своё усмотрение. 
    Например в данном варианте гистограмма распределения амплитуд яркости показывает 
    два доминирущих кластера по яркости (но не по площади). 
    Можно, к примеру, сказать, что это перепады высот. (А можно и, 
    что это группировки в соцсети вокруг агентов влияния 2-х разных идей...)
    Точно помню, что при неких простых параметрах вида констант 0/1 получилось 
    похоже на треуг-к Серпин-го.
    
defines.c  - включаемый файл, содержит универсальные макросы
cfg-m.cfg   - параметры модели в текстовом виде, нужно wN1=iP ...


Dz[][]  - 2-мерное поле точек, основная цель программы, на выходе файлы Dz.flt и Dz.json
Teta[][] - 2-мерное поле промежуточного параметра модели, сохраняется в teta.flt
eps.flt  - входной массив вероятностей (epsilon), должен иметь распределение спец. свойства,
      но свойства надо знать.
doEps.cpp  - можно создавать свой файл eps.flt, затем
      Eps[] будет использоваться для создания pi[0-3] с нужными характеристиками,
      в то время как pi[4-5] формируются случайным образом. 

  
Кстати переменные созвучны греческим буквам:
dzeta[][]  - значения числового поля, вычисляется по модели регрессионного типа
epsilon[]  - [0; 1], задано в файле
teta[][]  - {0; 1}, вычисляется рекуррентно, записывается в файл для промежуточного контроля
PVer[]  - [0; 1], заданы вероятностями, желательно чтобы и больше, и меньше 1/2,
          имеет смысл порогов сравнения.
pi[0-3] и pi[4-5] - {0; 1}, (не путать с числом 3,141593...), вычисляется,
          имеют 2 разных происхождения и использования
"Мю"   - ~0.5, вычисляется, имеет смысл матожидания в модели регрессии
Ro[], Lambda[] - [-1; 1], вычисляется
A[], B[]  - вычисляется
C[]  - [-1; 1], вычисляется


Если неохота писать рисовалку данных для изучения полученных корреляционных св-в.
пакет PHP версии от 5.2
запускать (зашито, что из каталога c:/tmp/4php/)
php.exe ind3.php Dz.png 30 33
где 30х33 - пример размеров графического полотна в пикселах

ind3.php  - рисует в png-файле (например в Dz.png) то, что читает из Dz.json 
dataDZ.inc  - включаемый файл
Dz.json  - встроенный входной файл для рисовалки, он же выходной для модели ( из Darm-m)
Dz.png - имя, к-рое задавать в командной строке
---------------------------------
20 янв 19, 17:52    [21789753]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Leonid Kudryavtsev
LZW для bi-tonal вроде не очень подходит. Всю жизнь считал, что bi-tonal значительно лучше сжимается Хаффманом. Был уверен, что TIFF для Bi-tonal именно Хаффман использует, но Wiki пишет про CCITT

Кто ошибается, мой маразм или Wiki - не знаю.

Не уверен. LZW обычно подходит для текстовых данных где есть ярко выраженные слоги.

Для сжатия черно-белых строк в классическом варианте используются кодирование Хаффмена.
Различные вариации CCITT Group 3/4. Строка изображения при этом представлена как последовательность
длинн черно-белых отрезков. Где черный и белый - строго четные и нечетные или наоборот.
20 янв 19, 18:00    [21789759]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Leonid Kudryavtsev
Если изобретать свой простой велосипед, то IMHO вполне достаточно XOR'ить соседние строки. Т.к. скорее всего они будут повторяться (вертикальные линии), а горизонтальные линии и Хаффман и LZW хорошо пожмет. В принципе, к велосипеда можно еще приделать квадратные колеса, где в начале каждой обрабатываемой строки или использовать или не использовать "пред обработку" (по аналогии с PNG). Но не думаю, что по качеству сжатия это сильно уйдет от CCIT

Эксперимент с XOR (вправо) я уже проводил где-то в sql.ru. Не могу найти правда.
У него полезный эффект - почти тот-же что и кодирование чет-нечет отрезков черного и белого.
Я-бы даже сказал что это одно и то-же. Для детектирование переходов мы можем xor-ить
соседей явно или в алгориме подразумевать это.

Добавление вертикального XOR к строкам не даёт полезного эффекта. Ну ... по крайней мере
для тех данных на которых я тестировал.

Хотя XOR может быть полезен как фильтр границ. Ну об этом чуть позже я еще напишу.
20 янв 19, 18:08    [21789763]     Ответить | Цитировать Сообщить модератору
 Re: Четверговый архивариус  [new]
mayton
Member

Откуда: loopback
Сообщений: 40731
Leonid Kudryavtsev
Не думаю, что в форуме можно изобрести нормальные алгоритмы распознавания изображений.

Я не претендую. В конце концов это чортовы игры разума. Как ферзи на доске.
20 янв 19, 18:10    [21789765]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Программирование Ответить