» ScanKromsator СканКромсатор (Часть 3)

bolega

Цитата:

Только я все равно Вас абсолютно не пойму.

Вот как я делал книгу:

1. Загрузил сырые сканы, задал всевозможный Greу Enhance + бинаризация. Выделил картинки в Picture-зоны. Получил на выходе множество ЧБ-сканов и множество вырезанных картинок, закрыл СК.

2. Открыл СК, загрузил опять множество ЧБ-сканов из п.1, покромсал начерно, закрыл СК.

3. Открыл СК, загрузил множество ЧБ-сканов из п.2, почистил вручную крупную грязь, примыкающую к контурам голых текстов, закрыл СК.

4. Открыл СК, загрузил множество ЧБ-сканов из п.3, покромсал начисто, закрыл СК.

5. Открыл СК, загрузил множество ЧБ-сканов из п.3. Теперь это уже полностью готовые облагороженные ЧБ-сканы.

Так вот - пришлось вставлять в них картинки, вырезанные в п.1, обратно через Фотошоп.

Результат здесь: http://www.onlinedisk.ru/file/182410/

А хотелось бы автоматически в СК. Но для этого нужно, чтобы логическая связь между сканами, из которых вырезали картинки в п.1 и этими самыми картинками (т.е. out-task), сохранялась на промежуточных этапах 2-4.

Причём где-то на этих промежуточных этапах могут попасться некие операции, изменяющие геометрию сканов (кромсание) - значит, нужно чтобы out-task корректировался во время них нужным образом - чтобы учесть возможные геометрические изменения на промежуточных 2-4.

Возможно, однако, и более простое решение: хранить некую мета-информацию в виде ini-файла, относящуюся исключительно лишь к вырезанным картинкам. Назовём его условно "pics.ini". Скажем, если есть скан, на котором 2-3 картинки, и они были вырезаны в 2-3 файла-картинок, то в "pics.ini" записать бы информацию-шаблон взаимного координатного расположения картинок.

Представим мысленно картину:

Получив в конце концов так или иначе готовые обработанные ЧБ сканы, открываем "pics.ini" - и вырезанные картинки тут же появляются над нужными местами сканов (в "предварительном" режиме - чтобы их можно было двигать над сканом). Далее мы пролистываем вручную все сканы, и смотрим - корректно ли легли картинки назад, и если надо - мышкой чуть подвигаем нужную картинку на нужную позицию. Откорректировав таким образом вручную позиции картинок, нажимаем некую кнопку - и картинки вставляются на сканы уже окончательно.

Или же такая функциональность уже существует в СК?

Добавлено:
Мне удалось проделать эту манипуляцию в СК. При помощи out-task.

Самое главное, что на финальном этапе вырезанные картинки вставились в "динамическом" режиме. Я их каждую мышкой чуть подвинул - на нужные места - и сделал merge. СК опять ругнулся "nothing to do" - когда я выставил create separate files for non b-w zones - но я это ругательство проигнорировал, нажал process - и получил готовые сканы со вставленными как положено картинками.

Единственное малое неудобство - если на одном скане 3 Picture-зоны - я не смог их мышью подвигать одновременно всё 3 сразу - пришлось по одной двигать.

И ещё я хотел повращать немного Picture-зоны - после вставки их в "динамическом" режиме (из out-task) - но не смог - не появилась там нигде закруглённая стрелка для вращения.

Добавлено:
А вращать Picture-зоны действительно хотелось бы - картинки почти всегда нуждаются в исправлении перекоса типа deskew.

monday2000
[Подавив изумление Вашим подходом]
Почему п.3 нельзя делать в том же задании, что и п.2?

Если каждый раз будете создавать задание через create-out-task, выполнять его (чтобы получить новые выходные файлы, пусть даже идентичные входным), то вся информация о зонах сохранится вплоть до последнего задания.
Есть одна тонкость: если для внешней зоны не задано никаких преобразований, то СК не будет делать ее копию в очередную папку out (это бессмысленно), т.е. out-задания будут создаваться, а зоны будут браться из out самого первого. Если Вы хотите и зоны каждый раз дублировать, то можно попробовать в принципе обмануть СК, включив в свойствах внешней зоны опцию transparent (но это нужно проверить). На самом последнем этапе отключить ее.

Добавлено:

Цитата:

ругнулся "nothing to do" - когда я выставил create separate files for non b-w zones - но я это ругательство проигнорировал, нажал process

Еще раз повторю: сначала нужно сделать process (чтобы получить вых. файлы), а потом уже merge. Если не будет выходных файлов, то с чем СК будет сливать зоны??? Поэтому он и говорит nothing to do.

Добавлено:
monday2000

Цитата:

Я их каждую мышкой чуть подвинул - на нужные места

По идее, сколько бы Вы ни делали out-заданий, СК должен идеально выдерживать положения зон. Но если у Вас они сбились, то это объяснимо. И это очень интересный момент в СК, который ранее никогда не обсуждался. Дело в том, что если делать deskew после того, как появились внешние зоны, то deskew на них не действует, т.к. предполагается, что внешние зоны уже выровнены (трудно представить себе обратное, кроме как в Вашем извращенном многоступенчатом методе). Не действует только потому, что во внутренних структурах зоны имеется флаг, который блокирует их поворот при обработке. Этот флаг СК сбрасывает только в одном случае - когда импортирует зоны из pdf. Делается это только программно, визуально доступа к флагу нет. И давать доступ к нему я посчитал опасным, так как можно сильно навредить зонам, если использовать его неправильно.
Таким образом, в Вашем случае сбой положений зон происходит когда при наличии невыровненных внешних зон идет deskew. Я порекомендовал бы самое первое вырезание зон делать в том задании, в котором делается deskew, не ранее и не позже. Тогда проблем не будет.


Цитата:

И ещё я хотел повращать немного Picture-зоны - после вставки их в "динамическом" режиме (из out-task) - но не смог - не появилась там нигде закруглённая стрелка для вращения

К сожалению, вращения внешних picture-зон не предусмотрено.

bolega

Цитата:

[Подавив изумление Вашим подходом]

Зато хорошо становится понятна логика "рядового книгосканировщика", не читающего этот топик. Возможно, все-таки стоит заставлять пользователя делать Merge на каком-то из этапов (при сохранении таска, при выходе - не знаю, когда еще). Или хотя бы как-то предупреждать, что Merge не выполнен.

ghosty

Цитата:

Или хотя бы как-то предупреждать, что Merge не выполнен.

Ага, а еще лучше встроиться в ядро windows, перхватывать все запуски DEE,Solo и т.д., и в этот момент давать предупреждение Я это к тому, что обработав сканы, юзер может вызвать DEE, не сохраняя и не выходя из СК. Нет, это слишком ненадежно и навязчиво. Это должно быть прописано одной строкой в доке.
И вроде бы уже пришли к выводу, что для рядового книгосканировщика СК не годится, нужен СТ.

bolega
Ну... в статусной строке хотя бы красным цветом - "UMERGED!"


Цитата:

И вроде бы уже пришли к выводу, что для рядового книгосканировщика СК не годится, нужен СТ.

Видимо, чего-то время от времени им в СТ не хватает...

bolega

Цитата:

Почему п.3 нельзя делать в том же задании, что и п.2?

В принципе, можно. Но всё равно п.4 нужно делать закрыв-открыв СК.

Цитата:

Если каждый раз будете создавать задание через create-out-task, выполнять его

Это слишком муторно ИМХО. Вот если бы СК делал это полностью автоматически - тогда ещё ладно. Автоматически - т.е. СК мог бы проверять папку с загружаемыми сканами на предмет присутствия в ней файлика out-task и, в случае обнаружения такового, "сопровождать" out-task далее через всю скан-обработку (корректируя его в плане координат картинок - если попадётся изменяющая геометрию сканов операция типа кромсания или deskew).

Это
Цитата:

Есть одна тонкость:

и это
Цитата:

то можно попробовать в принципе обмануть СК,

ИМХО тоже чересчур муторно. Проще сделать, как я (с ручной коррекцией позиций вставляемых назад Picture-зон).


Цитата:

[Подавив изумление Вашим подходом]

Вы имеете в виду то, что я всякий раз закрываю-открываю СК? Я лишь стремлюсь к максимальной простоте. Зато теперь я смогу объяснить другим работу с Picture-зонами. А как бы я им объяснил с фразами типа "можно попробовать обмануть СК" или "тут есть одна тонкость" и т.д.? Никто ведь и слушать не захочет...

А так - сразу, на первом же этапе вырезаем картинки, создаём out-task, отделяем картинки в сторону - и далее спокойно работаем с основными сканами как хотим - как будто никаких картинок и вовсе не было (и всех сложностей, с ними связанных). И лишь в самом-самом конце, открыв в заключительный раз СК, вставляем в уже готовые сканы вырезанные картинки (через out-task) - с той лишь (ИМХО малой) издержкой, что нужно будет эти картинки чуть вручную подвинуть.

Такой вариант ИМХО пока что наиболее прост и наиболее-воспроизводим большинством юзеров.

Добавлено:
bolega

Цитата:

К сожалению, вращения внешних picture-зон не предусмотрено.

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

Добавлено:

Цитата:

в Вашем извращенном многоступенчатом методе

Напротив - ИМХО мой многоступенчатый метод наиболее прост и понятен. Это даёт максимальную простоту - для понимания сканобработки сторонними юзерами. Простой и чёткий набор операций - каждая из которых внутренне обладает максимальной простой и "логической однородностью". Отпадает нужда разбираться и запоминать в излишних и запутывающих "тонкостях".

monday2000

Цитата:

ИМХО тоже чересчур муторно

Возможно. Хотя по сравнению с 5-ю этапами это просто цветочки
Делайте deskew и вырезание зон одновременно и никаких проблем не будет.


Цитата:

Вы имеете в виду то, что я всякий раз закрываю-открываю СК?

То,что для каждой операции создаете новое задание. Хотя СК оптимизирован на то, чтобы получать качество при одновременном применении опций. Если эти операции разнесены, то это уже не тот эффект. Это называется "баня тут, а раздевалка - через дорогу".

Многоступенчатый подход хорош следующим:

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

2. Становится легче всё объяснить стороннему юзеру - многоступенчатые этапы - это как бы "логические опорные точки" (либо для себя, либо для других).

3. Становится проще разделить весь процесс сканобработки по разным дням (если нет возможности всё сделать в один день).

4. Становится возможным в зависимости от вида сканов тот или иной этап проделать не в СК - а, например, в Book Restorer.

Именно поэтому я и ратую за разбиение функциональности СК и СТ на набор максимально-простых утилит. И тогда, в зависимости от вида данных сканов, подбирать те или иные этапы и утилиты (комбинируя при этом возможности СК, СТ, BR, Irfan View и т.д.).

Именно так и можно достичь максимума простоты любой сканобработки. А также в максимально-простых утилитах будет наиболее легко отладить все глюки.

monday2000

Цитата:

Получается, что при моём подходе это было бы полезным

Это в любом случае было бы полезным. Я не делал этого, т.к. необходимости до сих пор ни у кого не было, а делать это намного сложнее, чем поворот обычных зон (по сути наборов отрезков)

Добавлено:
monday2000

Цитата:

1. Загрузил сырые сканы, задал всевозможный Greу Enhance + бинаризация. Выделил картинки в Picture-зоны. Получил на выходе множество ЧБ-сканов и множество вырезанных картинок, закрыл СК.

Так скажите все-таки: здесь Вы перечислили почти все операции, выполняемые над сканом до бинаризации. Но здесь нет почему-то deskew. Это так?
Учтите, что качество поворота серого скана на порядок качественней, чем ч/белого. Видимо качество - это последнее, что Вас интересует.

Этапы Вы предлагаете, исходя из якобы простоты для чайника. А мне кажется наоборот. Если юзер - чайник, что он может понять в промежуточных результатах этих этапов? Он ведь не в состоянии толком оценить ни правильность, ни качество. Ему наоборот будет тяжело понять из какого этапа пошел косяк.
Мне кажется, что этапы нужны только Вам, чтобы ради интереса наблюдать за процессом кромсания.

bolega
Столкнулся со следующей непонятной ситуацией.
Перевожу разворот в сером 300dpi в пдф в разных режимах и наблюдаю следующее:
размер исходного tif 5,88 МБ, в irfan в свойствах - "число уникальных цветов" = 182.
Перевел с помощью Кромсатора этот разворот в пдф в двух режимах - JPG quality = 80% и JPG2000 quality = 50%., затем этой же программой вытащил тифы и получил:
в первом случае размер tif = 9,18 МБ, "число уникальных цветов" = 1022(!);
во втором случае размер tif = 7,93 МБ, "число уникальных цветов" = 2494(!!!).
Во всех трех случаях сжатие LZW.
Вчера на развороте из другой книги получалось нормально, т.е. исходный скан был самого большого размера ("число уникальных цветов" = 172), затем по мере уменьшения процента в JPG quality размер скана соответственно уменьшался, при переходе на JPG2000 quality эта тенденция продолжилась ("число уникальных цветов" от 200 до 220).
В вышеприведенном случае все по-другому.
М.б. при создании PDF что-то могло повлиять, хотя делал все однообразно?

bolega

Цитата:

Но здесь нет почему-то deskew.

Забыл упомянуть. Deskew я делаю над ещё серыми сканами - т.к. на них поворот точнее работает.

Цитата:

Этапы Вы предлагаете, исходя из якобы простоты для чайника. А мне кажется наоборот.

А как Вы себе представляете выполнить всю эту работу за один этап? Это гораздо сложнее. Главная сложность тут - отсутствие хелпа к СК. Совершенно нет гарантий, что удастся без сбоев-накладок сделать всё за один присест. А при многоступенчатой работе - и СК не надо так уж глубоко знать (т.е. те "тонкости"), и "откатиться назад" проще (на всём процессе сканобработки) - просто вернуться на предыдущую стадию.

Доп. сложности такие:

1. Левые и правые страницы.

2. Медленность перелистывания серых сканов (по сравнению с ЧБ) при корректировке резаков после DK.

3. DK вроде бы сбрасывает вручную выставленные флажки - но точно не знаю и рисковать зря не хочу.

4. Сначала у меня сканы почему-то покромсались не по центру, а поля получились большие. Почему - не знаю, да и не хочу разбираться (без хелпа это потребовало бы экспериментов - но и всё равно - без гарантий бессбойности). Проще заново перекромсать сканы - да и всё.

Цитата:

Если юзер - чайник, что он может понять в промежуточных результатах этих этапов?

А какая разница? Юзеру всёравно нужно в каждый момент времени чётко осознавать - что он делает, зачем, и что из этого получается. А Вы хотите видеть СК в качестве "чёрного ящика" - чтобы юзер и не понимал, что он, собственно делает? Вот уж действительно я -
Цитата:

[Подавив изумление Вашим подходом]

bolega

Цитата:

А какже тогда определить на какой странице 2-го (или к примеру 10-го) файла находится изображение, если у меня будет только его номер. Вычитать сумму страниц последовательных файлов, пока не попадешь на нужный?

М.б. это решается добавлением поля с префиксом, как это есть в других программах, вытаскивающих сканы из пдф?

bolega

Цитата:

Он ведь не в состоянии толком оценить ни правильность, ни качество. Ему наоборот будет тяжело понять из какого этапа пошел косяк.

А это уже - дело техники. Надо всё подробно рассказать, дать примеры, снабдить картинками - "до" и "после", описать словами критерии "до" и "после". Не совсем же юзер чайник - чтобы всё это не суметь понять.

А если всё же чайник - то и тут многоступенчатый подход демонстрирует неоспоримое преимущество перед Вашим одноступенчатым: чайник сможет хотя бы разрезать сдвоенные развороты, сделать deskew и бинаризацию - ну и хватит с него (и всё это - каждый раз открывая СК заново - поскольку нет на то соответствующих простейших-элементарных программ). Даже это всё же гораздо лучше, чем тупо дежавючить сырые серые сканы (как сейчас поступают чайники).

Даже ScanAndShare сложнее для понимания, чем многоступенчатый подход (т.к. ScanAndShare - одноступенчатый - в части работы с СК).

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

Конкретные сканы могут быть настолько экзотичными, что их нужно будет где-нибудь в Noise Ninja промежуточно обработать - в качестве одной из стадий многоступенчатого подхода. А, к примеру, Book Restorer даёт наилучшую бинаризацию и выравнивание освещённости (ИМХО) - на иных сканах приходится прибегать к Book Restorer.

shch_vg

Цитата:

М.б. это решается добавлением поля с префиксом, как это есть в других программах, вытаскивающих сканы из пдф?

Я так и сделал. Но я говорю про общий случай (я как разработчик всегда рассматриваю все возможные случаи): сделал импорт из нескольких pdf (пусть 2-х). Получил файлы
f01_p0001.tif
f01_p0002.tif
....
f02_p0001.tif
f02_p0002.tif
....
где fyy - номер файла,
pxxxx - номер страницы в файле.
Завтра мне пришлют 3-й файл, я должен добавить его в задание.
Так вот, перед импортом нового файла СК должен просканировать папку с существующими файлами, чтобы найти последний номер yy. Потому что если он снова начнет нумеровать с f01_p0001.tif, он затрет предыдущий импорт.



Добавлено:

Цитата:

Столкнулся со следующей непонятной ситуацией

Я бы списал все это на то, что jpg - формат с потерями (даже при 100%), поэтому при восстановлении появляются новые цветы (возможно, всего лишь по одному пикселу каждого нового цвета).
Может быть на разницу влияет наличие векторных или растровых рисунков, теней и т.д.
Вообщем, я не готов ответить на Ваш вопрос. Это требует серьезного изучения.

Добавлено:
monday2000
Так может Вам проще СТ слегка переделать. Там четкое разделение на этапы, добавить только вывод промежуточных результатов в файлы и все, делов-то.

bolega

Цитата:

Так может Вам проще СТ слегка переделать.

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

Добавлено:
bolega
Ещё одна идея: при разрезке сдвоенных разворотов, по команде "скопировать позицию резака" - "все вниз" Split-резак мог бы автозапоминать свою последнюю позицию по горизонтали (когда я его мышкой подвинул) - и не "сбиваться" при переходе на следующий скан (на позицию до ручного сдвига мышкой).

А сейчас приходится лишний раз (когда я его мышкой подвинул) вызывать "скопировать позицию резака" - "все вниз" - неудобно.

shch_vg
Вот еще одно соображение. JPG при сильном сжатии вносит искажения в виде паразитной окраски (читай - новых цветов) вокруг высокочастотных составляющих изображения (там потери и больше), по простому говоря, вокруг контуров букв. На однородных участках искажения заметно меньше. При небольшом сжатии происходит тоже самое, но в гораздо меньших масштабах. Т.е. это проявляется, но на глаз не увидишь.

bolega

Цитата:

Так вот, перед импортом нового файла СК должен просканировать папку с существующими файлами, чтобы найти последний номер yy. Потому что если он снова начнет нумеровать с f01_p0001.tif, он затрет предыдущий импорт.

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

monday2000

Цитата:

Ещё одна идея

Слишком уж неочевидная фича. В таких случаях проще снять галки со всех последующих файлов и двигаться вниз, попутно просто ставя галки (по одной или сразу группой). В этом случае и получится то, что хотите, т.к. при переходе от маркированного на немаркированный файл последний получает все его опции и позиции резаков, остается только зафиксировать их, ставя галку.

Добавлено:
shch_vg

Цитата:

хочу ли я в этом случае затереть имеющееся

В том то и дело, что здесь я решил не надоедать юзеру такими вопросами, все делать автоматом. Даже если юзер задаст некорректное значение NumFrom (такое, что файл с таким именем уже существует), СК сам подкорректирует его без всяких надоедливых вопросов.
Ладно, не берите в голову, что-нибудь придумаю.
Просто хотел уже по быстрому все закончить и выпустить новую версию, а то в 5.93 багов немало, чтож мучиться с ними. Да и вьетнамцы последнее время насели на меня по почте -когда, мол, будет 5.93+. Откуда они только прознали про 5.93.

bolega

Цитата:

Откуда они только прознали про 5.93.

Наверное, китайцы проболтались.

Цитата:

Да и вьетнамцы последнее время насели на меня по почте -когда, мол, будет 5.93+. Откуда они только прознали про 5.93.

Я не вьетнамец, поэтому лишь вежливо поинтересуюсь.. а когда?

Скажите, плз, какие настройки СК помогут уменьшить размер файла при улучшении (сохранении) читаемости подобного скана .

Спасибо

bolega

Цитата:

Слишком уж неочевидная фича.

Я разрезаю сдвоенные развороты вручную - ИМХО это надёжнее, чем автоматическая разрезка в СТ или FR. Для ручной простановки split-резака данная фича ИМХО выглядела бы совершенно естественной. Неестественно - как раз нынешнее поведение СК в этом отношении.

А "неочевидность" легко ликвидировать - достаточно написать статью о разрезке сканов.

Добавлено:

Цитата:

В таких случаях проще снять галки со всех последующих файлов и двигаться вниз, попутно просто ставя галки (по одной или сразу группой).

Не очень-то удобно. Галки я ставлю все сразу изначально. (Кстати - ИМХО галки - это совершеннейшее излишество).

Баг версии 5.92?
Дано: Automargins отключены, Page width/height=fixed, обработка в два этапа.
При финализации из контекстного меню VR каждой страницы отдельно проблем нет. Но при финализации страниц этого же задания из меню Process->Finalize размеры файлов (высота/ширина) не подгоняются под размер книги, т.е. все страницы получаются разной ширины. Обход бага: непосредственно перед финализацией взвести галку Automargins для всех файлов.
Похожие проблемы при работе в один этап:
При отключенных Automargins подгонка ширины страницы осуществляется только при Page width/height=Auto. Если Page width/height=fixed, то все страницы получаются разной ширины.

Ребята, у меня ошибка вылетает на 41 графическом файле Abort када нажимаю кнопку Процесс. Версия Кромсатора Бетта 92 мож из-за этого?

Vladimir54

Цитата:

Версия Кромсатора Бетта 92 мож из-за этого?

Думаю, скорее из-за кривых сканов.
Picture-зоны на этом скане есть?

Вроде баг?

На входе в СК - uncompressed tiff с цветностью 24 bit
В самом Кромсаторе слева снизу, где выводится информация о файле, пишется 16777216 colors.
При обработке ставлю Color = Original.
На выходе получаю визуально обесцвеченную (Grey) картинку.
Смотрю истинную цветность файла - 24 bit.
Тогда явно задаю Color = Color (24bit)
Результат тот же.

Vladimir54

Цитата:

Версия Кромсатора Бетта 92 мож из-за этого

Да, в этой версии баг - утечка памяти. Юзайте 5.93, там исправлено.

Arbat111

Цитата:

Automargins отключены

А зачем народ вообще отключает Automargins???
Там не то, чтобы баг, но путаница в СК, когда Automargins отключен.
Отключенный Automargins - это вообще то не то, для чего СК делался.
Но все равно разбираться буду, раз такое дело.

Torino
Был такой баг, если Color = Original задавать не глобально, а на закладке Special.
Уже исправил. Если убрать deskew, то он не проявляется

Уважаемый Bolega! Спасибо за новую версию кромсатора! Давно хотел спросить у Вас, нельзя ли добавить поддержку азиатских книг (например, японских), т. е. книг, которые читаются с конца к началу (по нашим представлениям). Имеется в виду, чтобы при разрезании листа на страницы и сохранении файлов, первым считался бы правый разворот, а вторым - левый. Сейчас приходится после разрезки вручную переименовывать номера файлов, чтобы восстановить правильную нумерацию. Поэтому такая опция "Азиатская книга" была бы очень полезна на закладке Files, где мы устанавливаем как нумеровать файлы. Спасибо!

P.S. Возможно, что это реализовано как-то уже сейчас и я просто невнимателен? В таком случае, прошу меня извинить.

Zelda
OK. Сделаю

Цитата:

Zelda
OK. Сделаю

Спасибо большое!