Крах в image_io относительно маловероятен. Можете ли вы попробовать написать тестовую программу и загрузить образ вручную?

#include "mve/image_io.h"
int main() {
  mve::image::load_png_file("your path");
  return 0;
}

Есть ли еще что-то особенное в изображении? Это 8 или 16-битный PNG?

Хорошо, я скомпилировал тестовую программу и пытаюсь загрузить PNG, который находится в той же папке, что и тестовое приложение. Я получаю тот же результат, программа вылетает с "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)".

Однако, если я изменю вызов функции на «load_tiff_file» и вместо этого загружу файл TIFF, он, похоже, будет работать нормально. Может конкретно функция load_png_file сломана?

Не уверен, что это поможет, но я изменил код обратно на load_png_file и использовал strace для получения системных журналов, связанных с этим приложением. Это последние несколько строк этого журнала перед сбоем:

14:00:46.197536 открыть("./frame_0001.png", O_RDONLY) = 3
14:00:46.197561 fstat(3, {st_mode=S_IFREG|0664, st_size=407653, ...}) = 0
14:00:46.197582 читать(3, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\5\0\0\0\2\320\10\2\0 \0\0@\37J"..., 4096) = 4096
14:00:46.197651 mmap(NULL, 2768896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcadc163000
14:00:46.198666 --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x40b69d} ---
14:00:46.337334 +++ убит SIGILL (сброс ядра) +++

Не могли бы вы прислать мне ссылку на это изображение?

Я предполагаю, что изображение просто имеет расширение png, но на самом деле не является png ... Я видел похожие проблемы, когда файл «.png» был фактически закодирован в формате jpeg.

http://maxdid.it/gamejam/img/frame_0001.png

Я использовал ffmpeg для экспорта кадров видео в файлы изображений.

Я подумал, что это может быть неправильный формат файла, но я использовал команду convert, чтобы преобразовать его из png в tiff и обратно, но безрезультатно.

Здесь файл загружается нормально.

open("frame_0001.png", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0640, st_size=691915, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5395d8a000
read(3, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\5\0\0\0\2\320\10\2\0\0\0@\37J"..., 4096) = 4096
mmap(NULL, 2768896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5393b87000
read(3, "\7\0?)\363\207i\27\30x'\356\330\214Xg\7\260\334W\23G\371\323\31 \323\2S\273\353\\"..., 4096) = 4096
...

Согласно вашему strace ваша программа убита SIGILL (не KILL). Я считаю, что это означает, что ваш процессор или ОС пытаются выполнить неверную инструкцию. Я не знаю, что с этим делать, но я полагаю, что это ваша система или ваша библиотека libpng, которая как-то испортилась. Можете попробовать переустановить/обновить libpng?

Итак, я удалил версию libpng, которую я установил с помощью apt-get install, и вместо этого напрямую загрузил репозиторий libpng, скомпилировал его и установил.

К сожалению, эффект тот же. Может это действительно мой процессор? В настоящее время я использую процессор AMD Phenom II X4 965, думаю, это не самая новая модель. Тем не менее, я не думаю, что у меня когда-либо были подобные проблемы раньше.

В любом случае, поскольку вы, ребята, не можете воспроизвести проблему, думаю, я закрою тему.

Мне жаль слышать, что это все еще не работает. Я действительно не думаю, что это ваше оборудование... но у меня нет идей. Может быть, есть флаги времени компиляции, чтобы отключить определенные функции ускорения для libpng? На данный момент я просто предполагаю, не зная, что вызывает проблему.

Я знаю, почему makescene вылетает при импорте файлов изображений после многих экспериментов. Это не причина libjpeg или libpng, настоящая причина - openMP. Вы можете исправить эту ошибку с помощью этих кодов в makescene.cc:
845 линия
mve::ImageBase::Ptr изображение;

pragma omp parallel для упорядоченного расписания (динамический, 1)

for (std::size_t i = 0; i < dir.size(); ++i)

....
std::string exif;

прагма критический

    image = load_any_image(afname, &exif);

...

Но это изменение не имеет особого смысла. Вы сохраняете изображение в переменной image , которая является общей для всех потоков, и хотя загрузка изображения теперь сериализована, вы перезапишете изображение из-за условий гонки и будете использовать неверные данные после загрузки изображения. ..

Вы пытались просто поставить критическое значение #pragma omp перед загрузкой изображения?

@timlgy , не могли бы вы рассказать нам немного больше о вашей системе? Какой процессор, операционную систему и компилятор вы используете?

У меня это работает на Ubuntu 14.04.5 LTS, 16U32G и компиляторе gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) PS «неправильные данные», что это? prebundle.sfm?

согласно этой статье #pragma omp Critical
Критическая директива omp определяет раздел кода, который должен выполняться одним потоком за раз.
Поэтому я подумал, что, возможно, 'load_any_image' опасен, если поместить этот код внутри mve::ImageBase::Ptr imagel=oad_any_image(afname, &exif);

load_any_image просто использует libpng в фоновом режиме, что является потокобезопасным при правильном использовании, что, я надеюсь, мы и делаем. Под «неправильными данными» я подразумеваю, что в приведенном выше коде изображение может быть перезаписано другим изображением до того, как оно будет использовано, и, таким образом, вы получите неправильные данные изображения в своем представлении.

Теперь просто для понимания этой проблемы, кого на самом деле затронули эти сбои?

Когда я загружаю только одно изображение (любого типа jpg tif или png) все в порядке, но когда я загружаю два изображения (любого типа) с высокой вероятностью происходит сбой.

Я не знаю, что вызывает проблему. Загрузка изображений должна быть возможной параллельно, и я никогда не видел проблем. Возможно, этот сбой связан с вашей доступной памятью, если вы загружаете действительно большие изображения? Я могу себе представить, что параллельная загрузка 32 изображений (если у вас столько ядер) на машине с 2 ГБ ОЗУ вызовет проблемы.

А пока просто поместите строку #pragma omp critical перед load_any_image , что должно решить проблему.

@timlgy , можешь опубликовать историю сбоя?
Кроме того, что вы имеете в виду под «16U32G»?

@ andre-schulz 16U32G означает многопоточность ЦП 16 и 32 ГБ памяти.

Я наблюдаю такой же сбой в Windows 7 64x с последней сборкой mve по инструкции:

Пытался поставить строку #pragma omp Critical перед load_any_image, но это не помогает, в этом случае я не могу построить. Как мы можем решить эту проблему? Для чего здесь используется OpenMP?

Пытался импортировать только одно изображение: у меня тоже такой же сбой.

Привет @stiv-yakovenko,
Спасибо за информацию. Можете ли вы опубликовать файл png, который вызывает проблему?
Кроме того, какой процессор вы используете?

0.zip

Проблема, похоже, в том, что makescene был скомпилирован в режиме отладки, но связан с libpng в режиме выпуска; вероятно, проблема со связью с разными библиотеками времени выполнения (/MD против /MDd). Это проблема с тем, как работает текущая система сборки. Я должен исследовать это дальше.
Можете ли вы подтвердить, что makescene работает в режиме RelWithDebInfo?

Если вам нужно запустить makescene в режиме отладки, вы можете скомпилировать сторонние библиотеки в режиме отладки, добавив Debug к CMAKE_CONFIGURATION_TYPES в стороннем CMakeLists.txt . Затем перекомпилируйте и вручную скопируйте отладочные версии библиотек в расположение отладочной версии makescene . Я попытаюсь выяснить, могу ли я как-то это исправить/автоматизировать.

Я подтверждаю, что версия ReleaseWithDeb работает.

@andre-schulz Привет, спасибо за ваш анализ режима отладки. Я перекомпилировал сторонние библиотеки в режиме отладки и добавил tiffd.dll, zlibd.dll в отладочную версию makecene. Программа все равно вылетает

png_read_image(png, &row_pointers[0]);

@andre-schulz Теперь все в порядке! После полной компиляции отладки после изменения CMAKE_CONFIGURATION_TYPES в CMakeLists.txt сторонних библиотек и изменения конфигурации входной библиотеки MVE.sln проблема с загрузкой jpg решена.