1. Пользоваться форумом на планшетах и телефонах стало удобнее благодаря Tapatalk

Invert...

Тема в разделе "Apple Shake", создана пользователем -, 31 май 2002.

Модераторы: Григорий Чаленко
  1. Guest

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

    Не вполне тебя понял. Invert по luma?
    Вот два варианта

    Grad1 = Grad(720, 486, 1, 0.5, 0.5, 1, 0, 0, 1, 0, 0, 1, 0, 1,
    0, 0, 0, 1, 1, 0, 0, 0, 0, 1, 0);
    Grad2 = Grad(720, 486, 1, 0.5, 0.5, 1, 0, 0, 1, 0, 0, 1, 0, 1,
    0, 0, 0, 1, 1, 0, 0, 0, 0, 1, 0);
    LookupHLS1 = LookupHLS(Grad2, JSplineV(x,1,0@0,1@1), JSplineV(x,1,1@0,0@1),
    JSplineV(x,1,0@0,1@1), JSplineV(x,1,0@0,1@1));
    LookupHSV1 = LookupHSV(Grad1, JSplineV(x,1,0@0,1@1), JSplineV(x,1,0@0,1@1),
    JSplineV(x,1,1@0,0@1), JSplineV(x,1,0@0,1@1));


    // User Interface settings

    SetKey(
    "nodeView.Grad1.x", "526.875",
    "nodeView.Grad1.y", "599.875",
    "nodeView.Grad2.x", "723.75",
    "nodeView.Grad2.y", "599.25",
    "nodeView.LookupHLS1.x", "706.25",
    "nodeView.LookupHLS1.y", "524",
    "nodeView.LookupHSV1.x", "507.5",
    "nodeView.LookupHSV1.y", "530.5"
    );


    Некоторые баги могут быть связаны с тем, что перевод RGB -> HLS, HSB и т.д. не вполне однозначен (зависит от, так называемого, luminance bias)
     
  3. Guest

    ...и нашел более красивое решение


    Grad3 = Grad(720, 486, 1, 0.5, 0.5, 1, 0, 0, 1, 0, 0, 1, 0, 1,
    0, 0, 0, 1, 1, 0, 0, 0, 0, 1, 0);
    ColorSpace1 = ColorSpace(Grad3, "rgb", "hls", 0.3, 0.59, 0.11);
    Invert1 = Invert(ColorSpace1, "g");
    ColorSpace2 = ColorSpace(Invert1, "hls", "rgb", 0.3, 0.59, 0.11);




    То же самое, что с LookupHLS, НО!!! в этом случае ты можешь вмешиваться в процесс конверсии RGB -> HLS -> RGB (тот самый luminance bias о котором я писал выше)
     
  4. Guest

    Здесь появились новые цвета (розовый и т.д.). Простым инвертированием
    luminance здесь не отделаешься. Если представить себе исходную картинку
    как набор цветов то получится вполне ограниченное кол-во. А в исходной
    картинке цвет каждого пикселя нужно заменить на цвет из набора, наиболее
    близкий к исходному по тону (H) и наиболее близкий к инвертированному по
    яркости (L). Извиняюсь за сумбурную формулировку, но точнее пока не могу :)

    Если на примере: есть видео с откорректированными цветами, которые менять нельзя, но при этом нужно "отсечь" некоторые части изображения эффектом
    похожим на invert. Что-то вроде этого..
     
  5. Guest

    Хотя третий вариант ничего но..
     
  6. Guest

    Третий, по математике, то же самое, что второй (LookupHLS), только управляемый (еще раз повторю, перевод RGB->HLS неоднозначен, ну это как RGB->CMY, если ты хоть немного занимался полиграфией или, скажем, цветными фотокинопроцессами, то поймешь о чем я говорю).

    Судя по твоей "сумбурной формулировке" :) тебе нужен первый вариант (LookupHSB), в этом случае перевод из одного пространства в другое однозначен и не будет banding, который четко видно на градиенте во втором и третьем вариантах.

    Кстати, Hue во всех случаях неизменна (!!!)
     
  7. Guest

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

    Что-то подсказывает мне что без pluginoписания здесь не обойтись :(
     
  8. Guest

    Тогда пиши витиеватые expressions при помощи ColorX, с ее помощью можно описать все что угодно, включая indexed colors :)
     
  9. Guest

    Можно? Такой expression, боюсь, мне не по зубам. Но все равно спасибо.
     
  10. Guest

    Вопрос насколько это будет громоздко реализовано. Дело в том, что ноды, вроде ColorX, DisplaceX и т.д. интерпретируются on the fly (то есть компиляция кода происходит в момент работы, программисты называют это "интерпретация"), что весьма тормозно (ты наверное обратил внимание, что проект, который я запостил вчера, считается гораздо медленнее, чем проект с обычным iDisplace)! Если нужны действительно сложные по математике вещи, то их рекомендуют писать на SDK. Где бы его только найти :))

    Shake даже умеет интерпретировать C. Нужно поставить перед командой ':' и дальше пиши на С сколько влезет :)

    Спасибо и тебе, что заставляешь шевелить мозгами... люблю я это дело :)))
     
  11. Guest

    Invert по Luminance
    И color match на глаз корректируешь
    У меня получилось.

    Это-же мера театролной условности зачем тебе абсолютное математическое попадание.
     
  12. Guest

    Согласен...
    Но мозгами надо было пошевелить :)
     
Модераторы: Григорий Чаленко

Поделиться этой страницей