Run-time error in cStdPicEx2 class

[IliaPreston]

I use the cStdPicEx2 class to display multiple pictures on a form.
But, today it just gave me an error for one specific picture:
Run-time 91: Object variable or With block variable not set

The error happened on this line:

   Set tpicPNG = cStdPicEx.LoadPictureEx(Pic_File_Path)

And the picture that causes this error is this:
http://www.mediafire.com/file/i72v2w...erbed.zip/file

Please note that:

1- I have NOT forgotten to do this in MDIForm_Load:

   Set cStdPicEx = New stdPicEx2

2- My process loops through multiple pictures and shows all of them on the same form.
All pictures are displayed by that same code:

   Set tpicPNG = cStdPicEx.LoadPictureEx(Pic_File_Path)

And all of them (except that one picture) is displayed properly.
It is only that one picture that gives me the run-time error.

Please advise
Thanks.

[LaVolpe]

I happen to be at work. I can take a look tomorrow after I get home and get some sleep.

That error simply means that image failed to load. It could be for a host or reasons. When I look at it, I'll post back with the reason, including if the reason is a bug in the class. On the plus-side, good to know that class works well for you 99% of the time

[LaVolpe]

VB won't open it, Microsoft Paint and Paint32 and Photo viewer won't open it. Even Mozilla won't open it.

Conclusion. Likely one or more JPG tags are written incorrectly. This has nothing to do with the class. If Microsoft won't open the file, and the class relies on MS dlls to read the file, then there is nothing to be done. The logical workaround would be to manually parse the JPG, the class does not manually parse JPGs.

[Steve Grant]

I tried this in Irfanview and it opens fine so I decided to try my Metadata test program.

Out of FreeImage, GDI+, Windows Imaging Component, Windows Image Acquisition and Stretchblt, only FreeImage will display it. FreeImage reports it as a standard jpg!

[LaVolpe]

... in Irfanview and it opens fine... only FreeImage will display it. FreeImage reports it as a standard jpg!

Been over a decade since I looked at Irfanview/FreeImage. It very well may manually parse JPG tags and fix/ignore those that don't matter for displaying purposes. Browsing JPG tags is easy to do. If you are really familiar with each tag's structure and what content is valid or not, then tweaking what can be easily tweaked is not a big deal. The only JPG block I ever wrote code to 'correct' was for a specific case where VB would load the JPG but GDI+ would not. That is not the case here.

[Schmidt]

The image in question is a corrupted one...

FWIW - the preview-version of the orginal image (from one of the "Stock-images"-sites) is here:
https://previews.123rf.com/images/hy...-flowerbed.jpg

And the preview-image under that above link:
- does have the exact same length in bytes as the corrupted one
- but does load without probems - also in the "less tolerant" (as in: "security-conscious") JPG-decoders

So, since the ByteSizes are the same (and for most parts, probably also the contents of the both versions),
one could now make a "binary-diff-analysis", what exactly was changed in the version which did not load in the less tolerant decoders).

Don't have the time (or interest) to do that analysis myself - but perhaps someone else will jump in...

HTH

Olaf

[LaVolpe]

Just a small update. GDI+ actually does load the JPG and reports it as 1300x866 pixels. But it can't display it.

As Olaf mentioned, need to do some sleuthing to figure out what's broken in the image, if it's that important. Good luck.

[Eduardo-]

Only the last byte is changed, the correct one has D9 (217) and the wrong one has 4B (75).

[LaVolpe]

Only the last byte is changed, the correct one has D9 (217) and the wrong one has 4B (75).

And changing that last byte fixes the problem. The last 2 bytes of every JPG image should be: 255 & 217. That is the EOI (end of image) tag. Obviously Microsoft and other image processors are enforcing that specification whereas Irfanview simply doesn't care.

[Schmidt]

Only the last byte is changed, the correct one has D9 (217) and the wrong one has 4B (75).

Ah... thanks for "doing the work, and digging this out"...

Olaf

[IliaPreston]

The image in question is a corrupted one...

FWIW - the preview-version of the orginal image (from one of the "Stock-images"-sites) is here:
https://previews.123rf.com/images/hy...-flowerbed.jpg

......

How did you find the original picture?

Thanks.

[LaVolpe]

Well, your zip file name is: "tulips-fresh-spring-flowers-flowerbed"
If you google that, including the quotes, it's among the first hits and images. Not sure if that's all Olaf did, but it works. And for comparison, one could compare file sizes as Olaf did and even verify the image dimensions.

Also, it is possible and I didn't look, that the link for the website might be embedded in the JPG itself viewable with Windows & other tools that can read JPG metadata or by just getting curious and opening the JPG in Notepad.

[Schmidt]

Well, your zip file name is: "tulips-fresh-spring-flowers-flowerbed"
If you google that, including the quotes, it's among the first hits and images.
Not sure if that's all Olaf did, ...

Yes, that's all I did (though included the 'watermark' "123RF" in addition in my google search-terms).

I've then just opened the FireFox-Graphics-Preview/Info-Popup (via RightClick on the image in question) -
and it showed the image-dimensions and image-size (which were identical to the Zipped-Image).

Olaf