Обрезка составного изображения в canvas

[doktor255]

По тому что нулевая координата у нас находится внизу посередине. Если мы увеличим например ширину, нулевая координата сдвинется вправо, и дальнейшая склейка не совпадёт по координатам. При построении изображения я просто делю ширину рисунка пополам, получая нулевую координату. Если ширина увеличится, придётся менять метод расчёта нулевой координаты. Причём ширина может увеличится как влево, так и вправо от нуля. В общем геморой ещё тот. Проще в процессе построения определять габаритные размеры, что я уже и сделал. Остаётся только обрезать по полученным габаритам.

Если вы считаете что такой расчёт возможен....Что-ж милости прошу попробовать сделать это. Прилагаю тестовый проект. Задача, получить прозрачную png, как на рисунке сверху, нормального размера.

[phomm]

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

Также есть расхождения, я решил на дельфи7 поработать, лень было запускать дхе2 (она на ноуте), путь компиляции бинарника и открытия-сохранения файлов не аналогичны Вашим. Пнгимейдж класс у меня из внешней либы пнгимейдж и называется пнгобджект, там пара методов переобозвано, но, думаю, в целом аналогично всё.
Добавил из упомянутого мной ранее приложеньица моего пару функций, сделал по аналогии с ним саму прорисовку на пнг из бмп.
Ну а расчёт с нуля написал, даже не смотря в Ваш уберкод по сериализации-десериализации параметров склейки (в котором, имхо, запутаться - нефиг делать). Конечно, расчёт негибок, но там всё относительно просто - константы можно вынести в конфиги, имена картинок тоже, и по конфигу грузить и клеить.
Соль расчёта - ищем, кто будет самым левым и самым верхним рисунком, ищем нужные центровые линии, и от них пляшем, согласуясь с офсетами из конфига. Необходимые допостроения (в данном случае собака) производить можно отдельно (её позиция по У рассчитывается из уже рассчитанной до неё из остальных величин высоты рисунка).

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

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

[s-andriano]

Сообщение от doktor255

По тому что

Я задал жва вопроса, на который из них Вы отвечаете?

нулевая координата у нас находится внизу посередине.

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

Если мы увеличим например ширину, нулевая координата сдвинется вправо, и дальнейшая склейка не совпадёт по координатам. При построении изображения я просто делю ширину рисунка пополам, получая нулевую координату.

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

В общем геморой ещё тот.

Повторюсь: причина геморроя - ошибка стадии проектирования.
Храните координату - и никакого геморроя не будет.

Проще в процессе построения определять габаритные размеры, что я уже и сделал.

А это в любом случае нужно делать.

Остаётся только обрезать по полученным габаритам.

А вот это - лишнее.

Впрочем, как раз здесь есть варианты.

Если вы считаете что такой расчёт возможен....Что-ж милости прошу попробовать сделать это. Прилагаю тестовый проект. Задача, получить прозрачную png, как на рисунке сверху, нормального размера.

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

Поясните исходную задачу.
Итак, у Вас есть некоторое начальное изображение.
Далее Вам нужно наложить на него еще несколько изображений.
И результат записать в файл.
Теперь вопрос:
Заранее известно количество и параметры изображений, которые нужно будет соединить?
Другими словами, можно ли решить задачу в два прохода:
1. Перебираем все изображения и вычисляем необходимый размер холста, чтобы на нем поместилось все, что нужно.
2. Создаем холст нужного размера и выполняем все операции по объединению рисунков.

[doktor255]

Сообщение от phomm

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

С изображениями всё в порядке. Пустое пространство там и должно быть, чтоб избежать сдвиги по осям в большинстве случаев. Тем более как понимаете, не я их рисовал. Брал что есть, и клеил.

Сообщение от phomm

Ну а обрезкой получаемой картинки, я в советую пользоваться только в крайнем случае.

Понимаю что обрезка не самый лучший выход, просто видел этот вариант, как самое логичное решение задачи. Да и на будущее всё равно нужно знать. Вдруг мне понадобится именно резать . Как тогда быть? Задумайтесь. За проект огромное спасибо. Сейчас изучу и отпишусь.

[doktor255]

Сообщение от s-andriano

Во всех графических форматах нулевая координата находится слева.

Уверены? Изучите понятие anchor в яве. Чтоб не утверждать подобный бред.

Сообщение от s-andriano

Я же говорил, что ошибка допущена на стадии проектирования, а не на стадии реализации (написания кода).

Ошибка, и не знание способа реализации разные вещи. В методах, применённых мною ошибок нет. А то что они не идеальны, так на то я и прошу помощи.

Сообщение от s-andriano

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

Увеличиваем ширину картинки влево от нуля, и ваша переменная становится бесполезной. Вы сначала вопрос изучите, а потом говорите, что нужно, а что нет.

Сообщение от s-andriano

Заранее известно количество и параметры изображений, которые нужно будет соединить?

Количество известно. Из параметров известны только сдвиги по осям

Сообщение от s-andriano

1. Перебираем все изображения и вычисляем необходимый размер холста, чтобы на нем поместилось все, что нужно.

Изображения лежат на HDD. Чтоб это сделать, нужно либо выделить массив, и загрузить все изображения, либо в цикле грузить в один PngImage, и считать размеры. Оба варианта не приемлемы. С массивом не удобно работать, цикл только нагрузит программу постоянными обращениями к HDD

[s-andriano]

Сообщение от doktor255

Уверены? Изучите понятие anchor в яве. Чтоб не утверждать подобный бред.

А что ява - это графический формат?

Увеличиваем ширину картинки влево от нуля, и ваша переменная становится бесполезной.

С какой это стати?
Если Вы не знаете, как ее использовать, это совершенно не значит, что она становится бесполезной.
Может, Вы не видите разницы между переменной и константой?
Если "!ноль" Вы отсчитываете слева, очевидно при расширении влево значение этой переменной нужно увеличить на величину расширения.

Количество известно. Из параметров известны только сдвиги по осям


Изображения лежат на HDD. Чтоб это сделать, нужно либо выделить массив, и загрузить все изображения, либо в цикле грузить в один PngImage, и считать размеры. Оба варианта не приемлемы. С массивом не удобно работать, цикл только нагрузит программу постоянными обращениями к HDD

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

[doktor255]

s-andriano К сожалению, насколько я понял Вы подогнали расчёты, совершенно не используя входящие данные по сдвигам. Попробуйте пожалуйста исправить ошибку. Вот входящие данные по конкретно данному случаю

Имя картинки; Сдвиг по X; Сдвиг по Y.

w_118_3_;0;0
w_b_0_3_1_;0;0
w_357_3_;0;0
w_353_3_;0;0
77;0;-74
p_5_;20;0
p_pxl;0;-122

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

идея в том, что входящих данных может быть любое количество. Может быть 10 картинок, а может и 100. То есть Нужно работать в цикле по входящим данным а не назначать статичные переменные. К сожалению этих цифр я не увидел поэтому применить данный код не смогу. Помогите пожалуйста доделать ваш код.

Почему я утверждаю, что расчёт не верен, по тому что пиксел p_pxl;0;-122 у нас определил высоту картинки 122 пикселя (опять же это конкретный случай. В других этого пикселя нет вообще), а у Вас высота получилась ниже. Мелочь конечно, но в практичном приминении будут жуткие лаги.

[doktor255]

Сообщение от s-andriano

А что ява - это графический формат?С какой это стати?

Да при чём тут формат???? То что изображения имеют ноль в верхнем левом углу это просто умолчание. А в программировании существует 6 вариантов нулевой точки отрисовки. И в делфи так же это встречается, например в расположении компонентов на форме, и реагировании компонентов на растягивание формы. Один компонент у нас привязывается к верху формы, а другой растягивается на всю форму. Это и есть ANCHOR!!! А вы взяли случай по умолчанию, и утверждаете, что только он правильный!

И пожалуйста не нужно более спорить. Мне помощь по проекту нужна, а не споры. Вы ни как не поспособствовали помощи. Извиняюсь, если обидел Вас. Если так желаете поспорить, прошу в асю 521823.

[phomm]

Сообщение от doktor255

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

Почему я утверждаю, что расчёт не верен, по тому что пиксел p_pxl;0;-122 у нас определил высоту картинки 122 пикселя (опять же это конкретный случай. В других этого пикселя нет вообще), а у Вас высота получилась ниже. Мелочь конечно, но в практичном приминении будут жуткие лаги.

Я так понял, этот пост всё же мне был адресован.
Расчеты я не подгонял. Я назвал свою модель расчета, она требует знания расположения одних элементов относительно других, но она НЕ ТРЕБУЕТ ЗНАНИЯ О РАСПОЛОЖЕНИИ ВСЕХ ЭЛЕМЕНТОВ НА КОНЕЧНОМ РИСУНКЕ. А это и есть Ваша проблема. И у меня и у Вас, по идее, нет никакой ошибки, просто моя схема расчёта не столь запутана, имхо. А у Вас из-за переусложнения не выводится правильный расчёт. У Вас алгоритм завязан на входные данные (хотя конечно Вы их передаёте параметрами). Также Вы плохо прочитали мой пост, я конкретно указал, что константы были использованы для быстроты, всё это надо законфигать для использования.
Применять мой код не стоит, Вы конечно, вряд ли в курсе, но я не даю обычно готовых решений, а только пишу для размышлений и образцы для демонстрации принципов, применять их надо самому.

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

Помогать более у меня нет возможности - начинается рабочая неделя. Да и потом, как-то некрасиво Вы поступаете. Вам стараются помочь решить явно коммерческую задачу, за которую Вы несёте ответственность, а как-то не прислушиваетесь. Ну и уж коли на то пошло. Мой код выполняет описанные требования в посте, где прикреплён Ваш архив ? У меня нет оснований полагать, что не выполняет. Если же Вам надо было более конкретно в каких-то математических рамках - надо было указать всё конкретно и подробно. Да я знаю, что в других постах Вы это расписываете, но я, как и s-andriano вижу переусложнение на ровном месте, и все остальные посты для меня это не попытка найти грамотное решение задачи, а дискуссия, какая матмодель лучше подходит. Потому я и постарался указать, что Ваша матмодель не единственно верная. Коли была бы указана Вами необходимость следовать строго Вашей модели, то тема, скорее всего, закончилась ничем, ну или предложениями проследовать во фриланс.
В общем, взываю к Вашему благоразумию. Поизучайте, пожалуйста, как бы с нейтральной стороны, оцените плюсы минусы, не надо цепляться за свою модель, рассуждайте трезво, если и тогда придёте к выводам, что Ваша лучше, так тому и быть. Ну а если же поймёте , что есть и другие и стоит их рассмотреть - то дискуссия и дальше, думаю, продолжится.

[s-andriano]

Сообщение от doktor255

Мне помощь по проекту нужна, а не споры. Вы ни как не поспособствовали помощи. Извиняюсь, если обидел Вас. Если так желаете поспорить, прошу в асю 521823.

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

А "асю" я принципиально не держу.