REPTILE

ja gute frage... man breuchte dazu zwei mal das gleiche testbild einmal in XYZ und einmal in RGB..... dann könnte man das RGB in XYZ (bzw andersrum) konvertieren und mit dem echten RGB/XYZ vergleichen... anders sehe ich keine möglichkeit das zu überprüfen.....

Bin gerade dabei diese multi Standbild funktion einzubauen, gleichzeitig baue ich noch eine überprüfung der bildauflösung ein.... dann kommt das multithreading auch für 2D film hinzu und man kann wählen zwichen 2 oder 4 Threads also dual bzw quad core CPUs.... und die neue imagamagick behandlung kommt rein, das die operationen direkt per dll/com+ aufruf ausgeführt wird statt der convert datei, das sollte das aktuelle problem lösen.... ach ja und der DPX und TIF support kommt mit rein.. kann also etwas dauern.. :D

ich bin mit dem blackberry unterwegs :) das hat sogar multitasking :D

ähä... mal abgesehen davon, was soll das bewirken? sinn ? da hätte doch nen bild von popcorn mehr sinn :)

mhh... wie carstenk schon sagte... das problem ist da nicht die technik sondern die benutzerschnittstelle... man kann ja kaum für jedes einzelbild ne eingabestelle für die datei und dann vieleicht auch noch die zeit reinbauen.. weil du sagst jetzt 5 bilder, der andere 7 stück etc... ABER... was ich mir gerade überlegt habe ist folgendes... man könnte es so machen das man wählen kann, einmal wie bisher, ein bild angeben und gut... ODER... man gibt ein verzeichniss an in dem dann bilder liegen mit folgenden dateinamen..... bild1-48.bmp bild2-190.bmp bild3-24.bmp soll heißen... bild1....3 bildreihenfolge in dem diese gezeigt werden sollen, und bildx-4 soll bedeuten, das bild für 4 frames anzeigen.. also die zahl nach dem "-" sagt die anzahl an frames die das bild gezeigt werden soll.. wäre das OK ?

der da :) http://www.youtube.com/watch?v=pbxrITEtX5U is geil.. und ja der lief im kino :)

also nicht 2x avatar in ein verzeichnis :D

300.000 frames wären aber schon über 3 stunden... :)

mhh das ist eigendlich ne gute idee :D

grumel... die vorgängerversion war 1.0.1.0 ?

hmpf... probier mal ohne xyz... wenn das geht... dann bau ich heute abend mal weng um... das ist dann immer das imagemagick das zickt.... wollte es ja vereinfachen daher habe ich ja die convert.exe mit ins tools verzeichniss... aber mhh da mag bei einigen rechnern nicht... da werde ich erstmal unter den einstellungen eine pfadangabe machen wo man den ort von den imagemagick installation angiebt.... das ist dann erstmal nen workaround bis ich das komplett ins programm integriert habe....

ne ne kleine anmerkung, zum "avatar, größen thread" weil du sagstest das im vergleich zu den anderen filmen avatar ne "normale" größe hat... oehm die anderen sind teilweise aber 2D, und bei 3D hat man im prinzip aufjedenfall das doppelte an Bild daten, da ja jedes bild doppelt da ist, repektive 48fps.... somit ist die größe eigendlich nicht normal....

jup das ganze basiert auf der openjpeg lib in der aktuellen version, als parameter die cinema profile.... jo mit der avatar theorie, das ist schon einleuchtend, da man damit die max quali in jeden bild rausholen kann.... aber ob das gemacht wird.. mhh.... ist ja auch ne frage von konstantheit... also ob man das nicht im laufenden film merkt die qualitäts unterschiede....

mhh ich kann mir ehrlich gesagt nicht vorstellen das das so gemastert wird, also jedes bild checken und die komprimierungsrate anpassen.... ich glaub da werden alle bilder mit einer kompressionsstufe durchgerechnet... man kann glaub ich auch beim fertigen bild nicht mehr herrausfinden mit welcher stufe es komprimiert wurde... zumindest habe ich bisher das nicht rauslesen können....

wo waren wir denn stehen geblieben... ach ja farbraum.. also aktuell verwende ich folgende matrix zum sRGB -> XYZ konvertieren.. 0.4124564 0.3575761 0.1804375 0.2126729 0.7151522 0.0721750 0.0193339 0.1191920 0.9503041 vorher gamma auf 0.454545 und nach der umrechnung gamma auf 2.6 wie oben zu sehen nehme ich sRGB als grundlage für den ausgangsfarbraum, referenz weiß D65

ich glaub eher das er den XDC G3 Server meint... :)

ich habe gerade ne neue version hochgeladen, die etwas an den filename bzw im assetmap ändert... da hatte ich weng schmarrn drin...

mhh in was liegen denn dann die bilder von wenn man DPX material hat.... ist das typischerweise dann YUV Farbraum oder schon XYZ ? ftp lege ich später dann an, muss erstmal noch andere sachen machen, da kommt man ja zu garnix mehr :D

also FTP ist kein problem, da habe ich unlimited :) @carstenk: Zur kompression, da gibs viel viel an optionen... man kann z.b. jeden layer mit einer anderen komprimierungsstufe komprimieren etc... aber ich denke das wäre zu viele optionen für die meisten... und da andere komprimierungs optionen einzustellen, ist ja echt das geringste :) von daher...

habe mich gerade mal weng genauer über die J2K komprimierung schlauer gemacht... http://www.intopix.com/pdf/JPEG%202000%20Handbook.pdf das was wir nutzten ist eine Virtuelle verlustfreie Komprimierung.... also der mensch sieht die "verluste" nicht... daher wird das warscheinlich heufiger einfach als verlustfreie komprimierung betitelt... ist zwar eigendlich falsch, aber naja... die komplett "mathematische" verlustfreie komprimierung schafft 2:1 ratio...

ja das mit dem ffmpeg kann man mal als zukunftsoption im hinterkopf behalten... im moment greife ich ja noch auf div. externe tools zurück, daher benötigt man die bilder als datei... ich werde versuchen die ganzen sachen schritt für schritt direkt in das programm zu integrieren, wenn ich das dann soweit integrierte habe das im prinzip nur noch das JPEG2000 file als zwichenprodukt existiert, bzw sogar direkt das mxf geschrieben wird, dann kann man an sowas denken.... naja klar ist JEPG2000 komprimiert, aber es wird (oder sollte) nur der nicht verlustbehaftete modus verwendet, im gegenteil von normalen jpegs die halt immer verlustbehaftet sind :)

naja da MJEPG vom prinzip her auf einzelbilder basiert, brauch man ja sowieso einzelbilder, da kommt man ja nicht drum rum, klar hat man es mir großen datenmengen zu tun, aber das ist ja nur für die dauer der konvertierung.... wüsste nicht wie ich das direkt an nen video decoder knüpfen soll, da es ja mehrere schritte bis zum gewünschten material ist... mhh jpg ist generell kein problem.... nur ist jpeg meiner meinung nicht das richtige material für ein 2k "mastering" da jpeg ja eine verlustbehaftete komprimierung ist, normal lassen sich entsprechend hochwertige digicams auch auf ein anderes format umschalten... daher hatte ich ja bmp gewählt, ok ist groß da komplett unkomprimiert, aber eben ohne verluste, aber wenn man tif nimmt, hätte man z.b. bei einen 8bit tif nur 2,5MB pro Bild bei 2k auflösung (bmp wären es 8MB)

gerade mal weng gedanken gemacht.... was für input formate man noch unterstützten sollte.... denke das man ein paar auswählen sollte.. weil eine zu große anzahl macht eigendlich kein sinn... ich hätte jetzt an folgende gedacht bmp tif dpx somit hat man zu dem im moment unterstützten bmp auch noch 2 weitere formate die bis 16bit Farbtiefe unterstützten.... und sind alle verlustfrei komprimiert, somit verliert man auch nichts an quali... einwände?

danke, geht zu lesen... mal sehen wie man das einbauen kann, gibs ja dann wieder verschiedene kombinations möglichkeiten... mit/ohne XYZ konversion... da kann man gleich auch noch *.png mit unterstützt als ein verbreiteteres format was 16bit kann...

hihi