Различных filesizes для изображений генерируются с использованием октавы и Python

Question

Я использую Python (scikit-изображение) и октаву, чтобы генерировать 200 изображений следующим образом

python3

import numpy as np 
from skimage.io import imsave 

images = [255*np.ones((100,100), dtype=np.uint8), # white 
      np.zeros((100,100), dtype=np.uint8)] # black 

for i in range(200): # save alternating black and white images 
    imsave('%04d.png'%(i+1), images[i%2]) 

октавной

pkg load image; 

im1 = 255*ones(100,100); # white 
im2 = zeros(100,100); # black 
for i=1:200 
    name = sprintf('%04d.png', i); 
    if mod(i,2) == 0 
     imwrite(im1, name); 
    else 
     imwrite(im2, name); 
    end 
end 

Далее, я использую ffmpeg для генерации t горе-видео (чередующиеся белые и черные кадры) из этих двух наборов изображений с помощью следующей команды

ffmpeg -r 10 -loglevel quiet \ 
     -i ./%04d.png -c:v libx264 \ 
     -preset ultrafast -crf 0 ./out.mkv 

1. Размеры файлов изображений, полученных с помощью обоих этих кодов различны.

   • октавных {белые: 192 байт, черные: 98 байт}
   • Python {белые: 120 байт, черный: 90 байт}

2. Размеры видеофайлы, полученных от этой октавы и Python изображения существенно отличаются друг от друга.

   • Октав {размер файла: 60 ​​килобайт}
   • Python {размер файла: 116 килобайт}

Почему у нас это, видимо, очень странное поведение?

EDIT

Поскольку было высказано предположение о том, что поведение может быть оброк октавы и питон, используя различные битовые глубины для хранения изображений, я изменяю код октава использовать 8-битные числа

im1 = uint8(255*ones(100,100)); # white 
im2 = uint8(zeros(100,100)); # black 

и теперь размеры файлов изображений почти одни и те же

• Octave {белый: 118 байт, черный: 90 по тес}
• Python {белый: 120 байт, черный: 90 байт}

, но проблема по-прежнему то же самое для видео файлов, октаву: 60K, питона: 116K

Answer 1

scikit-изображение (с использованием PIL под капотом) сохраняет PNG в 8-битном формате, в то время как октава использует 16-разрядную (как упоминается в @carandraug ниже, это происходит из-за того, что данные с плавающей запятой представлены в Octave, которые PNG не поддерживает напрямую, поэтому данные вместо этого преобразован в uint16). Это само по себе объясняет разницу в размерах (хотя их могут быть и другие тонкие различия в способах работы их кодеров).

scikit-изображение:

$ identify 000*.png 
0001.png PNG 100x100 100x100+0+0 8-bit RGB 256c 120B 0.000u 0:00.000 
0002.png[1] PNG 100x100 100x100+0+0 8-bit RGB 256c 90B 0.000u 0:00.000 
0003.png[2] PNG 100x100 100x100+0+0 8-bit RGB 256c 120B 0.000u 0:00.000 
0004.png[3] PNG 100x100 100x100+0+0 8-bit RGB 256c 90B 0.000u 0:00.000 
0005.png[4] PNG 100x100 100x100+0+0 8-bit RGB 256c 120B 0.000u 0:00.000 
0006.png[5] PNG 100x100 100x100+0+0 8-bit RGB 256c 90B 0.000u 0:00.000 
0007.png[6] PNG 100x100 100x100+0+0 8-bit RGB 256c 120B 0.000u 0:00.000 
0008.png[7] PNG 100x100 100x100+0+0 8-bit RGB 256c 90B 0.000u 0:00.000 
0009.png[8] PNG 100x100 100x100+0+0 8-bit RGB 256c 120B 0.000u 0:00.000 

Октава:

$ identify 000*.png 
0001.png PNG 100x100 100x100+0+0 16-bit RGB 98B 0.000u 0:00.000 
0002.png[1] PNG 100x100 100x100+0+0 16-bit RGB 192B 0.000u 0:00.000 
0003.png[2] PNG 100x100 100x100+0+0 16-bit RGB 98B 0.000u 0:00.000 
0004.png[3] PNG 100x100 100x100+0+0 16-bit RGB 192B 0.000u 0:00.000 
0005.png[4] PNG 100x100 100x100+0+0 16-bit RGB 98B 0.000u 0:00.000 
0006.png[5] PNG 100x100 100x100+0+0 16-bit RGB 192B 0.000u 0:00.000 
0007.png[6] PNG 100x100 100x100+0+0 16-bit RGB 98B 0.000u 0:00.000 
0008.png[7] PNG 100x100 100x100+0+0 16-bit RGB 192B 0.000u 0:00.000 
0009.png[8] PNG 100x100 100x100+0+0 16-bit RGB 98B 0.000u 0:00.000 

На моей машине (FFmpeg 2.8.11-0ubuntu0.16.04.1), оба видео в конечном итоге 116KB.