sorry, das hab ich vergessen zu erwähnen:sgywalka is back hat geschrieben:Auf welchem MOni hast Du / dein Kollege des angegeuckt?
Mir dämmert da was, is es ein I-mac oder Arbeitsmoni--- ungefähr? Grüße..
in welchen format bzw. welcher unterabtastung hast du rausgerendert?Tscheckoff hat geschrieben: Hatte ich auch schon mit 4:2:2 10 Bit DNxHD Material.
Aber in der Ausgabe war es nicht mehr zu sehen.
(Also nur im Rendering innerhalb der GUI.)
Ich vermute mal stark, dass du versuchst, reale Positionen aus einer schematischen Darstellung zu interpretieren. Witziger Gedanke ;)rudi hat geschrieben:Dort sieht man in der Mitte des Artikels schön dargestellt, dass die Abtastpositionen des Choma-Signals je nach Unterabtastung an verschiedenen Orten stattfinden kann. (An oder auch zwischen den Y-Pixeln).
Das würde ich ja, aber brauche dafür Material :(motiongroup hat geschrieben:Versucht das mal unter OS X zu testen ..
Mein Glaube ist unerschütterlich, was schert mich da die Praxis? ;)dienstag_01 hat geschrieben:Ich vermute mal stark, dass du versuchst, reale Positionen aus einer schematischen Darstellung zu interpretieren. Witziger Gedanke ;)rudi hat geschrieben:Dort sieht man in der Mitte des Artikels schön dargestellt, dass die Abtastpositionen des Choma-Signals je nach Unterabtastung an verschiedenen Orten stattfinden kann. (An oder auch zwischen den Y-Pixeln).
domain hat geschrieben:Bei maximaler Kontrastaufsteilung sieht das dann so aus:
ich würde es eher mit einer sehr hohen anhebung der farbsättigung herausheben:
ich glaube, das zeigt sich nur in dem dürftigen 8bit png screenshot, den ich hier zu illustrationszwecken benutzt habe. in wahheit liegen die störungen all in der grün-mangenta achse.domain hat geschrieben:Interessant, dass neben Grün und Magenta auch noch ein Blau- und Gelbanteil sichtbar wird.
nur nocheinmal als versuch einer klarstellung, was dieses bild eigentlich aussagt:
es ist einfacher grauverlauf, sondern ein geflecht von linien die jeweils in horizonaler und vertikaler richtung ihre helligkeit von 0 bis 1023 ändern -- hier ein auschnitt:
auf diese weise kann man über die platzierung der entsprechenden verfärbungen ganz genau sagen, bei welchen benachbarten grauwert-kombinationen sich der fehler zeigt.
es ist eine störung die über die ganze diagonale läuft -- d.h. man findet sie über den ganze helligkeitsbereich.
der fehler zeigt sich nur, wenn beide pixel relativ ähnliche [grau-]werte aufweisen. wobei allerdings ein erstaunlich großer bereich betroffen ist.
das wäre natürlich zu wünschen. wirklich sicher wäre ich mir allerdings nicht. mir sind mind. 3 ähnlich gravierende probleme (betreffend bspw. die framegenaue verarbeitung) bekannt, die von benutzern seit jahren bemängelt und in ihren auswirkungen immer wieder klar beschrieben wurden, aber trotzdem bisher nie gefixt wurden.domain hat geschrieben:Wird bestimmt in kürzester Zeit einen Patch von BMD geben.
die tatsache, dass BMD auf solche hinweise gar nicht eingeht, sondern wir uns vielmehr schon daran geöhnt haben, dass es gewissermaßen als bestätigung für einen reproduzierbaren bug aufzufassen ist, wenn keine antwort, die sofort mit einem benutzerseitigen fehler kontert, zu vernehmen ist.
wenn man einmal erlebt hat, wie das in anderen projekten gehandhabt wird -- ich denke da beispiel an natron, wo gravierende bugs oft in stunden, spätestens aber innerhalb von ein paar tagen gefixt werden, oder aber auch an "nuke", wo zumindest wirklich gut nachvollziehbare fehlertickets existieren und bei jeder neuen release ganz genau aufgelistet wird, welche probleme behoben wurden, aber auch, welche mängel noch offen sind -- wirkt es ziemlich enttäuschend, wie das von BMD gehandhabt wird.
prinzipiell würde ich behaupten, das jede software fehler und verbesserungspotential enthält. das ist nicht wirklich das problem. entscheident ist die art und weise, wie man diesem problem konstruktiv begegnet!
da hast schon recht! ich will es auch nicht überstrapazieren -- wobei ich schon glaube, dass auch kommerzielle unternehmen sich manches von den gepflogheiten in der freien welt abschauen könnten, damit die qualität jener porodukte, auf die wir in unserer täglichen arbeit angewiesen sind, besser wird.CameraRick hat geschrieben:Weiß nicht ob ich Open Source Projekte so sehr da mit rein nehmen würde, das sind ja ganz andere Strukturen. Bei BMD wird nach Feierabend niemand mehr daheim sitzen und was am Code ändern können.
ja -- wirklich schnell und zielgerichtet entwickeln sie leider offenbar gegenwärtig nicht, trotzdem ist ein tolles programm, auf das man sich in den meisten fällen wirklich verlassen kann. mir erscheint es deutlich transparenter und sauberer konzipiert als resolve oder fusion.CameraRick hat geschrieben:The Foundry läuft auch immer ein wenig als Negativbeispiel, habe erst vor kurzem einen Script-Breaking Bug reported, da hat man mich direkt angeschrieben dass es ein Known Bug ist, und mir den Link geschickt. Der wurde 2010 gemeldet...
wie gesagt, ich galube, dass es ganz unabhängig vom verwendeten codec in allen fällen, wo 4:2:2 subsampling genutz wird, aufzutreten scheint...CameraRick hat geschrieben:Ich will mal versuchen wie das mit verschiedenen Codecs usw aussieht, mit einer einheitlichen RAW Quelle die ich auch posten kann. Mal schauen wie sich das alles so verhält.
Klar, der "Schrott" ist gut genug, für einen guten Teil aller Hollywood Blockbuster, aber wir hier haben natürlich viel höhere Ansprüche.motiongroup hat geschrieben:Conclusio... Schrott
Auch wenn eine Software für High End benutzt und gemocht wird, darf man sich wohl pikieren wenn sie offensichtlich nicht ordnungsgemäß funktioniert :)Klar, der "Schrott" ist gut genug, für einen guten Teil aller Hollywood Blockbuster, aber wir hier haben natürlich viel höhere Ansprüche.
ich fürchte, dass er das tiff file und nicht den 4:2:2-clip verwendet hat.CameraRick hat geschrieben:Vielleicht können wir das Problem auf irgendwas eingrenzen. Bei Frank tritt es nicht auf.
genau diese hollywood phrasen, kann ich wirklich nimmer hören! :(Auch wenn eine Software für High End benutzt und gemocht wird, darf man sich wohl pikieren wenn sie offensichtlich nicht ordnungsgemäß funktioniert :)Klar, der "Schrott" ist gut genug, für einen guten Teil aller Hollywood Blockbuster, aber wir hier haben natürlich viel höhere Ansprüche.
"prima!" ist wohl in dem fall als antwort nicht wirklich angebracht. ;)Frank Glencairn hat geschrieben:Okay hab jetzt den clip probiert und seh es jetzt auch.
das ist nicht völlig auszuschließen...Frank Glencairn hat geschrieben:Ist womöglich ein QT Problem.
kannst mir zufälligerweise sagen, welche avi 'uncompressed' 4:2:2 variante resolve unterstützt, damit ich das ohne langes suchen durchprobieren kann?Frank Glencairn hat geschrieben:AVI > unkomprimiert > 4:2:2 > alles gut
Ist das bei den anderen Herstellern besser? Ich fand gerade das bei BM die Entwickler relativ gesehen zu den anderen Herstellern sehr präsent sind im eigenen Forum..leider ist ja BMD im umgang mit bugreports und der entsprechenden korrektur alles andere als vorbildlich. gerade, wenn es keine rückmeldung seitens der verantwortlichen auf entsprechende berichte und hinweise im benutzerforum gibt, kann man fast immer davon ausgehen, dass sie das problem ohnehin selbst reproduzieren können, aber es lieber einfach unter den tisch zu kehren versuchen. das ist leider auch insofern problematisch, weil auf diese weise ganz gravierende mängel (bspw. frame accuracy) oft über jahre hinweg nicht behoben werden.
das kann ich leider nicht bestätigen.Frank Glencairn hat geschrieben:Ist womöglich ein QT Problem.
...
AVI > unkomprimiert > 4:2:2 > alles gut
QT > unkomprimiert > 4:2:2 > Bunte Muster
auch in einem 8bit 4:2:2 h264 intra mit sehr hoher qualität (-qp 1) in einem mp4-container tritt es offenbar tatsächlich nicht zu tage! übrigens auch nicht, wenn man es in einen quicktime container packt.CameraRick hat geschrieben:Ich bin mal Franks Beispiel gefolgt, und habe das File in AVC-Intra Class100 und XAVC Class200 gewandelt. Presets aus dem AME.
Die haben, MediaInfo nach, beide 10bit 422. Aber keine bunten Streifen!
ob und in welcher weise BMD reagieren wird, erwarten wir natürlich alle sehr gespannt...motiongroup hat geschrieben:Wichtig ist das ihr schon einen Workaround gefunden habt und BM wird dem sicher auf den Grund gehen und den Fehler beheben..
wie oben schon erklärt, gibt es definitiv beispiele, wo das unvergleichlich besser funktioniert...motiongroup hat geschrieben:Ist das bei den anderen Herstellern besser?