Загрузка больших изображений JPG в qt не удалась [дубликат]
Другой способ взглянуть на это: Используются 64 бита для представления чисел. Как следствие, не может быть представлено более 2 ** 64 = 18 446 744 073 709 551 616 различных чисел.
Тем не менее, Math говорит, что существует уже бесконечное число десятичных знаков между 0 и 1. IEE 754 определяет кодировку для эффективного использования этих 64 бит для гораздо большего количества пробелов плюс NaN и +/- Infinity, поэтому есть пробелы между точно представленными числами, заполненными числами, только приближены.
К сожалению, 0,3 сидит в промежутке.
4 ответа
Оба ограничены 32767x32767 пикселей. То есть вы можете думать о них как о использовании подписанного 16-битного значения для разрешения X и Y.
Никакая ось не может превышать 32767 пикселей, даже если другая ось имеет только 1 пиксель. «Битность» операционной системы не влияет на ограничение. Основная система может работать в других пределах, таких как память, как вы упомянули, до создания такого огромного изображения.
Вы можете увидеть пример этого ограничения в следующем исходном коде: http : //git.zx2c4.com/qt/plain/src/gui/image/qpixmap_x11.cpp
if (uint(w) >= 32768 || uint(h) >= 32768) {
w = h = 0;
is_null = true;
return;
}
-
1– Thorbjørn Lindeijer 6 April 2015 в 20:30
-
2– quimnuss 7 May 2018 в 13:13
-
3– quimnuss 7 May 2018 в 13:36
У меня действительно было время разобраться в этом. Сделайте поиск в исходном коде qimage.cpp для «проверки работоспособности для потенциальных переполнений», и вы можете увидеть проверки, которые выполняет Qt. В основном,
- Количество требуемых байтов (width * height * depth_for_format) должно быть меньше
INT_MAX. - Он должен иметь возможность
mallocиспользовать эти байты в то вы создаете экземплярQImage.
Основываясь на ответе @ charles-burns, вот соответствующий исходный код для QImage:
QImageData *d = 0;
if (format == QImage::Format_Invalid)
return d;
const int depth = qt_depthForFormat(format);
const int calc_bytes_per_line = ((width * depth + 31)/32) * 4;
const int min_bytes_per_line = (width * depth + 7)/8;
if (bpl <= 0)
bpl = calc_bytes_per_line;
if (width <= 0 || height <= 0 || !data
|| INT_MAX/sizeof(uchar *) < uint(height)
|| INT_MAX/uint(depth) < uint(width)
|| bpl <= 0
|| height <= 0
|| bpl < min_bytes_per_line
|| INT_MAX/uint(bpl) < uint(height))
return d; // invalid parameter(s)
Итак, bpl - это количество байт на строку, что эффективно width * depth_in_bytes. Используя алгебру в этом последнем недействительном тесте:
-
INT_MAX/uint(bpl) < uint(height) -
INT_MAX < uint(height) * uint(bpl) -
INT_MAX < height * width * depth_in_bytes
Итак, ваш общий размер изображения должен быть меньше, чем 2147483647 (для 32-битных ints).
Вы строите 64-битное приложение? Если нет, вы очень быстро столкнетесь с проблемами памяти. В Windows, даже если устройство имеет 16 ГБ оперативной памяти, 32-битный процесс будет ограничен 2 ГБ (если это не LARGEADDRESSAWARE, а затем 3 ГБ). Изображение размером 16000x16000 будет чуть меньше 1 ГБ, поэтому вы сможете выделить достаточно памяти на 1, а может быть, на 2, если вам повезет.
С 64-битным приложением вы сможете выделить достаточно памяти для нескольких изображений.