mayton2019

Я помню что в умных статьях, которые сравнивают алгоритмы сжатия типа JPEG/J2k/Lurawave
часто приводили параметр PSNR (Peak signal-to-noise ratio) и на базе него пытались
построить какие-то выводы. Период этих революций сжатия приходился примерно на 2000-е годы.

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

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

Вобщем сравнивать вам придется не по 1 параметру а по вектору. Увы-увы... в наше современное
время маш-обучения сравнение векторов это нормально. Так и должно быть.

Вот https://www.wordclouds.com/

Фильтр Гаусса ничего не знает о цвете. Он просто применяется к матрице вещесвтенных чисел.
Поэтому обычно картинку в формате RGB переводят в трех-слойную вещественную матрицу { double, double, double }
и фильтр Гаусса применяют трижды для каждого слоя. И результат потом снова сводят в RGB.

Есть миллиард хитростей как делать это в целых или в вещественных числах или как использовать SIMD, Parallel
computing e.t.c. но ты сделай сначала самый простой и работающий вариант а потом уже оптимизация.

С оптимизацией неизбежно сталкиваются все новички на цифровых фильтрах. Потому-что без нее фильры
работают на порядки медленнее чем в Photoshop например.

Можно попробовать сохранить эти точки в SVG-файл. Там формат - простой.

Что надо делать.?
Не понимаю, с чего начать.

Вообще если у тебя так много непоняток - то начни не с изображений а с 1-мерного графика.
Курс валют например. Или ход температуры за сезон. Разберешся - дальше пойдешь.
А если ты сейчас даже какую-то фигню закодишь
- то как ты проверишь что правильное преобразование сделал?

Начни с контракта. Что приходит тебе на вход? Вот это вот
double[] x, double[]y

С моей точки зрения - тут должна быть картинка. Image. На следующем уровне ты ее разбиваешь
на цветовые слои. Красный зеленый ит.д. Потом эти слои разбиваешь на фреймы (8х8 пикс как в jpg).
Потом их нормируешь от цвета пиксела до вещественного значения. И вот уже когда ты получишь
матрицу вещественных значений - тогда и можно приступать к Фурье. Усек? У тебя хедер
функции должен иметь такие параметры чтобы тебе было все кристально ясно что за аргументы и как.

А так конешно у тебя каша в голове.

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

И дальше - делаешь все в обратном направлении. От Фурье к картинке. Получиться картинка - молодец.
Значит правильно сделал.

Наверное лучше брать Python для работы с картинками. Под него много софта написано.
В том числе научного. Для сложных задач.

По поводу "собираюсь сделать прогу". Тебе надо обозначить правильную цель. Потому что изучать
node это одна цель. А делать фильтр картинок это совсем другое. Смыслы как-бы разные.

Надо посмотреть что за шум. Есть шум типа недостаточная экспозиция. При слабом свете была сделана фотка
и по ней цветные пиксели появляются. Свойство света мать ево. Корпускулярные свойства. Частица попала
только на красный либо линий либо зеленый элемент. Тут наверное будет один алгоритм фильтрации.

Если шум вида пыль и царапины на отсканированном фото - то это наверное будет другой фильтр.

Шум может быть низко-частотный. Цветовой блик или пересвет части изоборажения с уголка. Солнце в линзу попало.

Логотип фото-хостинга я-бы тоже считал шумом да. :) Смотря под каким углом смотреть на проблему.

Digital Signature с авторскими правами :) Тоже типа шум. Смотря для кого. :)

Есть алгоритм Монте-Карло. Ты просто кидаешь рандомные точки на экран и считаешь попадает ли точка в фигуру или нет. Соотношение попаданий к общему число бросков даст тебе соотношение площади фигуры и площади области бросков (экрана).

Данный метод универсален. Быстр и позволяет аппроксимипровать площать (выдавать приближенное значение) еще до того как будут посчитаны все точки).

Решение о попадании можно принимать по цвету пиксела.

Если на экране находится несколько фигур одного цвета - то соотв будет посчитана их общая площать.

Задача распознавания образов (а именно так звучит на самом деле постановка) имеет очень мало отношения к C#.
Я-бы советовал автору вообще забыть про C# а искать сверточные (convolution) нейронные сети которые ищут в картинках нечто знакомое на любых (на всех языках разработки). Когда стоит такая амбициозная задача - то нужно вообще забыть про язык и мыслить категориями математики и известрых алгоритмов НС.

Задача сразу скажу - сложная. И на 99% - кастомизируемая. Тоесть вы не найдете готовых шаблонов или походов к решению. Вы будете почти все делать самостоятельно. Особенно в части обучающей выборки и методики обучения. И в части выбора качества модели.

С высокой вероятностью вы найдете примеры похожих решений на Python/OpenCV.- Ваша задача будет заключаться в поиске полезного что можно почерпнуть из готового метода. И уже потом адаптировать под C# что можно из этого стека. Но опять-же ... C# здесь совершенно вторичен.

Весят чет многовато даже после компрессии.

Все очень просто. Зависимость размера от ширины - квадратичная.
Это означает что размер картинки растет не линейно а в квадрате от
одного из измерений. И JPEG/WebP здесть не помогает т.к его алгоритмы
не меняютс своих свойств от размера. Обычно ты задаешь коэфф сжатия
или он берется по дефолту. Ставить более сильное сжатие нет смысла
т.к. портится качество мелких деталей. А если портить - то нахрена
увеличивать размер?

Пример такого расчета в сыром размере RBG байтов:

Разрешение FullHD 1920 x 1080 = 2073600 pix = 2073600 * 3 = 6 220 800 bytes
Тоже самое в два раза больше в поперечнике 3840х2160 = 8294400 pix = 24 883 200 bytes
Итого размер стал в 3 раза больше. Для 8К разрешения ситуация станет хуже во много раз.

Поэтому увеличивать разрешение нужно очень осторожно.

Почти все современные редакторы умеют работать с векторной графикой. Если есть рисование кистью сплайнов или просто геометрических фигур - то считай уже векторный. В противоположность и Adobe Illustrator умеет фотки в себя затягивать. Тоесть деление это сугубо условное. Как сельхоз-продукция и пром-товары. Я-бы предложил просто найти в википедии и почитать как оно классифицировано там.

Предположительно на картинке канал V(яркость) заменили на градиент радуги.

Можно попробовать сделать 2 фото. Одну во время дождя. А другую в ясную погоду. Со штатива и не двигая между снимками. Потом попробовать сравнить 2 фотки и посмотреть какие артефакты дает дождь.

Да и в данном вопросе есть два "хитрых" смысла. Есть художественный смысл. Типа улучшить фото. Этим занимаются художники. И есть смысл информационный. Например понять какой номер машины был замечен в плохую погоду и попытаться его распознать. Вот этот второй смысл - он про другое и к убиранию дождя не имеет отношения. Я-бы сказал что для систем машинного зрения лучше вообще дождь не фильтовать а сразу давать сырое на вход. Это более честно.

Я могу изготовить картинку где фон - принципиально неотделим от основного изображения (например моего лица).
Это может быть например эффект наложения моего лица с фоном с альфа-каналом где альфа канал - это круговой градиент. Тоесть в центер картинки - точно-точно лицо. А на краях - точно градиент. Но где происходит граница - неясно.

Я готов спорить что никакой даже очень умный нейро-алгоритм не сможет правильно решить где заканчивается фон и начинается ценная информация.

Можно попробовать генетические алгоритмы. Где хромосомы - суть 4 измерения эллипса кандитата. А fintess function берется как некая дельта между картинкой и эллипсом. (Здесь автор должен сам расскажать какие ожидаются толщина эллипса и фильтрация. И есть ли у него вообще толщина? ).

Но генетика может дать парадоксальные результаты. Тоесть может находить лже-эллипсы в самых неожиданных места. И неясно также что делать когда будет более чем 1 решение.

Лучше - бы автор привел пример картинки.

В топике КМК спутаны несколько вопросов. Сжатие и кроп - это разные методы. И crop теоретически
повреждает картинку убирая из нее потенциально значимую часть сведений (копирайты или
надписи внизу). Поэтому надо обговорить твоё задание не с бухты-барахты а более детально.

Что делает imagecompressor - я не знаю. Но предположительно он берет JPEG и прогоняет по нему WEBP
алгоритмы и потом перегоняет обратно в JPEG используя некую совместимость между ними. В цифру
70 % я не поверю. Там скорее всего идет какой-то нечеткий критерий. А в условиях нечеткости можно написать
любые проценты и при этом окружающие покивают головами ведь критерий-то нечеткий.

По поводу сервиса. Я-бы поднял AWS-Lambda и поставил туда какой-то опенсорцный JPEG-WEBP кодек
и использовал бы для себя как конвертер. Но по последнему пункту тебе надо искать программиста
под AWS.

Да. Если ты сохраняешь в JPEG то он тебе подкинет свинью. Тк работает не с дискретным а с непрерывным (синусно-косинусным) представлением маленьких фрагментов картинки.

Реально тебе нужна гарантия что destination будет всегда в форматах GIF/PNG т.к только они гарантируют точное соотвествие цвета на входе и на выходе.