On 2018-05-09, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Marcin Debowski <a...@I...zoho.com> writes:
>
>> To jak to sobie właściwie wyobrażasz i co to sa te płynne przejścia?
>
> No normalnie, jak się robi animację w zwolnionym tempie, to jest wiele
> możliwości zrobienia przejść. Film ma np. 25 albo 30 itp.
> klatek/sekundę, a materiał ma np. 1 kl/s albo mniej. Robi się np. tak,
> że właściwe zdjęcie jest przez połowę czasu (0,5 s - kilkanaście klatek
> filmu), następnie zdjęcie powoli zamienia się w następne (kolejne 0,5 s)
> itd.

No to wygląda jak morfowanie/blendowanie. Z takim czymś to sie często
borykam w nieco innej sytuacji gdy mam zrobiony film np. 24kl/s i chcę
to zamienić na 25kl/s.

> To dość podstawowa technika tak w ogóle, praktycznie zawsze robimy coś
> takiego, jeśli serię zdjęć chcemy zamienić w film. Chyba każdy program
> do nieliniowego montażu ma takich efektów na pęczki (chociaż te
> najprostsze mogą być tu najlepsze).

Nadal nie wykluczone, ze czegoś nie rozumiem, ale generalnie nie mam za
dużo doświadczenia z robieniem filmów poklatkowych z kilkudziesięciu
klatek. To co zwykle robię to dostosowuję częstotliwość robienia zdjęć
do planowanej dynamiki zmian (o ile się da) i długości filmu.
Przykładowo, chodzą mi w tej chwili 3 aparaty "pogodowe", które generuje
4-5tys zdjęć dziennie, każdy. To sie przekłada na te 3 min filmu,
25kl/s.

>> Normalny, średnio dynamiczny film poklatkowy poniżej 10kl/s to już się
>> wizualnie rwie.
>
> Google "telecine". Nie żebym dokładnie to tu proponował, ale zasada jest
> podobna.

I to sie robi takim zwykłym 2:2, 2:3 puldown i daje to zadowalające efekty?

>> No chyba, że róznice klatka-klatka sa praktycznie
>> żadne. Tu, robione z ręki, nawet ze stabilizacją, bedzie pewnie dużo
>> gorzej.
>
> Zakładam, że tych zdjęć jest mniej niż myślisz i że różnice między nimi
> są bardzo duże (zarówno w samej roślinie, jak i w warunkach ich
> wykonania, kątach itd). Dlatego zaproponowałem ujednolicenie sceny
> np. w GIMPie (bardzo łatwe przy takiej liczbie zdjęć, i efekty powinny
> być bardzo przyzwoite). Oczywiście moje założenia mogą być mylne, autor
> może wyjaśnić szczegóły.
>
> Stabilizacja nie ma tu żadnego zastosowania, poza eliminacją poruszeń.

No jeśli to jest morfowanie-blendowanie to ok, rozumiem.

--
Marcin

do góry

Użytkownik "Marcin Debowski" napisał w wiadomości grup
dyskusyjnych:zEMIC.157934$b...@f...ams1...
On 2018-05-09, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Marcin Debowski <a...@I...zoho.com> writes:
>>> To jak to sobie właściwie wyobrażasz i co to sa te płynne
>>> przejścia?
>
>> No normalnie, jak się robi animację w zwolnionym tempie, to jest
>> wiele
>> możliwości zrobienia przejść. Film ma np. 25 albo 30 itp.
>> klatek/sekundę, a materiał ma np. 1 kl/s albo mniej. Robi się np.
>> tak,
>> że właściwe zdjęcie jest przez połowę czasu (0,5 s - kilkanaście
>> klatek
>> filmu), następnie zdjęcie powoli zamienia się w następne (kolejne
>> 0,5 s)
>> itd.

>No to wygląda jak morfowanie/blendowanie. Z takim czymś to sie często
>borykam w nieco innej sytuacji gdy mam zrobiony film np. 24kl/s i
>chcę
>to zamienić na 25kl/s.

Hm, przy 24 - 25 kl/s to chyba nie ma co zmieniac, chyba ze bardzo
chcesz synchronizm utrzymac.

Za to jak u zrodla jest 1kl/s to faktycznie trzeba...

>Nadal nie wykluczone, ze czegoś nie rozumiem, ale generalnie nie mam
>za
>dużo doświadczenia z robieniem filmów poklatkowych z kilkudziesięciu
>klatek. To co zwykle robię to dostosowuję częstotliwość robienia
>zdjęć
>do planowanej dynamiki zmian (o ile się da) i długości filmu.
>Przykładowo, chodzą mi w tej chwili 3 aparaty "pogodowe", które
>generuje
>4-5tys zdjęć dziennie, każdy. To sie przekłada na te 3 min filmu,
>25kl/s.

No i to wystarczy pokazac klatka po klatce.
Jak jednak nie masz automatu, ktory robi zdjecie co sekunde, tylko
robisz raz dziennie, i chcesz z tego przynajmniej 30s filmu, to
trzeba..

J.

do góry

Marcin Debowski <a...@I...zoho.com> writes:

> No to wygląda jak morfowanie/blendowanie. Z takim czymś to sie często
> borykam w nieco innej sytuacji gdy mam zrobiony film np. 24kl/s i chcę
> to zamienić na 25kl/s.

Nie spotkałem się z inną metodą robienia tego niż przez zwykłe
przyspieszenie odtwarzania i resampling audio (połączony ew. z korektą
(przesunięciem) widma dzwięku (pitch correction)).
W każdym razie tak się załatwia filmy kinowe, to właśnie dlatego
w wersji m.in. EU są krótsze (nie napiszę że PAL, bo z PAL to tam jest
głównie frame rate, ale potocznie tak się mówi - PAL i NTSC).

> Przykładowo, chodzą mi w tej chwili 3 aparaty "pogodowe", które generuje
> 4-5tys zdjęć dziennie, każdy. To sie przekłada na te 3 min filmu,
> 25kl/s.

No, tak oczywiście też można zrobić, ale rozumiem, że to nie jest obecny
przypadek, no i takie coś wymaga dużo więcej zachodu.

>> Google "telecine". Nie żebym dokładnie to tu proponował, ale zasada jest
>> podobna.
>
> I to sie robi takim zwykłym 2:2, 2:3 puldown i daje to zadowalające
> efekty?

To jest zwykła, standardowa procedura. Jasne że teoretycznie lepiej
robić zdjęcia (i montaż itd) 600 FPS progressive i wtedy niczego
podobnego nie potrzebowalibyśmy. Kiedyś może tak będzie (modulo ilość
światła w obiektywach).

Tzn. od momentu pojawienia się telewizorów LCD i plazmowych (a także
kineskopowych z podwajaniem itp. częstotliwości odchylania - "100 Hz")
dochodzi tu jeszcze problem taki, że obraz jest wyświetlany
progresywnie, więc cały ten przeplot to jest trochę zawracanie głowy.
Właściwie lepiej byłoby nie robić deinterlacingu w TV, tylko połączyć
telecine i deinterlacing w masteringu (czy co to tam jest - od czasów
DVD tak się często robi z filmami na płytach, chociaż bez dwukrotnego
zwiększenia frame rate). No ale inercja w przemyśle.

W gruncie rzeczy, o ile rozumiem przeniesienie interlacingu do kolorowej
TV (z B&W), o tyle nie powinno to mieć miejsca w jakiejkolwiek TV
cyfrowej. No i wygląda na to, że to w końcu całkiem umrze.

To tak na marginesie.
--
Krzysztof Hałasa

do góry

On 2018-05-10, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Marcin Debowski <a...@I...zoho.com> writes:
>
>> No to wygląda jak morfowanie/blendowanie. Z takim czymś to sie często
>> borykam w nieco innej sytuacji gdy mam zrobiony film np. 24kl/s i chcę
>> to zamienić na 25kl/s.
>
> Nie spotkałem się z inną metodą robienia tego niż przez zwykłe
> przyspieszenie odtwarzania i resampling audio (połączony ew. z korektą
> (przesunięciem) widma dzwięku (pitch correction)).
> W każdym razie tak się załatwia filmy kinowe, to właśnie dlatego
> w wersji m.in. EU są krótsze (nie napiszę że PAL, bo z PAL to tam jest
> głównie frame rate, ale potocznie tak się mówi - PAL i NTSC).

Problem wystepuje. Nie potrafię powiedziec czy przy powaznych
zastosowaniach komercyjnych, ale przy amatorskich jest dośc realny,
wystarczy, że ma się aparaty/kamery z różnych regionów (systemów).

Mam np. takiego Olympusa TG-2, który potrafi tylko 60/30fps. Pozostały
sprzet to w większości 50/25fps. I jak to teraz porządnie razem
zmontować bez utraty jakości? Tańsze programy po prostu pominą co którąś
klatkę. W scenach z płynnym, powolnym ruchem będzie to koszmar.

Ostatni raz sprawdzałem z 5 lat temu, ale było dostępne oprogramoanie
robiące takie rzeczy. Kosztowało sporo (kilkaset $ i w górę). Z bardziej
przystepnych, jedyny, który jakoś sobie (podobno) z tym radził, to
Applowski Compressor, dostepny wyłącznie na OSX a i z nim nie udało mi
się uzyskać aż tak zadawalających wyników.

--
Marcin

do góry

Marcin Debowski <a...@I...zoho.com> writes:

> Mam np. takiego Olympusa TG-2, który potrafi tylko 60/30fps. Pozostały
> sprzet to w większości 50/25fps. I jak to teraz porządnie razem
> zmontować bez utraty jakości? Tańsze programy po prostu pominą co którąś
> klatkę. W scenach z płynnym, powolnym ruchem będzie to koszmar.

Owszem, to jest problem i w gruncie rzeczy nie da się go naprawdę dobrze
rozwiązać.
Jakimś rozwiązaniem jest zmiana parametrów w locie, ale nie wszystkie
urządzenia / programy radzą sobie z tym. Gorzej, jeśli trzeba
wyprodukować coś w wersjach 25 i 30 FPS. Z drugiej strony, sprzęt
120 FPS (jakiś) jest dostępny od pewnego czasu, da się z tego ładnie
zrobić 25p (24p z lekkim rozciągnięciem i audio pitch correction) oraz
30p.

> Ostatni raz sprawdzałem z 5 lat temu, ale było dostępne oprogramoanie
> robiące takie rzeczy. Kosztowało sporo (kilkaset $ i w górę). Z bardziej
> przystepnych, jedyny, który jakoś sobie (podobno) z tym radził, to
> Applowski Compressor, dostepny wyłącznie na OSX a i z nim nie udało mi
> się uzyskać aż tak zadawalających wyników.

Zasadniczo cena nie gra tu wielkiej roli, bo to kwestia teoretyczna -
nie ma naprawdę dobrego algorytmu dla ogólnego zastosowania.
--
Krzysztof Hałasa

do góry

W dniu 2018-05-11 o 02:39, Marcin Debowski pisze:

> Mam np. takiego Olympusa TG-2, który potrafi tylko 60/30fps. Pozostały
> sprzet to w większości 50/25fps. I jak to teraz porządnie razem
> zmontować bez utraty jakości? Tańsze programy po prostu pominą co którąś
> klatkę. W scenach z płynnym, powolnym ruchem będzie to koszmar.
>
> Ostatni raz sprawdzałem z 5 lat temu, ale było dostępne oprogramoanie
> robiące takie rzeczy. Kosztowało sporo (kilkaset $ i w górę). Z bardziej
> przystepnych, jedyny, który jakoś sobie (podobno) z tym radził, to
> Applowski Compressor, dostepny wyłącznie na OSX a i z nim nie udało mi
> się uzyskać aż tak zadawalających wyników.

Do konwersji fps używałem AviSynth z różnymi pluginami. Przerabiałem
stare filmy z kamery PAL z 576i50 (576 linii, 50 obrazów na sekundę
z przeplotem - czyli każdy z 50 ma połowę linii) na 720p60 (720 linii,
w każdym obrazie wszystkie linie).

Przykłady wysłane na YT (trzeba upewnić się, że wyświetla w trybie 720p60):
https://youtu.be/AjYxHfMZJaU
https://youtu.be/tHiLMcznuR4

Konwersja jest staranna, tzn. najpierw usuwa się przeplot uzyskując 576p50,
potem interpoluje się 50 fps do 60 fps przez wykrywanie ruchu obiektów
i generowanie brakujących ramek (ruchome obiekty są na tych wygenerowanych
kadrach w pozycjach pośrednich), potem skaluje się do 720 linii (inaczej
YouTube zmniejszy obraz do 480 linii). Jest to czasochłonna operacja,
trwa nawet kilka razy dłużej niż przerabiany film.

P.

do góry

Piotrne <p...@p...onet.pl> writes:

> Konwersja jest staranna, tzn. najpierw usuwa się przeplot uzyskując 576p50,
> potem interpoluje się 50 fps do 60 fps przez wykrywanie ruchu obiektów
> i generowanie brakujących ramek (ruchome obiekty są na tych wygenerowanych
> kadrach w pozycjach pośrednich), potem skaluje się do 720 linii (inaczej
> YouTube zmniejszy obraz do 480 linii).

Można tak robić, ale wiąże się to ze stratą jakości (w porównaniu do
oryginalnego 704/720x576 50i). Artefakty są widoczne oczywiście przy
ruchu - powstają "cienie". Z tym, że może dla youtuba nie ma lepszej
możliwości, nie wiem. Akurat tu wyszło nieźle moim zdaniem.

W każdym razie generalnie lepiej zostawić materiał w formacie, w jakim
jest, i wszelkie operacje przeprowadzać dopiero podczas wyświetlania -
nie trzeba wtedy robić zmiany szybkości (obecny sprzęt potrafi zwykle
pracować z dowolną szybkością wyświetlania), potrzebny jest tylko
deinterlacing z podwojeniem FPS + (tylko jeden) upscaling.

> Jest to czasochłonna operacja,
> trwa nawet kilka razy dłużej niż przerabiany film.

To akurat jest bardzo bardzo szybko :-)
--
Krzysztof Hałasa

do góry

W dniu 2018-05-19 o 14:51, Krzysztof Halasa pisze:

> W każdym razie generalnie lepiej zostawić materiał w formacie, w jakim
> jest, i wszelkie operacje przeprowadzać dopiero podczas wyświetlania -
> nie trzeba wtedy robić zmiany szybkości (obecny sprzęt potrafi zwykle
> pracować z dowolną szybkością wyświetlania), potrzebny jest tylko
> deinterlacing z podwojeniem FPS + (tylko jeden) upscaling.

Oczywiście oryginalnego materiału nie niszczę. Do oglądania na telewizorze
nadaje się bardzo dobrze. Ale po wysłaniu takiego nagrania na YouTube
zauważalnie spada jakość: przeprowadzana jest bardzo prosta konwersja
na 30 fps przez powielanie niektórych ramek (czasem w dziwny, nierównomierny
sposób) i obraz jest pomniejszany do 480 linii. Jedyne rozwiązanie
to przerobienie filmu lepszymi metodami przed wysłaniem.

Przy poprawnej konwersji 50 fps -> 60 fps "cienie" nie powstają.
To nie jest nakładanie / przenikanie sąsiednich kadrów, tylko wykrywanie
ruchu obiektów i generowanie pośrednich obrazów przez wyznaczenie
pozycji obiektów w "międzyczasie". Wykorzystywane są m.in. te same
biblioteki, co przy stabilizacji drgań obrazu na podstawie analizy
jego treści. Przy prawidłowym wykrywaniu ruchu możliwe jest dowolne
zwiększanie fps.

Poniżej - skrypt dla AviSynth wykonujący konwersję PAL -> 720p60.
Znalazłem kiedyś tutaj:
http://forum.doom9.org/archive/index.php/t-138285.ht
ml
i uzupełniłem o ładowanie niezbędnych pluginów (których trzeba poszukać
samodzielnie):

# start
# oryginalny film: DV PAL 720x576 4:3 50fps z przeplotem (interlaced)
# docelowy: 720p60 (720 linii, 4:3, 60 fps bez przeplotu)
PluginPath = "c:\Programy\AviSynth\plugins\"
LoadPlugin(PluginPath+"nnedi3.dll")
LoadPlugin(PluginPath+"masktools2-25.dll")
LoadPlugin(PluginPath+"RemoveGrain.dll")
LoadPlugin(PluginPath+"gradfun2db.dll")
LoadPlugin(PluginPath+"AddGrainC.dll")
LoadPlugin(PluginPath+"SmoothDeinterlacer.dll")
LoadPlugin(PluginPath+"mt_masktools-26.dll")
LoadPlugin(PluginPath+"nnedi3.dll")
LoadPlugin(PluginPath+"mvtools2.dll")
LoadPlugin(PluginPath+"nnedi2.dll")
LoadPlugin(PluginPath+"dfttest.dll")
LoadPlugin(PluginPath+"VerticalCleanerSSE2.dll")
LoadPlugin(PluginPath+"nnedi.dll")
LoadPlugin(PluginPath+"FFT3DFilter.dll")
LoadPlugin(PluginPath+"TDeint.dll")
LoadPlugin(PluginPath+"EEDI2.dll")
LoadPlugin(PluginPath+"RepairSSE2.dll")
LoadPlugin(PluginPath+"RemoveGrainSSE2.dll")
LoadPlugin(PluginPath+"SSE2Tools.dll")
Import(PluginPath+"LimitedSharpenFaster.avsi")
Import(PluginPath+"GradFunkMirror.avsi")
Import(PluginPath+"QTGMC-3.32.avsi")
LoadPlugin(PluginPath+"svpflow1.dll")
LoadPlugin(PluginPath+"svpflow2.dll")
LoadPlugin(PluginPath+"mvtools2.dll")
Import(PluginPath+"TempGaussMC_beta2.avsi")
Import(PluginPath+"InterFrame2.avsi")
directshowsource("Naganie_PAL_z_kamery_DV.avi")
#AssumeTFF()
AssumeBFF()
ConvertToYV12()
QTGMC( Preset="Slow" )
USS(960,720)
#Addborders(160,0,160,0)
#USS(1280,720)
Cores=2
SetMemoryMax(512)
#SetMTMode(3,Cores)
InterFrame(Cores=Cores,NewNum=60000, NewDen=1000)
Subtitle("2001-01-01 11:41:33", 40,650,90,119,"Arial",40,$ffffff)
Subtitle("2001-01-01 11:41:34", 40,650,120,149,"Arial",40,$ffffff)
Subtitle("Nagrał Piotr Fabian", 40,650,180,210,"Arial",40,$ffffff)
###
### function Ultimate Super Sample : USS()
### by LaTo INV.
###
### Need : nnedi, limitedsharpenfaster, gradfunkmirror, addgrain
###
### USS(input, ox, oy, PP1, PP2, PP3)
### ox = destination width
### oy = destination height
### PP1 = "Limited Sharpen Faster" post-processing
### PP2 = "GradFun2DB" post-processing
### PP3 = "Add Grain" post-processing
###
### Default : USS(last, 1280, 720, 100, 1.2, 5)
###

function USS(clip input, int "ox", int "oy", int "PP1", float "PP2", int "PP3") {
ox = default(ox, 1280)
oy = default(oy, 720)
PP1 = default(PP1, 100)
PP2 = default(PP2, 1.2)
PP3 = default(PP3, 5)
ix = input.width
iy = input.height
scaleX = ceil(float(ox)/float(2 * ix))*2
scaleY = ceil(float(oy)/float(2 * iy))*2
scale = scaleX > scaleY ? scaleX : scaleY
upscale2 = scale > 1 ? input
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=1).turnle
ft()
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=0).turnri
ght()
\ : input
upscale4 = scale > 2 ? upscale2
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=1).turnle
ft()
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=0).turnri
ght()
\ : upscale2
upscale8 = scale > 4 ? upscale4
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=1).turnle
ft()
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=0).turnri
ght()
\ : upscale4
upscale16 = scale > 8 ? upscale8
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=1).turnle
ft()
\ .nnedi3(dh=true,Y=true,U=true,V=true,field=0).turnri
ght()
\ : upscale8
process = upscale16
\ .LimitedSharpenFaster(ss_x=1.0,ss_y=1.0,strength=PP1
)
\ .gradfunkmirror(PP2)
\ .addgrain(PP3,0,0)
output = process.spline36resize(ox,oy)
return output
}
###





P.

do góry

Piotrne <p...@p...onet.pl> writes:

> Oczywiście oryginalnego materiału nie niszczę.

Tego nie miałem zamiaru sugerować :-)

> Przy poprawnej konwersji 50 fps -> 60 fps "cienie" nie powstają.

Sprawdziłem na pierwszym linku który podałeś, przy szybkim ruchu muszą
powstawać i powstają. Przecież tych informacji tam nie ma i bardzo
często nie ma ich skąd wziąć (np. z innych klatek). Jeśli np. obiekt
obraca się w czasie ruchu, to co algorytm ma zrobić?

> Przy prawidłowym wykrywaniu ruchu możliwe jest dowolne
> zwiększanie fps.

W animacjach może. Zresztą co tu mówić o interpolacji, jeśli artefakty
pojawiają się nawet w deinterlacingu, i to w normalnej, komercyjnej
produkcji.

Przy zwiększaniu np. 25 lub 30 -> 60 FPS problem jest o tyle mały, że
materiał źródłowy jest względnie stacjonarny (25 FPS to wciąż jest dość
szybko). Człowiek praktycznie nie widzi krótkich artefaktów (trwających
np. 1/60 s). Nawet 24 FPS jest normalnie wystarczające.

Faktem jest, że taki film po konwersji wygląda ładniej niż gdyby
oryginalny film wyświetlać z 25 FPS (pseudo p, bez usunięcia przeplotu)
na wyświetlaczu 60p, ale nie można tego porównywać do nagrania z kamery
np. 720x576p60.
--
Krzysztof Hałasa

do góry

Fri, 18 May 2018 14:48:35 +0200, w <pdmi35$ui8$1@node2.news.atman.pl>, Piotrne
<p...@p...onet.pl> napisał(-a):

> Konwersja jest staranna, tzn. najpierw usuwa się przeplot uzyskując 576p50,
> potem interpoluje się 50 fps do 60 fps przez wykrywanie ruchu obiektów

Ale po co zmieniasz liczbę klatek? To dosyć fajny sposób, ale na zepsucie
ruchu.

do góry