Ślepa pizda i kierownik co miał wyjebane

Nie spać, zwiedzać!

Miała nie tylko telefon, ale także selfie stick... zamierzała robić rzeczy na tiktoku... zasługuje na to

sadistic.pl/baba-na-drodze-vt589965.htm

Trzeba naprawić tę wyszukiwarkę! Za co ja tu kurwa płacę?

Trzeba naprawić tę wyszukiwarkę! Za co ja tu kurwa płacę?

Wyszukiwanie po tagach gówno daje.

Może by tak dać jakieś porównywanie obrazów? Typu perceptual hash?

Tak na przykład: bierzemy mały zestaw pikseli z każdej klatki, powiedzmy 8x8 (czyli dla poziomej rozdzielczości 1920 bierzemy na przykład piksel 120, 360, 600, 840, 1080, 1320, 1660, 1800 (celowo nie biorę pikseli skrajnych tylko środek każdego pola)), każdy z nich obcinamy do jednej z 256 wartości. W ten sposób nawet jeśli filmy były kilkakrotnie kompresowane z jakością HujHD, jest bardzo duża szansa że hash będzie taki sam (możliwe że artefakt kompresji akurat przekroczy granicę jednego z 256 kolorów, no ale cóż). To zredukuje nam każdą klatkę do 64 bajtów.

Dubel będzie miał przynajmniej 10-20 sekund wspólnych: filmy są różnie pocięte/posklejane ale z dużych wspólnych fragmentów. Czyli szukamy 250-500 takich samych hashy pod rząd. Problemem jest że nie wiemy z jakim przesunięciem wspólny fragment się zaczyna, ale chyba na to jakieś algorytmy też są.

Ja się na tym nie znam: ostatni raz grafiką bawiłam się w Turbo Pascalu kiedy większość ludzi tutaj srała w pieluchy. Ale są ludzie którzy się na tym znają. Może by ruszyć ten temat?

Wyszukiwanie po tagach gówno daje.
Może by tak dać jakieś porównywanie obrazów? Typu perceptual hash?
Tak na przykład: bierzemy mały zestaw pikseli z każdej klatki, powiedzmy 8x8 (czyli dla poziomej rozdzielczości 1920 bierzemy na przykład piksel 120, 360, 600, 840, 1080, 1320, 1660, 1800 (celowo nie biorę pikseli skrajnych tylko środek każdego pola)), każdy z nich obcinamy do jednej z 256 wartości. W ten sposób nawet jeśli filmy były kilkakrotnie kompresowane z jakością HujHD, jest bardzo duża szansa że hash będzie taki sam (możliwe że artefakt kompresji akurat przekroczy granicę jednego z 256 kolorów, no ale cóż). To zredukuje nam każdą klatkę do 64 bajtów.
Dubel będzie miał przynajmniej 10-20 sekund wspólnych: filmy są różnie pocięte/posklejane ale z dużych wspólnych fragmentów. Czyli szukamy 250-500 takich samych hashy pod rząd. Problemem jest że nie wiemy z jakim przesunięciem wspólny fragment się zaczyna, ale chyba na to jakieś algorytmy też są.
Ja się na tym nie znam: ostatni raz grafiką bawiłam się w Turbo Pascalu kiedy większość ludzi tutaj srała w pieluchy. Ale są ludzie którzy się na tym znają. Może by ruszyć ten temat?

Dobrze kombinujesz, tylko zamiast hashy liczy się raczej odległości w przestrzeni n-wymiarowej różnic między cechami. Im mniejsza odległość tym cechy bardziej zbliżone. Tyle, że to byłoby jednak spore zadanie a obecnie są chyba prostsze sposoby. Można pobrać gotowy model AI, który jest w stanie słownie opisać co widzi na obrazie.
A tak poza tym, to moja uwaga dotyczyła tego, że obecnie wyszukiwarka, która przedtem działała przestała działać i nie potrafi wyszukiwać więcej niż jednego słowa.

Ale liczyć odległości można tylko 1 do 1, czyli trzeba by porównywać każdą parę. A filmów jest ponad 4TB, za dużo. Zaś hashe można szukać jako stringi.

Za długie te twoje hashe. 64 bajtów na klatkę przy 5-minutowym filmie zajmie pół mega.

> Ale liczyć odległości można tylko 1 do 1, czyli trzeba by porównywać każdą parę.

Nie, są drzewa na których mozesz to wyszukać w O(n*log n), korzystają z nierówności trójkąta. Dobrze nadają się do np. wyszukiwania obrazów. Nie widzę jednak jak można by tego użyć do porównywania filmów. ze względu że wymiarów robi się zbyt dużo. Musiałbym pomyśleć, jednak na pierwszy rzut oka twój pomysł z kwantyzacją i hashem brzmi lepiej.

Nie można porównywać pojedyńczych klatek bo za dużo będzie false positivów, takich jak logo Crazyshit.

> 250-500

Pciółka, jak ty możesz używać takich przypadkowych liczb! Zaokrąglij to do 256-512! :þ

> Dubel będzie miał przynajmniej 10-20 sekund wspólnych: filmy są różnie pocięte/posklejane ale z dużych wspólnych fragmentów. Czyli szukamy 250-500 takich samych hashy pod rząd. Problemem jest że nie wiemy z jakim przesunięciem wspólny fragment się zaczyna, ale chyba na to jakieś algorytmy też są.

Ja bym to zrobił tak: dla każdej klatki, liczysz hash ciągu 0..255 klatek następujących po niej. To się da szybko policzyć bo nie trzeba hashować całego ciągu, tylko pierwszą i ostatnią wartość, poczytaj o "rolling hash". Uzyskane hashe sortujesz i dla każdego przedziału długości kilku sekund zapisujesz w bazie tylko ten pierwszy. Żeby nie było kolizji, te hashe powinny mieć przynajmniej 12-16 bajtów długości. Kilka bitów można zaoszczędzić jeśli rolling hash jest dłuższy niż to co zapisujesz w bazie, a kluczem sortowania jest właśnie ta odrzucona część.

Dla 5-minutowego filmu zjechaliśmy do 480 bajtów.

Doliczając metadane, weźmy 4-bajtowy numer filmu. Tak więc, nasza struktura będzie 16-bajtowy klucz -> 4-bajtowa wartość, lub jeśli wolisz krócej, 12-bajtowy klucz -> 4-bajtowa wartość. Taką bazę można łatwo trzymać w pamięci.
Koszt czasowy: dla 5-minut filmu 30 odwołań do bazy. Hashe mają najgorszą możliwą lokalność ale jeśli baza siedzi w pamięci lub na nie-kręconym dysku, nawet tysiące wyszukań na sekundę nie stanowią problemu.

O tej godzinie nie myśli mi się najlepiej, powiedz czy nie widzisz w tym co piszę jakiejś bzdury.

> Tyle, że to byłoby jednak spore zadanie a obecnie są chyba prostsze sposoby. Można pobrać gotowy model AI, który jest w stanie słownie opisać co widzi na obrazie.

Eh, AI to taki nowy blockchain. Nie widzę jak można by sensownie użyć gotowych modeli. Można by wymyśleć nowy, ale to duża sprawa, dużo większa niż rozwiązanie które zajęło mi 15 minut myślenia i da się zaklepać w kilka godzin, i powinno działać szybko: praktycznie cały koszt czasowy to dekodowanie filmu.

@Up
Idea stojąca za algorytmem hashujacym to dokładne zaprzeczenie potrzebie szukania podobieństw w zbiorach danych, bo budowany jest on tak aby skróty maksymalnie się od siebie różniły nawet przy najmniejszych zmianach w danych wejściowych. Jak już się upieracie to lepiej liczyć prostą sumę kontrolną, która nie jest optymalizowana w kierunku maksymalizowania entropii.

Nie, AI to nie jest nowy blockchain. To jest największa rewolucja w dziejach ludzkości i zrozumiesz to już za kilka lat, bo tempo publikacji prac w tej dziedzinie narasta wykładniczo. Już samo to, że eksperci wieszczą pojawienie się AGI w najbliższych latach pokazuje co się dzieje. Jesteśmy u progu Kurzweilowskiej osobliwości technologicznej i cieszy mnie, że prawdopodobnie dożyję tej chwili.

Tymczasem na potrzeby tego zagadnienia wystarczyłby choćby ten model: llava-vl.github.io/
Ten akurat znam, nie szukałem czy są gotowe modele video-to-text, ale zastosowanie image-to-text nie jest jakimś wielkim wyzwaniem w kontekście inteligentnej wyszukiwarki. Do automatycznego wyszukiwania dubli potrzeba by więcej roboty, ale nie jest to niezbędne.

Aha, i zwracam uwagę, że słowny opis filmu wystarczy wygenerować raz po jego wgraniu, więc taki model pracował by tylko wtedy.

Ale liczyć odległości można tylko 1 do 1, czyli trzeba by porównywać każdą parę. A filmów jest ponad 4TB, za dużo. Zaś hashe można szukać jako stringi.

R-Tree, zresztą to nie wiem, ale wiem, że takie metody stosuje się w dużych systemach np sprzedażowych do wyszukiwania podobnych ofert m.in po zdjęciach.