TheBubble hat geschrieben: ↑Di 20 Feb, 2018 11:16
Ihr könnt versuchen ein Histogramm über möglichst viele Samples aus vielen Frames zu erstellen. Mit Glück sind die "echten" Helligkeiten/Farben erkennbar häufiger vertreten, als die "Rundungsfehler". Die Anzahl der "echten" Helligkeiten/Farben erlaubt dann einen Rückschluss auf die Bittiefe der ursprünglichen Aufnahmen.
wie gesagt, natürlich ist das der weg, an den man als erstes denkt, und der im alltag und hausgebrauch sicher auch oft nützlich ist. trotzdem sind histogramme immer mit großer vorsicht zu genießen.
gehen wir ganz praktisch von jenem material aus, das uns cantsin oben nahe gelegt hat, und konzentrieren wir uns der einfachheit halber nur auf die enthalte helligkeitsinformation, allerdings in genau jener YCbCr datenrepräsenstation, wie sie in farbunterabgetasteter 4:2:0 und 4:2:2 videoübertragung üblicherweise genutzt wird, und worauf sich unsere 10bit genauigkeitsangabe eben tatsächlich bezieht.
auch wenn man sich davon ein sehr genau gerechnetes histogram ansieht, kann man leider noch immer nicht so recht sagen, ob das nun von 8bit od. 10bit ausgangsmaterial stammt -- obwohl es natürlich diese auffälligen spitzen zeigt:
wirklich deutlich wird es erst, wenn man sich ansieht, welche helligkeitswerte im bild tatsächlich genutzt werden und welche darin nicht vorkommen:
Code: Alles auswählen
Y:
[171 174 177 181 184 188 191 195 198 201 205 208 212 215 219 222 225 229
232 236 239 243 246 250 253 256 260 263 267 270 274 277 280 284 287 291
294 298 301 304 308 311 315 318 322 325 329 332 335 339 342 346 349 353
356 359 363 366 370 373 377 380 383 387 390 394 397 401 404 408 411 414
418 421 425 428 432 435 438 442 445 449 452 456 459 463 466 469 473 476
480 483 487 490 493 497 500 504 507 511 514 517 521 524 528 531 535 538
542 545 548 552 555 559 562 566 569 572 576 579 583 586 590 593 596 600
603 607 610 614 617 621 624 627 631 634 638 641 645 648 651 655 658 662
665 669 672 675 679 682 686 689 693 696 700 703 710]
wenn man sich diese geordnete liste mit werten ansieht, wird auf den ersten blick klar, dass da ganz offensichtlich gleichförmige lücken zwischen den viel zu wenigen tatsächlich benützten werten zu entdecken sind.
das spannende dran ist allerdings die tatsache, dass sie nicht exakt auf jenem raster zu liegen kommen, den man erwarten würde. statt dass zwischen den vorfindlichen werten immer 3 unbenutze liegen, ist der abstand zwischen ihnen in wahrheit oft kleiner:
Code: Alles auswählen
[3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 4,
3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 4,
3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 4,
3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4,
3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4,
3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4,
3, 3, 4, 3, 4, 3, 4, 3, 3, 4, 3, 4, 3, 4, 3, 4, 3, 7]
ich fürchte, dass man diese erscheinung im gegenständlichen fall vermutlich einfach damit erklären kann, dass beim einlesen des ursprünglichen 8bit ausgangmaterials bzw. dessen weiterer verarbeitung eine stauchung von "full range" nach "legal" vorgenommen wurde.
ganz abgesehen davon, dass man das natürlich auch schlicht als schlampigkeitsfehler meinerseits werten könnte, ist es es doch insofern interessant, als dadurch einfache überprüfungsmethoden, die WoWu ("Stuck Bits") und ich ("bitweise OR" und betrachtung der restwerte bei ganzzahliger division durch 2**2) bereits weiter oben angesprochen haben, aufs glatteis geführt werden. es ist zwar ganz eindeutig, das nur ein viertel der werte genutzte wird, aber dadurch, dass sie in einer weise gestreut sind, die mit einfachen bitmasken nicht mehr erfasst werden kann, erkennt man das mit den betreffenden überprüfungsmethoden trotzdem nicht.