Error Flipping Multiple Images - Error Flipping Multiple Images

I'm getting a return code of 20037 from CreateThumbnailFromFile. What is error 20037? Where is a list of these errors?

Our current error codes don't have this value--are you using a legacy version? Which version of the toolkit are you using?

The closest I could locate to this was -37 in our current documentation, signifying "Invalid Data".
https://www.leadtools.co...in/api/return-codes.html

This indicates the issue may be stemming from the image you're working with. Could you furnish us with that and the code you're using?

WE are using V13. I found a document with error codes for LEADTOOLS ePrint 5 COM methods. It has the 2xxxx errors. Assuming that they are the same as the imaging COM methods the error is

Error No. Description
ERROR_INVALIDDATA 20037 Internal error - call LEAD.

I'm calling. The image opens fine before being flipped. The image along with many other are selected and flipped. The error occurs on one of the images and the applications ends. When restarted the CreateThumbnailFromFile function that properly displayed the image thumbnail before the flip and that failed on the flip now fails when displaying the thumbnail of the image. The image is changed during the flip, originally it was a color jpeg of a BW document that is around 1 mb. After the flip, the image is around 3 mb.

I would have to create a stand-alone app to send the code. That is a last resort. How do I send the image files?

I downloaded the current SDK and ran the MainDemo under Viewers and Displays for .NET, C, and C++, they all failed to open the image that failed on the flip. To be clear the pre-flip image opened fine in all three. The image after the flip failed in all three. The failing image opens in multiple Windows viewers.

.NET Error opening file
C++ Internal error - call Lead
C Leadtools DLL Error (-37)
Internal error - call Lead

How is this file corrupted?

Thank you for including your images. After examining the file it appears some of the resync markers in it are invalid.

Could you furnish us with the code you're using to generate this image? The call to L_SaveBitmap() (or whichever LEADTOOLS function you're using to save the image) may be sufficient.

Are the invalid resync markers only in the "failed" image?
Why isn't Lead able to display this image when various Windows and other utilities can?

Is there a way to detect this problem?
Is there a way to fix the image?

The rough code is below. They are all Leadtools functions. It is version 13 code. Is there a better way? Note that this flow has worked on a very large number of images over many years.

Load( path, 0, 0, 1 );

Rotate( 18000, ROTATE_RESIZE, RGB(0, 0, 255) );

bits = GetBitmapBits()
Save( path, 10, bits, 2, SAVE_OVERWRITE );

CreateThumbnailFromFile( path, 0 );


Subsequent calls to CreateThumbnailFromFile( path, 0 ) fail on the image.


Thanks for your assistance.

These are only present in the "failed" file. One thing I did note is the input file is JPEG YUV 4:1:1 and the damaged output file is JPEG YUV 4:4:4. I'm unsure if this is a contributing factor. Is it possible to save the file to a different format (or the same as the original input) or use L_ResizeBitmap to scale the bitmap in memory down to a thumbnail size after the Rotate operation?

Note later versions of the toolkit do have the ability to partially load files damaged like this one, however, I'm unable to find anything in the v13 documentation stating that may be the case with this version.

The good input file is from the scanner. The failed file is saved using Lead's Save function. How are you detecting the 4:1:1 vs 4:4:4? How could this be saved differently to get a 4:1:1 file?

I examined the documents in the v21 MainDemo (in the "Open" Dialog, highlight the file and select the "File Info" button at the top right, second from the right) which reported the Format as JPEG (YUV 4:4:4).

I see you're passing "10" to your Save() call. Assuming this is the file format, in our documentation this correlates to JPEG File Interchange Format with YUV 4:4:4 color space. Looks like FILE_LEAD1JFIF (21) is YUV 4:1:1. Does the issue persist when modifying your save call?

I modified the code to use the 4:1:1 color space. The error continued. I modified the code to use a different quality setting in the Save so that the file size would remain roughly the same after the flip. That fixed my inhouse problem. At the client site neither change fixed their problem. I've asked them to test the two changes to see of one is better than the other. The client is scanning and displaying a very large number of images each day. A sizable number of those require flipping.

Any additional ideas would be greatly appreciated. Thanks for your help so far.

Modifying the code as such likely changed how the data were saved in the image such that no invalid resync markers were formed. This may not be possible with every image. It may be the case this doesn't occur in a later version of the SDK--regretfully, v13 is out of maintenance.