SeidChr / AutoTagger

Proof of Concept for a Instagram Best-Tag-Finder
1 stars 1 forks source link

Crawler #2

Open DariosKrimsKrams opened 6 years ago

DariosKrimsKrams commented 6 years ago

Oder iwo Crawer online gehostet und so, dass man man ihn über einen Link anschmeißen kann, dem man dann sagt, nach welchem Hashtag er suchen soll und von dort aus ca. 1000 Einträge crawlen. Dann kann man den Crawler nach einem Hashtag suchen lassen anschmeißen, kurz bevor man das Tool nutzt und weiß, dass man ein Foto mit einem bestimmen Themengebiet hochladen wird. Sonst ist ja evtl nichts drin in der DB zu diesem Thema. (Alternative/Optimalscenario wäre, dass der Crawler die ganze Zeit laufen müsste und ganz Instagram crawlt, jedoch Crawler und Crarifai Kapazitäten hier nicht ausreichend)

SeidChr commented 6 years ago

Ich bin mir nicht ganz sicher was du da sagst, aber ich glaube ersteres ist bereits fertig. und wenn man die zahl einfach beliebig hoch setzt, letzteres auch. Clarifai hat in der Dev-Version 5000 Requests frei. Allerdings kann man sich auch mehrere Entwickler accounts machen.

SeidChr commented 6 years ago

ich habe heute eingebaut dass der crawler mit random hashtags startet. leider ist mir bei den ergebnissen aufgefallen, dass diese viel zu "jung" sind. soll heißen, dass zuerst nur ganz frisch hochgeladene bilder gefunden werden, bei denen sich die qualität kaum abschätzen lässt. das alter muss also auch noch gecrawlt werden, um die zu jungen bilder herauszufiltern

DariosKrimsKrams commented 6 years ago

Wegen den "jungen" bildern: macht es Sinn, statt random zu crawlen, sich die Top100 Influencer zu einem Tag/thema geben zu lassen und "nur" alle Fotos dieser Personen zu verarbeiten?

SeidChr commented 6 years ago

Habe das mit dem neuen crawler erschlagen. Jetzt werden nur noch die 6 erfolgreichsten Bilder des hashtags zurückgegeben (instagram zeigt die ja immer schön oben an) Dabei leider gemerkt, dass instagram bei diversen hashtags einen login braucht um sie anzusehen. aber das spielt auf die dauer keine rolle denk ich

DariosKrimsKrams commented 6 years ago

habe u.a. den Crawler gefactored und cleaner gemacht. habe gesehen, du @Vittel hattest mit "SpeedParser" da einige Neuerungen umgesetzt. Ist das stable? dann würde ich das in den normalen Crawler reinpacken? Oder willst du das machen?

Können wir bitte allgemein Branches nicht so lange rumliegen haben, sonst enden wir in unendlichen Merge-Conflicts

SeidChr commented 6 years ago

Der SpeedParser arbeitet doch etwas anders als der Parser selbst. Bitte merge da nichts zusammen was nicht zusammen gehört. Gibt eigentlich keinen Grund warum die nicht parallel existieren können (OCP). Ich werde das zu gegebener Zeit integrieren. Bei den Branches musst du dir nur regelmäßig den master stand in den Branch mergen, dann sollten die Konflikte sich in grenzen halten.

DariosKrimsKrams commented 6 years ago

Ich laufe gerade jedoch gerade vor das Problem, dass die gecrawlten Daten zu "jung" sind - also genau das, was du schon gelöst hast. Wie löse ich jetzt mein Problem deiner Meinung nach? ich hätte vorgeschlagen, mir anzuschauen, wie du mit SpeedParser das gelöst hast und in den refactored crawler mit einzubauen (why not?). Auch vor dem Hintergrund, dass ich gerne den Crawler um eine Fähigkeit ergänzen würde, FollowerCount zu crawlen (sowie mehrere Bilder eines Followers zu crawlen, um den Overhead zu reduzieren)

DariosKrimsKrams commented 6 years ago

was Branches angeht: Wie das vor allem bei Projektbeginn ist, ändern man ja viel. z.B. hast du den Crawler (v1) umbenannt und geändert und ich komplett refactored.. einer von uns beiden wird so zwangsläufig immer in merge-conflicts enden.. oder ich werde nie deine Änderungen / potentielle Verbesserungen am Crawler haben.. würde das gerne in Zukunft verhindern

DariosKrimsKrams commented 6 years ago

Habe gerade mal deinen crawlerV2 angeschaut. Du gehst garnicht mehr auf die Foto-Seiten, sondern crawlst die 9 Fotos von der Übersichtsseite, die 'top rated' sind, sehr clever. Ich war am überlegen, wie ich den FollowerCount bekomme. Das geniale: man könnte sich die User Seite raussuchen und macht dann dort das selbe wie bei der Übersichtsseite, nur dass es hier effizienter ist, was das fotos-requests-verhältnis angeht. Bei der User-Seite haben wir dutzende Einträge - die alle nicht 'jung' sind :)

SeidChr commented 6 years ago

Man sieht auf der nutzerseite nur die letzten x Bilder. Also die neusten. Alles weitere wird via ajax nach geladen und ist ein weiterer request Ein Bild sollte wenigstens 2 Tage alt sein, sonst ist es für uns nicht gut verwertbar

DariosKrimsKrams commented 6 years ago

x = 24 (Also sollte passen. Abzügl. den "zu jungen", hat man immer noch mehr so viele Bilder pro Requests als auf der Übersichtsseite (+ FollowerCount) Oder was siehst du, spricht dagegen?)

SeidChr commented 6 years ago

also ich sehe beim ersten pageload nur 12 bilder. und wir werden dann user-centric. soll heißen wir laufen gefahr die bilder bzw tags von bestimmten usern sehr hoch zu bewerten weil sie diese ständig benutzen und einen hohen Bekanntheitsgrad haben. der speedparser bzw. v2 hat sammelt sich ja nun schon nur von instagram selbst als erfolgreich gekennzeichnete bilder heraus. in meinen augen reicht das nach wie vor völlig. Allerdings sollten wir, bevor wir das weiter diskutieren vielleicht mal ein paar Rechnungen anstellen in wie weit der Bekanntheitsgrad wirklich Einfluss auf die Bewertung des tags hat. Wie gesagt, es ist ein deutlicher mehraufwand zu den schon ausgesuchten bildern noch alle nutzerdaten abzufragen.

SeidChr commented 6 years ago

Bitte bedenken, dass das System nicht perfekt sein muss. ein gewisser Fehler stellt kein bzw. nur ein sehr kleines Problem dar

DariosKrimsKrams commented 6 years ago

Das user-centric sehe ich nicht als Problem. Man crawl5 ja immer noch die best-tags Pages und alle Fotos wie bisher. Nur, dass wir NOCH MEHR Fotos kriegen (des weiteren rechne ich damit, dass weitere Fotos des selben users ins selbe Thema bzw Interessengebiet passen, daher nicht total unnötig sind - wobei ich dies nicht als Hauptargumente werten möchte, weil ne gewisse Toleranz an der Aussage ist).

Was Diskussion FollowerCount angeht, da sind wir wieder am Anfang. Vllt sollten wir das persönlich / vor-ort mal diskutieren? Ich sehe den FollowerCount unabdingbar, weil eine noch genauere Auswertung verspricht :)

Stimmt, es muss nicht Perfekt sein, aber das wird es sowieso nicht, weil uns die Datenmenge fehlt, Ungenauigkeiten in der Bildanalyse sowie unser "Algorithmus" zu simple ist (Stichwort deep Learning)

DariosKrimsKrams commented 6 years ago

weiterer Vorteil vom Userpage crawling: wir haben Zugriff auf ältere/beliebtere Fotos. per explore/tags Seite sind selbst die "top-rated" nur paar Std. alt (haben meistens so um die 300 - 500 likes)

(x=12, hast recht. pro ajax request weitere 12)