Dlaczego niektóre pliki JPEG tej samej sceny są znacznie większe niż inne?

Używam kamery IP Foscam FI8910W, aby oglądać scenę statyczną w stałych warunkach oświetleniowych. Kiedy odciągam uchwyt ramy, jego rozmiar wynosi około 35 KB. Mogę to robić w kółko i zawsze ma około 35 KB, ale waha się nieco z powodu różnych dźwięków nieodłącznie związanych z elektronicznym rejestrowaniem obrazu. Ta losowa fluktuacja ma wielkość najwyżej 1 KB.

Około 2500 ramek rozmiar obrazu nagle zmienia się na 70 KB. Nie ma stopniowego pełzania w górę, jeśli myślisz o szumie termicznym, gdy kamera się nagrzewa. 1 ramka będzie miała 70 KB (ish), a następnie powrócą do ramek o rozmiarze 35 KB.

Stało się to wcześniej, gdy kolejny bieg patrzył na inną scenę. Wspólny rozmiar pliku wynosił wtedy 39 KB, a na 10 000 ramek 4 były rzędu 77 KB. Histogram wielkości obrazu wyglądał następująco: -

Zanim zapytasz, udało mi się zapisać jedną z tych ramek i wygląda to tak, jakby wszystkie inne zakazywały oczekiwanej fluktuacji hałasu. Mają mniej więcej taką samą liczbę unikalnych kolorów na około 23 000. Więc nie jest to ćma przypadkowo lądująca na obiektywie dla dokładnie 1 klatki, a następnie odlatująca. Dla kompletności wykonałem kolejny ciąg obrazów i jest to przykład typowego obrazu (odbicie to oświetlacz IR): -

To jest obraz nieprawidłowości :

Widać, że nie ma różnicy. Przepraszam hipopotama. Jestem dość zaznajomiony z algorytmem JPEG i nie widzę, jak to się mogło stać, oprócz błędu kodowania przy implementacji Foscam. Ale czy może istnieć coś z natury chaotycznego w niektórych funkcjach transformacji JPEG (takich jak dyskretna transformacja kosinusowa lub kwantyzacja)? Statystycznie można by oczekiwać normalnego rozkładu wielkości pliku i to widzę około 39 KB. Następnie jest kilka wartości odstających przy 77 KB. Więc to nie wydaje się stochastyczne.

Powodem, dla którego jest to w CS, a nie w sprzęcie, jest pytanie, czy może to być zjawisko kodu programowania związane z algorytmem kodowania JPEG? Wydaje się to mało prawdopodobne, ale anomalie są losowe i rzadkie i nie ma interakcji człowieka z urządzeniem. Czy kodowanie JPEG jest stabilne?

Powodem, dla którego możesz nie być zaznajomiony z tym zjawiskiem, jest to, że ponieważ obrazy wyglądają tak samo, nikt tak naprawdę nie patrzy na rozmiary plików. Rozmiar pliku ma dla mnie kluczowe znaczenie, więc zauważyłem. Jak to się może zdarzać mniej więcej co 2500 klatek?

Uzupełniający:-

Publikowanie tych zdjęć nie zadziała, ponieważ oprogramowanie imgur ponownie próbkuje przesłane pliki. Tak więc, mimo że opublikowałem pliki 37K i 73K, imgur ponownie próbkował oba pliki do 35K. Wydaje się, że jest to problem z wymianą stosów, który wydaje się ironiczny dla strony zajmującej się przetwarzaniem obrazu, kompresją danych i analizą.

To jest moje przetwarzanie obrazów. To znormalizowana różnica między normalnym obrazem a anomalią. Obraz jest zgodny z oczekiwaniami, z szumem JPEG w regionach wysokich częstotliwości. To jest obraz RGB, chociaż wygląda monochromatycznie. W kostce kolorów znajduje się 8000 unikalnych kolorów (reprezentujących szum).

Uzupełnienie 2: -

Zgodnie z żądaniem 4 normalne ramki i 2 nieprawidłowe ramki można pobrać z ramek przykładowych . To inna scena, ale nadal zachodziło nietypowe zachowanie, co dowodzi, że jest konsekwentna.

Domyślam się, że autofokus lub przysłona zmieniają się na krótko w taki sposób, że powstały obraz zawiera więcej elementów o wysokiej częstotliwości.

Na przykład, jeśli fokus przesunie się z gładkiego obiektu na obiekt teksturowany (np. Gładki hipopotam na zasłonę materiałową) w sposób, w którym powierzchnia szczegółów tekstury tego ostatniego, JPEG będzie miał zwykle większy rozmiar.

Jak ktoś już stwierdził: dobrym pomysłem jest sprawdzenie danych EXIF ​​obrazu pod kątem zmian podstawowych parametrów, takich jak apertura i odległość ogniskowania. W przypadku tak uderzającej różnicy wielkości obrazu jest całkiem prawdopodobne, że niektóre podstawowe parametry są inne w opinii aparatu.

Z czujnikami „CMOS” często spotyka się zjawisko znane jako „FIOLETOWY PIERŚCIEŃ” lub możliwe problemy z „zakwitaniem czujnika”, które wyjaśnię bardziej szczegółowo za chwilę.

Muszę to jednak powiedzieć, mówiąc wam, że faktycznie jest trochę debaty na temat tego, czy PF jest przyczyną Sensor Bloom lub odwrotnie, ale sedno: oba mogą być wynikiem anomalii w samym obiektywie lub samym czujniku aparatu - lub obu. Efekty te mogą być wynikiem efektu kulminacyjnego, który powoduje przeciążenie, jeśli z kolei w czujniku spowoduje się skok w przechwyconym świetle. ULEPSZANIE PLIKÓW.

Wierzę, że przeciążenie występuje w zakresie purpurowym (lub fioletowym), a zjawisko to jest dość rzadkie.

Pomyśl o czujniku jak o ogromnej tacy na kostki lodu ..... ułożonej w sposób podobny do siatki. Jeśli jedna komora przepełni się wodą (światłem) z powodu anomalii ... może rozlać się na sąsiednie komory i tak dalej, powodując partię nieco większej objętości kostek lodu dla tej partii. (Prawdopodobnie wyjaśnia większy rozmiar pliku ... I dane koloru)

Teraz jest to najlepsze przypuszczenie i znalazłem link, który może okazać się pomocny z dodatkowymi informacjami na temat powyższego - TAKŻE JAKO dodatkowe informacje techniczne, które mogą pomóc w wyodrębnieniu problemu, jeśli moja ocena jest nieprawidłowa.

Sprawdź ten link http://toothwalker.org/optics/chromatic.html

Pamiętaj, że RGB to odejmująca przestrzeń kolorów. Kolor za pomocą światła (w porównaniu z pigmentami) jest manipulowany poprzez usuwanie światła o określonych długościach fal. Niektóre długości fali kolorów są dłuższe niż inne.

Na stronie znajduje się świetna lekcja optyki, która może również pomóc w wyjaśnieniu anomalii.