LoadPicture и битые картинки

[The trick]

Посмотри это.

[sosed213]

Да, спасибо. Этот метод я тоже использовал (писал вначале про GDI Plus).

Но основная фишка родного LoadPicture, что если JPG-файл "битый", то возникает ошибка, и можно этот момент обрабатывать.
Но бывает что вместо ошибки, программа зависает.

Вот как бы сделать так, чтобы программа из своего ресурса, запускала маленькую программу (или библиотеку) (напрямую в память, без сохранения на hdd) которая побывала открывать jpg-файл, и если надо, то пусть себе на здоровье зависает. ( Может ошибусь, но что то типо Pipe сделать)

[Debugger]

Да, спасибо. Этот метод я тоже использовал (писал вначале про GDI Plus).

Но основная фишка родного LoadPicture, что если JPG-файл "битый", то возникает ошибка, и можно этот момент обрабатывать.
Но бывает что вместо ошибки, программа зависает.

Вот как бы сделать так, чтобы программа из своего ресурса, запускала маленькую программу (или библиотеку) (напрямую в память, без сохранения на hdd) которая побывала открывать jpg-файл, и если надо, то пусть себе на здоровье зависает. ( Может ошибусь, но что то типо Pipe сделать)

Файл в студию

[sosed213]

Вот, файл в студию.

[sosed213]

Debugger, глянул? Есть идеи?

[The trick]

Но основная фишка родного LoadPicture, что если JPG-файл "битый", то возникает ошибка, и можно этот момент обрабатывать.
Но бывает что вместо ошибки, программа зависает.

Ну так сделай внутри генерацию ошибки по типу If hBmp = 0 Then Err.Raise 481

[Debugger]

Debugger, глянул? Есть идеи?

Да, я очень удивлен, что VB6 и вправду зависает (и на самом деле ждал, пока придет Хакер, и напишет, почему так происходит).

Похоже, встроенными функциями не получится решить задачу. Что-то мешает пользоваться GDI?

[sosed213]

The trick, в том то и дело, что если грузить через GDI Plus, то hBmp не равно 0 (увы).

Надеюсь что и правда, Хакер подскажет.

[Хакер]

Да, я очень удивлен, что VB6 и вправду зависает (и на самом деле ждал, пока придет Хакер, и напишет, почему так происходит).

Я пока не смотрел.
VB6 не стоит обвинять, ибо он всецело полагается на OLEAUT32.DLL для получения ссылки на IPicture из файла.

Во-первых, в пространстве имён по умолчанию будет две функции LoadPicture.

load_picture_in_vb_scope.png (3.86 Кб) Просмотров: 8753

У одной из них ноги растут из TLB-шки «olelib», которая по дефолту подключена в References ко всем новым проектом. Это просто продекларированная функция из OLEAUT32.DLL — функция называется OleLoadPictureFileEx.

Так что когда вы вызываете этот вариант LoadPicture, вызов сразу идёт в системную API, в обход рантайма. VB не имеет никаких шансов вмешаться и повлиять на процесс. То, что от битых файлах эта системная функция зависает — проблема не VB, а общесистемная.

Вторая LoadPicture — это метод аппглобального объекта (аппглобальный объект — это объект класса Global, свойствами которого являются, к примеру, App, Screen, Printers, Clipboard и т.п.). Собственно говоря, если первая функция даже не обёртка, а прямой отсыл к системной API, то тут всё-таки обёртка. Но не смотря на это, обёртвывающая логика — это преобразование исключительно Variant-ных параметров в типизированные, конвертация единиц изменения, подготовка на основе имени файла объекта, поддерживающего интерфейс IStream, и скармливание этого объекта и преобразованных параметров опять-таки системной API-функции OleLoadPictureEx.

Так что VB к зависаниям отношения не имеет.

[Хакер]

Надеюсь что и правда, Хакер подскажет.

Я уже сказал: все эти функции, что из OLE, что из GDI — написаны не как детекторы нарушений формата и всевозможных повреждений. Они написаны, чтобы просто загружать картинку, написаны из соображений, что им будут скармливать только нормальные не битые картинки. Никто не гарантирует их нормальную работу на всех теоретически возможных вариантах повреждений файлов.

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

Если стоит именно задача детектирования битых файлов, то ничего не остаётся, кроме как взять в руки мануал на формат, разобрался и написать этот валидатор, который будет тщательно проверять каждую мелочь, каждый байтик, каждую структуру и оценивать, нет ли тут подозрительных вещей. Либо взять готовый, но опять таки, готовый именно валидатор, а не какой-нибудь загрузчик.

[Qwertiy]

Написать просто оптимистичный загрузчик всегда в пару порядков проще

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

[Хакер]

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

Оптимистичный — этот тот, который написан исходя из идеи и действует исходя из расчёта, что файл заведомо корректен.

Так, например, если у нас в файле есть какая-то цепочка элементв, и каждый элемент хранит файловое смещение на следующий элемент, то оптимистичный загрузчик просто пройдётся по цепочке, и не будет заморачиваться на то, чтобы строить и поддерживать отдельный список список уже посещённых элементов цепочки и сверять с ним каждый новый элемент, на случай, если в результате повреждения файла цепочка оказалась закольцованной.

[Qwertiy]

Оптимистичный — этот тот, который написан исходя из идеи и действует исходя из расчёта, что файл заведомо корректен.

Собственно варианты:

• Код рассчитан на то, что ему подаются заведомо корректные входные данные. Не проверяет ничего, сам ошибки не бросает никогда (но если внутри что-то упадёт, вызывающий код об этом узнает). По сути, это для приватных методов, где вызывающий код должен обеспечить инвариант. Делать такие методы открытыми - весьма подозрительное решение.
• Код рассчитанный на то, что если на вход подаются корректные данные, то результат корректный. Если некорректные, то попытаться их как-то интерпретировать. Сделать всё что возможно, чтобы получить хоть что-то. Никогда не падать. Редкая ситуация, но иногда используется.
• Код рассчитанный на то, что если на вход подаются корректные данные, то результат корректный. Если некритично некорректные, то как-то интерпретировать. Если некорректность критичная, то выкинуть ошибку. Вот это бы я назвал оптимистичным.
• Код рассчитанный на то, что если на вход подаются корректные данные, то результат корректный. Если некорректные, выбрасывает ошибку. По сути, это уже валидатор формата.

Получается, ты называешь оптимистичным первый вариант? Или какой-то промежуточный между первым и третьим? На мой взгляд, у промежуточного почти нулевая ниша использования.

[Хакер]

Собственно варианты:

Без вариантов.

Оптимистичный — значит основная логика рассчитана на обработку корректных входных данных. Некорректные входные данные обрабатываются по мере нормальной работы с данными и не более того. Это значит, что любая нетривиальная проверка корректности не делается.

Я привёл хороший пример: если у нас в файле есть односвязный список (в каждом элементе — файловое смещение на следующий элемент) или древовидный граф (в каждом элементе — файловые смещения на детей). Если мы пишем код, основная задача которого — обработать правильный входной файл, то мы просто будем идти по цепочки или дереву. Тривиальные проверки мы при этом делать можем. Например взять и проверить, не указывает ли файловое смещение за пределы файла. Отследили некорректность — просигнализировали наверх. Это легко. Если у каждого элемента или структуры есть сигнатура — её легко проверить. Тоже легко.

Другое дело, это удостовериться, что цепочка не превратилась в кольцо, а изначально древовидный граф не является графом с циклом. Это нужно строить и проверять специальный индекс уже посещённых файловых элементов. Это дополнительный код, требующий дополнительного времени и трудозатрат и их оплаты. Количество нарушений, которые могут быть в файле, просто невероятно. Если из разбить на классы и анализировать по-классово — то всё равно получается много. Поэтому понятно, что эти нетривиальные проверки в код OleLoadPicture не сделали.

Или вот например взять любой файл, в котором есть разные структуры, адресуемые файловыми смещениями. По хорошему, чтобы делать валидацию, нужно взять проверить все структуры на предмет их возможного взаимопересечения. Это требует реализовать специальную структуру данных и специальный алгоритм для обнаружения наслоения одних данных на другие.

Люди, пишущие анализатор корректности файлов на такое заморочатся. А люди, от которых потребовали просто сделать загрузчик нормальных картинок, ясное дело, что не стали чем-то таким озадачиваться.

[Хакер]

Пореверсил тут я немного.
Как я и предполагал, зависает поток в бесконечном циклическом чтении JPEG-файла.

Но виновата не OLEAUT32.DLL, а виновата asyncfilt.dll — именно в ней алгоритм обработки JPEG, который и виснет.

[Qwertiy]

Другое дело, это удостовериться, что цепочка не превратилась в кольцо, а изначально древовидный граф не является графом с циклом.

Ну, я бы посчитал багом, если лоадер зациклился.
В большинстве случаев, кстати, код рано или поздно грохнется с out of memory. Если мы не просто перебираем всё, ничего при этом не сохраняя.
А в конкретно примере с цепочкой - не надо хранить и проверять, надо вместо вечного цикла сделать цикл не больше длины файла - если мы выполнили большее количество итераций, то цикл точно есть.

нужно взять проверить все структуры на предмет их возможного взаимопересечения

А что плохого в их пересечении? Так можно сжатие попытаться организовать, при желании.

[Хакер]

А что плохого в их пересечении? Так можно сжатие попытаться организовать, при желании.

О, вот видишь. Помимо технических сложностей (необходимости проводить саму по себе проверку пересечений), придётся ещё и озадачиться ответом на вопрос о том, а является обнаруженный подозрительный факт дефектом в файле, или это какой-то допустимый оптимизационный трюк.

[Хакер]

Итак, немного деталей.

На определённом этапе oleaut32 проверяет, загружены ли необходимые библиотеки (в числе которых asyncfilt.dll), и если нет — то загружает её. Делается это однократно, при первом вызове LoadPicture.

Дальше вызывается экспортируемая из asyncfilt.dll функция FilterCreateInstance — одна из всего лишь 2 экспортируемых этой библиотекой функций (вторая это DllCanUnloadNow). Вообще asyncfilt.dll это COM-библиотека (но не ActiveX), с такой же моделью использования, как, к примеру, Direct3D. Т.е. позволяет создавать COM-объекты, но не через CoGetClassObject+IClassFactory (как принято в ActiveX), а с помощью особой функции.

Функция FilterCreateInstance возвращает ссылку на объект, поддерживающий интерфейс IImageFilter (официального описания этого интерфейса я нигде не нахожу). На самом деле, функция возвращает HRESULT, а ссылка возвращается через последний аргумент (retval), как это принято в COM.

В числе аргументов: CLSID создаваемого объекта, REFIID интерфейса, указатель на который будет возвращён.

В качестве CLSID допустимо (по крайней мере у меня на XP) передавать одно из следующих значений:

• CLSID_GIFFilter
• CLSID_JPEGFilter

Если передано что-то другое, будет возвращён HRESULT-код 0x80004005 (E_FAIL).

Как уже понятно, внутри библиотеки есть два класса CGIFFilter и CJPEGFilter, и эта функция порождаёт и возвращает указатель на интерфейс нужного из них.

Они поддерживают 6 интерфейсов (не считая IUnknown):

• DataTransfer
• IDirtyImageRect
• IImageFilter
• IOriginalFormat
• IPersistStream
• ITaskAdvise (имя фигурирует в тексте патента US6430591)

После вызова FilterCreateInstance код в oleaut32.dll, у возвращённого объекта запрашивается IPersistStream и ITaskAdvise.
Вызывается ITaskAdvise::Initialize (чтобы инициализировать фильтр), а затем вызовом IPersistStream::Load в объект загоняются сырые данные, которые ему предстоит обработать (вернее не сами данные, а абстракция над ними в виде интерфейса IStream).

После этого идёт цикл примерно такого содержания:

Код: Выделить всё

while(pTaskAdvJpegFilter->IsFinished() == S_FALSE)
{
    hr = pTaskAdvJpegFilter->DoWork(0, pSyncAdv);
}

Как не трудно догадаться, метод DoWork делает основную работу по декодированию JPEG-данных, причём делает это в пошаговой манере, так что его вызов засунули в цикл. Этот метод реализован в классе CImageFilter — родительском классе, от которого унаследованы CJPEGFilter и CGIFFilter, так что эта часть логики общая для всех типов файлов.

Сам метод DoWork после некоторых проверок внутреннего состояния вызывает у объекта метод GetMore. GetMore является чисто виртуальным — у CImageFilter он определён, но не проимплементирован, а имплементируется только в дочерних CJPEGFIlter и CGIFFilter, то есть для каждого типа файлов (JPEG/GIF) логика получения следующей порции данных может быть своя. Этот метод GetMore не является членом какого-либо COM-интерфейса.

Что же делает CJPEGFilter::GetMore? В зависимости от некоего внутреннего поля-состояния объекта, котороые может принимать одно из 3 значений, вызов GetMore транслируется в вызов одного из трёх методов:

• CJPEGFilter::ReadHeader
• CJPEGFilter::DoScanLines
• CJPEGFilter::EndDecompression

При этом после вызова ReadHeader или DoScanLines проверяется код возврата (HRESULT), если он не сбойный (самый старший бит установлен), то проверяется, равен ли он S_OK. S_OK, очевидно, показывает, что чтение соответствующей части закончено (а не сбойный и не равный S_OK — что остались ещё данные). Если возвращён S_OK, то поле (то, которое принимает только 3 значения) меняется так, чтобы следующий вызов GetMore привёл к обращению не к ReadHeader, а к DoScanLines, или не к DoScalLines, а к EndDecompression.

В норме обработка JPEG-файла проходит все эти 3 шага: вызов ReadHeader, вызов DoScanLines и вызов EndDecompression.

Но в случае с битым файлов возврата из CJPEGFIlter::EndDecompression не происходит.

Что делает этот злосчастный EndDecompression. Он вызывает две обычных плоских процедуры:
jpeg_finish_decompress
и затем
jpeg_destroy_decompress


Именно jpeg_finish_decompress — та процедура, внутри которой имеет место происходить бесконечный цикл.

Дальнейшую логику я пока не отслеживал, там идёт мудрёный код расшифровки JPEG-данных.

[Mikle]

Сейчас потестировал немного, попробовал загружать с помощью D3DX8 - неотслеживаемый вылет, D3DX9 - тоже неотслеживаемый вылет, GDI+ - загружается так, будто ошибки нет, просто половина изображения серая, можно тут же сохранить, естественно с этой серой частью на картинке.

[sosed213]

Более-менее стало понятно как работает обертка LoadPicture.

А вот как бы самому сделать такую обертку, но учесть зацикливание в jpeg_finish_decompress, чтобы видеть приходит S_OK, или нет.

[Sam777e]

@sosed213

GDI+ - загружается так, будто ошибки нет, просто половина изображения серая

Вот, может быть, и проверять загруженные картинки на наличие характерной серой области ?

[Mikle]

А если на картинке БЫЛА серая область внизу?

[The trick]

Тут нужно либо юзать стороннюю либу (можно и в LIB), либо запускать в отдельном потоке загрузку и прибивать поток при необходимости.

[Mikle]

Или, как вариант, написать самому или найти готовое на VB6. Если сохранение в Jpeg сделали, то и загрузку можно осилить.

[Sam777e]

@Mikle
Полностью согласен.

Да понятно, что это не панацея, а некая эвристика/паллиатив, идея для творчества. Я же предлагаю проверять не левый нижний пиксель..., а "характерной серой области" - размеры, наличие, опять же, характерной границы, регулярных или наоборот, случайных точек; простор для фантазии и творчества; как в мозговом штурме? идеи самые чуднЫе бросать можно, а с критикой ни-ни . Сам 10-15 лет не писал ничего, связанного с графикой, может есть средства быстрого сравнения больших блоков данных (!??); так, проходя мимо, бросил [ возможно - стоящую полкопейки ] "идею" ... 100% она, конечно, не даст; но, вдруг , снизит количество зависаний. Хотя понимаю, что даже одно-единственное - уже очень плохо.

И потом, ведь при таком подходе можно без зависаний на выходе получить примерные списки хороших / плохих / подозрителььных картинок и работать с ними дальше - короче, придумать не совсем промокаемый порох


С большим уважением

[sosed213]

Вот, может быть, и проверять загруженные картинки на наличие характерной серой области ?

Не всегда она именно серая, может быть и белой, а может и зеленой.

пример прикладываю (по запросу в яндекс картинках: corrupted jpg)

Тут нужно либо юзать стороннюю либу (можно и в LIB), либо запускать в отдельном потоке загрузку и прибивать поток при необходимости.

Вот это первое мне и пришло в голову, писал об этом выше.