Ещё похожая програмка Zim (zim-wiki.org) Это текстовый редактор позволяющий создавать wiki подобную структуру связанных страниц, использует для этого только папки и текстовые файлы(txt).
Спасибо за статью, очень интересный результат) Хочу поделиться парой наблюдений.
На последней картинке ещё один явный артефакт — люди отбрасывают мелкие детали на эскизах, особенно если их много и они не существенны. Конкретно береговая линия в исполнении человека была бы ровная или почти ровная.
Ещё есть чисто человеческая особенность при штриховке — если штрих разделён на два отрезка контуром фигуры, часто эти отрезки не на одной прямой и даже не на параллельных. Плотность штрихов в таких разнесённых областях тоже может слегка отличаться.
Плотность штриха вдоль границы фигуры в зависимости от наличия соседних областей, сложности формы, плотности штриховки и т.п может как падать, так и увеличиваться. В некоторых случаях штриховка может менять тип в сложных местах.
Штриховка при достаточной длине образована обычно не прямыми, а дугами, просто из-за механики движения руки.
При штриховке больших областей может разбиваться не несколько областей, внутри области штриховка обладает более-менее одинаковыми параметрами, а между областями слегка отличается(но конечно слабее чем у разных фигур)
При строительстве ездит техника и развозит на колёсах грунт со стройки. При стройке грунт копают, а могильник как раз под землёй, т.е развезут самое фонящее. Оно превратится на дороге в пыль и разнесётся по всему городу.
Точно попадёт в реку.
Часть земли будут куда-нибудь вывозить, если её будут декларировать чистой, то возить будут в открытых грузовиках, разнося эффективнее. А потом просто свалят неизвестно где заражая ещё больше территории.
Если бы признали, что там есть загрязнение, то было бы два более-менее правильных пути — отказаться от проекта хорды на этом месте и укрепить могильник(чтоб не фонило и не утекало), либо вывезти весь загрязнённый грунт со всеми мерами предосторожности, дезактивацией и контролем в новый могильник, но уже сделанный по современным стандартам, и на очищенной земле начать стройку. Но это очень дорогая и сложная операция, поэтому решили подделать документы и строить так. Потом когда поднялся шум решили рекультивировать, но уже доверия к тому что сделают эту операцию как следует у меня что-то нет.
Если что, про медленно это про словарь функций… Тестировал. Не быстро. И неестественно. Решение противоречит дзену питона, так что не я решаю))
Pattern matching соответствует, но цепочка if-ов это по прежнему не быстро.
import time
def switcher(condition):
lambdadict = {13:lambda x, y: x+y,
12:lambda x, y: x*y,
16:lambda x, y: x/y,
1:lambda x, y: x**y}
return lambdadict[condition] if condition in lambdadict else lambda x, y: x
def test_switcher(inp):
A = 0
for n,i,j in inp:
A += switcher(n)(i, j)
return A
def test_ifs(inp):
A = 0
for n,i,j in inp:
if n == 1: A += i**j
elif n == 12: A += i*j
elif n == 13: A += i+j
elif n == 16: A += i/j
else: A += i
return A
funcs = (1, 12, 13, 16, 2432)
inp = [(funcs[n % 5], funcs[n % 5]//3, n) for n in range(10000)]
test_ifs(inp)
test_switcher(inp)
times = 0
A = 0
for i in range(1000):
t1 = time.perf_counter_ns()
A += test_ifs(inp)
times += time.perf_counter_ns() - t1
times /= 1000
print('ifs test average by 1000 reps: %i ns' %times)
times = 0
A = 0
for i in range(1000):
t1 = time.perf_counter_ns()
A += test_switcher(inp)
times += time.perf_counter_ns() - t1
times /= 1000
print('switcher test average by 1000 reps: %i ns' %times)
input('any')
результат:
ifs test average by 1000 reps: 1908833 ns
switcher test average by 1000 reps: 7090622 ns
В 3.5 раза… это медленно.
И медленнА, и не естественнА и чем так лучше уж без.
А это похоже на switch и читаемость будет получше, но в switch всегда была фишка в быстром сопоставлении, если здесь генерируется код аналогичный лесенке из if-ов(всегда, без оптимизированных исключений), то ценность этой фичи весьма умеренная… а после того как 7-ку дропнули, просто ещё и не светит)
А типа авторотации ничего нельзя сделать? Чтоб крылья под набегающим потоком в нейтральное положение перемещались? Если привод от мотора сделать через фрикционную муфту, как крыло себя поведёт при остановке двигателя (т.е есть трение, препятствующее движению, но оно ограничено)? Ладно, это уже явно пошли не вопросы а «бесплатные советы»)) Очень здорово, буду ждать новых статей)
Два вопроса:
1) За счет чего управляется FlapFlyer? Хвостовое оперение или изменение угла атаки крыльев?
2) При остановке двигателя, крылья останавливаются в случайном положении, в общем случае выглядит так, что симметрия нарушается(судя по видео). Как это сказывается на управляемости и возможности планирования и что с этим предполагается делать?
Этот подход не бесплатный с точки зрения производительности. Поэтому в библиотеках он ещё хуже. Библиотека может оказаться довольно глубоко в цепочке зависимостей и любая её неэффективность будет множителем в общей производительности. Библиотеки как раз надо оптимизировать под периодическую читаемость(вероятно даже не авторами), стабильность требований и высокую производительность. А тут предлагается решение как раз для облегчения модификации, если оно эту задачу не решает, то оно так же эффективно как и SOLID.
Если эффекты параметризованы, то просто добавьте регулировку и будет шик(для свечения — интенсивность/размер ореола, для 3д — амплитуду искажения по X и Y)
А так выглядит классно, но свечение очень размывает картинку.
Кстати можно поэкспериментировать с наложением эффектов в фон символов, познакоместно, например в огонь, взрывы, дым или жидкости.
Я правильно понял, что если один элемент имеет площадь 1 см2, то таких элементов для запитки чего-нибудь более-менее полезного нужно около 40 шт(напряжение 1.2В, ток 1 мА)? И какой объём займет такая сборка?
Или один элемент имеет большую площадь?
Картинки именно что похожи(третью специально по цветам подбирал), поэтому результат близкий. Ниже пример непохожей картинки, результат явный.
если для «похожих» мера сходства около 85%, то от них с явно непохожей -2… 5%.
Я не говорю что простое определение расстояния хороший метод классификации(см. «похожие» картинки), но он даёт стабильный и предсказуемый результат, при этом метод простой как грабли. К тонкостям качества картинки он тоже умерено чувствителен(считай робастный). Поэтому задумывая классификатор и распознавание изображений, надо добиваться результата не хуже.
Не вопрос, но это надо было подумать)) В данном конкретном случае скорость безразлична. Плюс так любой, в том числе не знакомый с питоном, разберётся что именно тут написано.
Но да, можно оптимизировать.
import pygame
import os
import numpy as np
#from math import sqrt
P1 = pygame.surfarray.array3d(pygame.image.load(os.path.join("Pictures","TestImage1.png")))
P2 = pygame.surfarray.array3d(pygame.image.load(os.path.join("Pictures","TestImage2.png")))
P3 = pygame.surfarray.array3d(pygame.image.load(os.path.join("Pictures","TestImage3.png")))
(R,G,B) = (0,1,2)
Sum12 = Sum13 = Sum23 = 0
for x in range(512):
for y in range(512):
for color in (R,G,B):
Sum12 += abs(float(P1[x][y][color]) - float(P2[x][y][color]))
Sum13 += abs(float(P1[x][y][color]) - float(P3[x][y][color]))
Sum23 += abs(float(P2[x][y][color]) - float(P3[x][y][color]))
Norma = 255*3*(512**2)
N12 = Sum12/Norma
N13 = Sum13/Norma
N23 = Sum23/Norma
def makeMono(Array):
New_Array = np.zeros(Array.shape)
for x,row in enumerate(Array):
for y,(R,G,B) in enumerate(row):
New_Array[x][y] = int((0.299*R**2 + 0.587*G**2 + 0.114*B**2)**0.5)
return New_Array[:,:,0]
Pm1 = makeMono(P1)
Pm2 = makeMono(P2)
Pm3 = makeMono(P3)
SumM12 = SumM13 = SumM23 = 0
for x in range(512):
for y in range(512):
SumM12 += abs(float(Pm1[x][y]) - float(Pm2[x][y]))
SumM13 += abs(float(Pm1[x][y]) - float(Pm3[x][y]))
SumM23 += abs(float(Pm2[x][y]) - float(Pm3[x][y]))
Norma = 255*(512**2)
Nm12 = SumM12/Norma
Nm13 = SumM13/Norma
Nm23 = SumM23/Norma
Результаты при сохранении цвета N11,N12 и N23 (расстояния между соотв. изображениями):
N11 = 0.144
N12 = 0.191
N23 = 0.176
Не ахти, но два ближайшие показаны верно и это метод «в лоб»
Результаты при обесцвечивании Nm11,Nm12 и Nm23:
Nm11 = 0.141
Nm12 = 0.180
Nm23 = 0.152
Суть та же, результат верный. Метод элементарный «в лоб».
Если надо, могу исходные гифки выложить.
PS исправил ошибку в коде. N от Nm теперь почти не отличаются.
PSPS. Подскажите как это можно свернуть, чтоб простынёй не висело? ))
От чего же не будет? Специально только что попробовал(в GIMP). Взял RGB изображение из стандартных виндовых, сохранил как gif, открыл и преобразовал обратно в RGB. Искажения есть, но они небольшие. Разница между изображениями мизерная (Самое яркое искажение не больше 20 по каждому каналу, различимых глазом точек не много). Соответственно и расстояние будет небольшое. Как и должно для сильно схожих изображений. Поэтому должно сработать
Переводим изображение в RGB и по каждому каналу для каждого пикселя считаем корень из модуля разности квадратов значений для двух изображений(либо просто модуль разности). Полученные таким образом расстояния по всем каналам и всем пикселям просто складываем. Получаем одно число, которое тем меньше, чем изображения более схожи.
Для большей ясности. Изображение 1 назовём P1, А изображение 2 — P2.
Пиксель имеет координаты XYС, где C это цветовой канал R,G или B, а X Y это положение. Ниже алгоритм на питоне, в предположении, что изображение это трёхмерный массив.
def PicDist(P1,P2)
sum =0
for x in range(X):
for y in range(Y):
for C in ['R','G','B']:
sum += sqrt(abs(P1[x][y][C]**2 - P2[x][y][C]**2))
return sum
Согласен с VDG.
Странный подход, по идее любой машинный классификатор изображений должен удовлетворительно справляться с классификацией того, что легко классифицирует человек(иначе не стоит и браться). В данном случае, человеку похожие изображения сопоставить не то что не проблема, а даже не задача. Даже простой попиксельный подсчёт дистанции даст однозначный результат.
Если я правильно понял, волна начинает формироваться из области с интенсивностью выше некоторого порога, по идее это для двух случайно зашумлённых изображений даст, в общем случае, случайный результат, который в волнах высших порядков может быть сойдётся к чему-то более-менее общему. Звучит как-то не очень надёжно.
Вывод, предложенный метод не работает.(А как он может работать вообще, без хотя какой-то нормализации входных данных, мне не понятно.)
Ещё похожая програмка Zim (zim-wiki.org) Это текстовый редактор позволяющий создавать wiki подобную структуру связанных страниц, использует для этого только папки и текстовые файлы(txt).
На последней картинке ещё один явный артефакт — люди отбрасывают мелкие детали на эскизах, особенно если их много и они не существенны. Конкретно береговая линия в исполнении человека была бы ровная или почти ровная.
Ещё есть чисто человеческая особенность при штриховке — если штрих разделён на два отрезка контуром фигуры, часто эти отрезки не на одной прямой и даже не на параллельных. Плотность штрихов в таких разнесённых областях тоже может слегка отличаться.
Плотность штриха вдоль границы фигуры в зависимости от наличия соседних областей, сложности формы, плотности штриховки и т.п может как падать, так и увеличиваться. В некоторых случаях штриховка может менять тип в сложных местах.
Штриховка при достаточной длине образована обычно не прямыми, а дугами, просто из-за механики движения руки.
При штриховке больших областей может разбиваться не несколько областей, внутри области штриховка обладает более-менее одинаковыми параметрами, а между областями слегка отличается(но конечно слабее чем у разных фигур)
Точно попадёт в реку.
Часть земли будут куда-нибудь вывозить, если её будут декларировать чистой, то возить будут в открытых грузовиках, разнося эффективнее. А потом просто свалят неизвестно где заражая ещё больше территории.
Если бы признали, что там есть загрязнение, то было бы два более-менее правильных пути — отказаться от проекта хорды на этом месте и укрепить могильник(чтоб не фонило и не утекало), либо вывезти весь загрязнённый грунт со всеми мерами предосторожности, дезактивацией и контролем в новый могильник, но уже сделанный по современным стандартам, и на очищенной земле начать стройку. Но это очень дорогая и сложная операция, поэтому решили подделать документы и строить так. Потом когда поднялся шум решили рекультивировать, но уже доверия к тому что сделают эту операцию как следует у меня что-то нет.
Pattern matching соответствует, но цепочка if-ов это по прежнему не быстро.
результат:
ifs test average by 1000 reps: 1908833 ns
switcher test average by 1000 reps: 7090622 ns
В 3.5 раза… это медленно.
А это похоже на switch и читаемость будет получше, но в switch всегда была фишка в быстром сопоставлении, если здесь генерируется код аналогичный лесенке из if-ов(всегда, без оптимизированных исключений), то ценность этой фичи весьма умеренная… а после того как 7-ку дропнули, просто ещё и не светит)
1) За счет чего управляется FlapFlyer? Хвостовое оперение или изменение угла атаки крыльев?
2) При остановке двигателя, крылья останавливаются в случайном положении, в общем случае выглядит так, что симметрия нарушается(судя по видео). Как это сказывается на управляемости и возможности планирования и что с этим предполагается делать?
А так выглядит классно, но свечение очень размывает картинку.
Кстати можно поэкспериментировать с наложением эффектов в фон символов, познакоместно, например в огонь, взрывы, дым или жидкости.
Или один элемент имеет большую площадь?
если для «похожих» мера сходства около 85%, то от них с явно непохожей -2… 5%.
Я не говорю что простое определение расстояния хороший метод классификации(см. «похожие» картинки), но он даёт стабильный и предсказуемый результат, при этом метод простой как грабли. К тонкостям качества картинки он тоже умерено чувствителен(считай робастный). Поэтому задумывая классификатор и распознавание изображений, надо добиваться результата не хуже.
Но да, можно оптимизировать.
Четвёртое изображение специально контрастное прошлым.
Результаты:
N14 = 1.021
N24 = 0.97
N34 = 0.95
Nm14 = 0.290
Nm24 = 0.266
Nm34 = 0.216
тестовые изображения.
Тестовый код на питоне:
Результаты при сохранении цвета N11,N12 и N23 (расстояния между соотв. изображениями):
N11 = 0.144
N12 = 0.191
N23 = 0.176
Не ахти, но два ближайшие показаны верно и это метод «в лоб»
Результаты при обесцвечивании Nm11,Nm12 и Nm23:
Nm11 = 0.141
Nm12 = 0.180
Nm23 = 0.152
Суть та же, результат верный. Метод элементарный «в лоб».
Если надо, могу исходные гифки выложить.
PS исправил ошибку в коде. N от Nm теперь почти не отличаются.
PSPS. Подскажите как это можно свернуть, чтоб простынёй не висело? ))
Для большей ясности. Изображение 1 назовём P1, А изображение 2 — P2.
Пиксель имеет координаты XYС, где C это цветовой канал R,G или B, а X Y это положение. Ниже алгоритм на питоне, в предположении, что изображение это трёхмерный массив.
Странный подход, по идее любой машинный классификатор изображений должен удовлетворительно справляться с классификацией того, что легко классифицирует человек(иначе не стоит и браться). В данном случае, человеку похожие изображения сопоставить не то что не проблема, а даже не задача. Даже простой попиксельный подсчёт дистанции даст однозначный результат.
Если я правильно понял, волна начинает формироваться из области с интенсивностью выше некоторого порога, по идее это для двух случайно зашумлённых изображений даст, в общем случае, случайный результат, который в волнах высших порядков может быть сойдётся к чему-то более-менее общему. Звучит как-то не очень надёжно.
Вывод, предложенный метод не работает.(А как он может работать вообще, без хотя какой-то нормализации входных данных, мне не понятно.)