08-07-2003 03:06 PM
08-07-2003 04:41 PM
12-09-2013 07:39 AM
... somewhat late perhaps....
Has this problem been resolved since?
I am using LV 6.1 and WinXP.
The "Read JPEG file" VI is crashing in this same manner. Most of my jpg files do not create this problem, but one third of the jpg files generated by my IP camera ends up with the described error. All jpg files can be viewed without problems with PhotoImpact or Paint or the Windows viewer.
What is wrong with these jpg files (or with the VI)?
Are there newer VIs running with LV 6.1 which can open the jpg files?
Thanks!
12-09-2013 07:52 AM
Hi ff,
LV6.1 is somewhat outdated nowadays...
- You didn't attach one of those problematic JPG files for us to cross-check!
- What happens when you convert those JPGs to BMP or PNG and try to load the converted picture (using the correct function)?
12-09-2013 08:07 AM
Hi GerdW,
thanks for your quick reply, and sorry for bothering all of you with my old LV version.....
Here I attack two files: The original 'Stall_4.jpg' which causes "Read JPEG file" crash, and the re-saved (using PhotoImpact) jpg file (Stall_4_new.jpg") which does not cause trouble.
Any conversion of the problematic file (re-saving as jpg, as well as converting to bmp or png) leads to disappearance of the problem. But I want to handle IP camera pictures automatically using LV, so I cannot convert or re-save them first. LV should be able to treat them in the original version.
Best regards, WA
12-09-2013 08:14 AM
WA,
your attached "Stall_4.jpg" loads and displays properly running LV 2013 32bits on Win7 64bits.
Cameras most often don't pass image data as JPG, as this is a highly condensed (read: reduced) image format. So you want to check what the camera really creates.
If the camera compresses the image directly (some have this feature), most of these provide several options for this (like PNG).
Norbert
12-09-2013 08:30 AM
Sorry for bothering you also with my cheap camera (which does not provide any image file options other than referring to the file name).
However, the jpg file seems to be a jpg file, as no other program has a problem with it. Furthermore, the first post of this thread (2003) described the very same problem. So I suppose something is wrong with the "Read JPEG file" routine built in LV 6.1. The error then depends on some specific of the image file itself. Very similar pictures created by the same camera after minimal time delay may cause or cause not the VI to crash. I do not think that the camera changes compression algorithms randomly from picture to picture.
Well, my above posting here was just made in case anyone knows a solution for this, or a substitute for "Read JPEG file" running in LV 6.1 (which might have been created in the meantime). If this is not the case, it may remain unresolved. Regrettably, I have no possibility to go into the algorithms of the built-in libraries.
Best,
WA
12-09-2013 08:53 AM
Hi ff,
I can confirm that LV2013 loads both JPGs without any problems.
Again my suggestion:
What about substituting the JPG file by BMP or PNG? What about using some 3rd party converter tool to convert your problematic JPG stream? Ever tried tools like ImageMagick?
12-09-2013 09:10 AM
WA,
i would expect the camera to be much more "up-to-date" than LV 6.1. That being said, i would also expect the JPG format to have changed a little over time.
So, essentially my guess is that LV 6.1 reads an old standard of JPG whereas the camera driver saves the image in a newer JPG format. When LV 6.1 tries to read the file, it access "invalid" sections (which were not defined in the old standard) and crashes. Which is, of course, not a nice behavior.....
Norbert
12-09-2013 09:10 AM
Again my suggestion:What about substituting the JPG file by BMP or PNG? What about using some 3rd party converter tool to convert your problematic JPG stream? Ever tried tools like ImageMagick?
Hello GerdW,
I did not fully catch up your idea when first mentioned (because I had a substitution of the critical VI or a LV-based manipulation of the critical image files in mind). An automated, command-line based converter would indeed be suitable for my purposes. This would be a viable workaround! I will try ImageMagick, as you suggested. Thanks!
WA