Исправление локального перекоса в Лептонике 1.68

Question

У меня есть интересная проблема с Лептоникой, которая мне интересует, видели ли другие участники SO.

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

Вот соответствующий код, который производит операцию восстановления:

    // Make a black and white version for deskew calculations
    l_int32 thresh;
    PIX * deskewbw = pixMaskedThreshOnBackgroundNorm(pix,NULL,10,15,25,10,2,2,0.1,&thresh);  
    NSLog(@"Used threshold of %d to normalize image for deskew",thresh);

    // Find the local skew
    PTA * ptas, *ptad;
    pixGetLocalSkewTransform(deskewbw, 0, 0, 0, 0.0, 0.0, 0.0, &ptas, &ptad);

    // Cleanup the first B/W version
    pixDestroy(&deskewbw);

    // Deskew the original image
    PIX * deskewgray = pixProjectivePtaGray(pix, ptad, ptas, 128);

    // Reduce the deskewed original image to B/W
    pixbw = pixMaskedThreshOnBackgroundNorm(deskewgray, NULL, 10, 15, 25, 10, 2, 2, 0.1, &thresh);

Использую ли я это или функцию pixDeskewLocal (которая делает что-то подобное), я получаю ОЧЕНЬ УЖАСНЫЕ результаты с эффектом чересстрочной линии:

Просто для сравнения, вот оригинальное (слегка перекошенное) изображение:

Это происходит независимо от того, является ли оригинал черным или белым на переднем плане и более суровым в областях, которые больше смещены. В этот момент у меня возникает соблазн просто сделать так, чтобы iOS выполняла рендеринг, чтобы я не использовал Leptonica для этой конкретной операции, но это увеличивает количество конверсий в моем рабочем процессе, которых я бы предпочел избежать, если это возможно.

Кто-нибудь еще сталкивался / преодолевал эту проблему раньше? Любые указатели на то, почему это происходит / как это исправить?

Answer 1

Вы можете использовать функцию pixEndianByteSwap(pixbw); для решения этой проблемы.

Answer 2

Я подумал об этом с точки зрения обработки изображений и понял, что, вероятно, допустил ошибку при чтении данных в Лептонику, а не в том, что Лептоника был здесь виновником, и, как оказалось, я был прав.

Пиксельное расстояние для этого глюка составляло 4, и, как оказалось, Leptonica считывает данные словами, обрабатывая из MSB / MSb в LSB / LSb, что приводит к конфликту между способом, которым CGContext записывает данные, и тем, как Leptonica читает их,Это не такая большая проблема, если вы считываете данные в Leptonica как rgba, потому что как только вы переводите их в оттенки серого или в черно-белый режим, ошибка в основном исчезает (за счет некоторого динамического диапазона), но так как я читал данныев 8-битном оттенке серого ошибка не исчезла, а вместо этого проявлялась, как вы видите выше.

В системах с прямым порядком байтов данные должны быть разделены на слова, а порядок байтов должен быть обращен в формуразумное изображение из CGContext, в системах Big-Endian, никаких изменений не требуется.Я бы предпочел найти способ сделать так, чтобы CGContext сделал это для меня, но сейчас я исправлю это трудным путем.