Seite 9 von 9

Verfasst: 22.08.2006 17:04
von ts-soft
Alves hat geschrieben:Könntest du das mal für die 3.94er mal kompilieren?
Du kannst doch Updaten, kostet doch nichts. Hab auch beide Versionen am laufen.

Verfasst: 22.08.2006 17:16
von inc.
Lade bei einem RGB Bild die Werte direkt in ein Array, denn Point ist irre langsam (unabhängig ob du später einnen Buffer nehmen wilst):
http://www.purebasic.fr/german/viewtopic.php?t=9458

Die meisten Videoformate kommen nicht in uncompressed rgb32 oder rgb24 daher. Dies sind zu 90% oft die reinen Anzeigeformate.
Professionell wird oft auf YUV 4:4:4 geschnitten, bedeutet ebenso 24bit 8y8u8v aber eben kein rgb (y=luma,u/v=chroma).

Die schnellste Art Filmbearbeitung zu vollziehen ist via YV12, diesen Farbraum nutzt auch DV PAL, sowie alle Consumer mpeg Varianten (mpeg@mainProfile), DVD, Divx, Xvid etc.
Dieser hat sodann 12Bit, aber immer noch die 16,x Mio Farben.
Die Reduktion auf 12Bit wird hier via der Farbauflösung erreicht.
Also Volle Helligkeitsauflöung, aber jeweils nur die viertel Farbauflösung.

Zudem ist RGB "interleaved", genauso wie YUY2, d.h. die Punkt-Farbwerte folgen hintereinander.
YV12 ist nicht "interleaved" sondern "planar", bedeutet: Erst die Y-Luma Daten (Ebene) im Speicher gefolgt von U und dann die V Ebene.


Warum erzähle ich dir das?
Ganz einfach ... fange bereits jetzt an dich auf YV12, also planar aligned einzustellen, denn 99% aller Sourcen kommen als YV12 (DV, DVD etc).
Wenn du deine Errungenschaften in diesem Videosektor dann mal richtig einsetzen willst, wirst du sodann fast alles in RGB wandeln müssen, was Qualitätsverlust (auf Farbgenauigkeitsebene) bedeutet.
Zudem ist YV12 Bearbeitung bis zu 40% schneller (s.o.) und wenn du im Netz suchts, wirst du VirtualDub finden, denn dieses Programm hatte ebenso alles in RGB32 bearbeitet wovon die Videobearbeiter vollkommen abgekommen sind und nun Avisynth nutzen, welches nativ YV12 Daten bearbeiten kann

Danke für den Tipp

Verfasst: 22.08.2006 23:04
von Xaby
Meine Idee war ja, mir ist egal, wie das Video komprimiert ist.

Am Ende macht das ja der CODEC, der mir mein RGB-Bild wieder geben sollte. Denn irgendwie muss das ja auch angezeigt werden können.

What you See, is what you get. (oder so ähnlich)

Jaja, die Sachte mit den Buffern und dem Array, ist auch klar.

Nur, wenn ich gleich anfange hier Schnörkel und Hyýroglyphen zu posten, wird sicherlich der ein oder andere nicht mehr den Code verstehen.

Siehe zwei Posts drüber (Konvertierung, statt Kompeilierung ...)

Ich will nicht das fertige Endprodukt hier reinstellen, sondern lediglich einen nachvollziehbaren Denkansatz.

Kannst ja gern auch mal deinen Code zeigen mit anderer Farbcodierung.

Auch mit Schnelligkeitsoptimierung. ...

Mir war auch wichtig, dass es für Bilder und Videos gleicher maßen funktioniert. ...

[[ Da ich aus der Fotobranche stamme ...
Muss ich dir sagen, dass mir mein Auge teilweise weh tut, wenn ich JPEGs mit komprimiertem Farbraum sehe. ...
Für mich ist Farbechtheit wichtig. Und wenn man dort die Kompression von Echtfarben auf 4:2:2 oder 4:1:1 stellt ... ist das Ergebnis zwar ähnlich und für das menschliche Auge genauso angenehm, aber es sind nicht mehr die selben Farben.
Videotechnisch hast du, zu mindest wie du sagst im Consumerbereich, Recht und genau für diese Zwecke ist es ja auch konzepiert ...
Denn für den Rest gibt es Maschinen für hundert tausende Euro, die demn menschlichen Auge nachempfunden sind und schauen, wie gut ein neuer Codec wirklich ist.
]]


Freue mich über deine (finale >:) ) Version.

Gruß, Folker :allright:

Habt ihr schon mal ...

Verfasst: 22.08.2006 23:53
von Xaby
JPEGs gemacht?

Wenn man nur die Dimensionen des Bildes ändert, dürfte sich theoretisch das Histogramm nicht ändern. (wenn es dem entsprechend skaliert ist wie in meinem Programm)

Wenn die JPEG-Kompression jedoch stärker wird (Qualitätsverlust ...)

Kann man das deutlich im Vergleich zum Original sehen.

... ich hoffe, mit dieser Bemerkung konnte ich euch anstacheln, es mal selbst zu versuchen.

Vielleicht finden wir gemeinsam ja eine gute, schnelle Lösung, um Qualität von Schund unterscheiden zu können.

Gruß, Folker :allright:

Verfasst: 23.08.2006 11:51
von inc.
Xaby hat geschrieben:Freue mich über deine (finale >:) ) Version.
? Was für eine finale Version? Ich will dir 'Hints' geben und keine eigene Sache promoten.

Aber es gibt jede Menge 'finale versionen', welche dir einen wunderbaren Ansatz zu deinen Konzepten bieten: -> Source Codes von Plugins für Avisynth und davon gibts ne Menge: http://www.avisynth.org/warpenterprises/

Dein Thread-Titel bezieht sich auf 'Video'analyse, oder? Und die meisten Videos sind eben von ihrer Source her in YV12 oder YUY2.

Der RGB Farbraum is der ANZEIGE-Farbraum, der BEARBEITUNGSfarbraum sollte der native Farbraum bleiben, bzw. in der selben Farbraum-Familie bleiben (meist YUV). Denn ansonsten gibts einen Verlust der Farbakurranz.
Die meisten Codecs können neben RGB auch in den "belassenen" nativen uncompressed YV12 dekodieren.
Zumal liegen beinahe alle YUV Videos in einem ITU/CCIR Wertebereich. D.h. 16-234, also tiefste Tiefen in min 16 und hellste Lichter in max 234. Wenn nun in den Anzeigefarbraum RGB gewandelt wird, wird der Wertebereich gestreckt. Eben auf die Monitor RGB 0-255.
http://www.fourcc.org/fccyvrgb.php

Gehst du nun hin und forcierst vorab eine Dekodierung hin zu RGB, um diese "technisch" verfälschten Werte sodann in ihren Werten zu bearbeiten um sie dann wieder auf Video/TV konforme YUV zu bringen, hast du signifikante Verfälschungen, die dem deiner Erfahrung mit jenen schlechten jpeg Bildern entsprechen könnten ;)

Referenz: http://www.fourcc.org/ <- sehr interessant für dein Vorhaben

Zumal hast du bei z.B. einer Mask-Detection in YV12 die Y-U-V Kanäle wunderbar hintereinander (planar) und nicht interleaved angeordnet.

Was mjpeg angeht, da kommts auf den codec an, der in YUV wandelt. Eine MiroDC30+ welche via onBoard Hardware-mjpeg-codec Betacam Qualität bietet WENN die Datenrate bei ca. 6,5MB/sek liegt wurde bis vor ein paar Jahren sogar hier beim WDR in gewissen Bereichen zum digitalisieren genutzt.

Wikilink

Verfasst: 25.08.2006 08:46
von Xaby
Zum Thema Farben und Farbkreis

http://de.wikipedia.org/wiki/Farbkreis

Bild

Bild

Bild

... bin mal gespannt, was wir draus machen :roll:

Gruß, Folker :allright:

Verfasst: 28.08.2006 12:48
von Xaby
@ inc. oder wer anders

Sage mal, kannst du mir vielleicht einen Ansatz geben in PureBasic, wie ich das Bild, was ich beim Abspielen eines Videos sehe ... in ein Array bekomme?

Und das möglichst schnell. ... (also im Programm /:-> )

Das wäre nett von dir.

Danke, Gruß, Folker :allright:

Hier ist einer

Verfasst: 12.10.2006 18:15
von Xaby
Kennt jemand PlugIns für PhotoShop?


Bin auf GrowCut gestoßen.
http://graphics.cs.msu.su/en/research/S ... index.html

Mag jemand vielleicht was dazu sagen?

Schaut euch ruhig mal die Beispiele an, vielleicht inspiriert es euch ja und ihr habt einen Geistesblitz.
Oder weiß jemand, wie man PhotoShop-PlugIns weiter nutzen kann?

Dann bräuchte man ja eigentlich nur noch eine Methode finden, wie das Programm selbst die roten und blauen Linien setzt.

Schreibt ruhig auch mal wieder was hier rein. Ist ja sonst etwas langweilig, so ganz allein im Forum /:-> :allright:

Verfasst: 21.05.2007 10:46
von Xaby
Und wieder gehen wir einen Schritt weiter:

http://members.aol.com/leonheinz/lautbi ... chrift.htm

Die Lautschrift:

Bild

Einige Beispiele:
Bild

In Verbindung mit einem TextParser, der vielleicht auch auf dem Code aus dem CodeArchiv:
PhoneticTextSearch.pb

basiert, einem klitzekleinen Pivot-Zeichen-Programm und man hat ein schönes Spielzeug. Klar, wird man um eine Datenbank nicht herum kommen, aber wenn sie sich durch den Umgang mit einem Kind oder einem anderen Menschen selbst erweitert, eventuell die Daten per Netz auch noch verbreitet und ergänzt, wäre eine gute Maschine-Mensch Komunikation möglich.

eine ZwischenSprache, die auf Bildern basiert, benötigt nicht unbedingt Wörterbücher, sondern nur Vektoren (SVG z.B.)

Ein Japaner könnte genauso ein Bild malen wie ein Deutscher.
Ohne dass beide Englisch können müssen.
Man könnte die Lautsprache als Zwischensprache einführen, um auch Fehler zu verhindern.

Google schafft es nicht mal seinen eigenen Text, von Deutsch nach Englisch, von Englisch wieder zurück genauso aussehen zu lassen wie die ursprüngliche Eingabe war. Wenn man zwischendurch noch Französisch oder Spanisch nimmt, versteht man den Deutschen Text am Ende auch nicht mehr.

Wenn man also wie bei der Primzahlfaktor-Zerlegung die Sprache runterbrechen kann auf einige wenige Begriffe, reichen vielleicht 1.000 Worte, um daraus alle anderen Worte herzuleiten oder zu generieren.

Genauso wie ein Schrank aus Schubfächern besteht, die ebenfalls aus Holz oder Plastik besteht. Dieses Holz widerum stammt von einem Baum.

Damit besteht ein Schrank aus Baum. Ein Schrank ist also fast wein Baum.

So ist ein Computer, ein Auto, ein Telefon ... eine Art Maschine.

Kennt ihr diese Freundes-Freunde-Verknüpfungen, die jetzt modern geworden sind?

:: Paul hat einen Freund, der ist mit Meike befreundet, Meike kennt Hans.
Hans ist mein Freund. Also kenne ich auch Paul.

Irgendwie so. Ich glaube, die Lokalisten oder so, sind sowas.

http://de.wikipedia.org/wiki/Freundschaft
http://de.wikipedia.org/wiki/Lokalisten

Wenn man also jeden Gegenstand oder jedes Wort als Lokalisten in seiner eigenen Datenbank anmelden würde, könnte man damit Assoziationen schaffen.

Genauso wichtig ist es, Fehler zu machen. So sollte man immer den Weg gehen, dass Text über ein Schrifterkennungsprogramm erkannt werden muss. Denn sobald man dabei etwas anderes liest, als da steht, besteht die Möglichkeit, dass man an etwas anderes denkt und damit die Sache in einem anderen Zusammenhang sehen kann.

Etwas traurig finde ich, dass nicht all zu viel Feedback kommt.

Allein werde ich es nicht schaffen. Dazu kenne ich mich mit Datenbanken zu wenig aus.

Kennt ihr schon, ich weiß
http://www.ezprezzo.com/videoclips/whit ... uture.html
:?

Verfasst: 02.06.2007 03:09
von Xaby