
Hello, I have an Apache server that serves a large static jpeg file. It originally came from a scanned photo. Most programs display this fine, including Firefox and Chromium that come with the latest Ubuntu. If I look at the file, I can't see any signs of missing regions or other corruption (not including spots from the original scanned image of course). Firefox under windows displays a message that the image cannot be displayed due to errors. Android 2.3.4 running on my Galaxy S2. says "An internal server error occurred. Please try again later." which is nonsense, as the apache log file says the server provided the file without errors. Programs like Gimp, gthumb, and display all seem to load the file ok. Any ideas? -- Brian May <brian@microcomaustralia.com.au>

On Mon, Mar 26, 2012 at 10:27:28AM +1100, Brian May wrote:
Firefox under windows displays a message that the image cannot be displayed due to errors.
Android 2.3.4 running on my Galaxy S2. says "An internal server error occurred. Please try again later." which is nonsense, as the apache log file says the server provided the file without errors.
Programs like Gimp, gthumb, and display all seem to load the file ok.
Any ideas?
it may be that FF on Win and (chromium??) on your Galaxy are less tolerant of minor file format errors. try saving it from gimp, and checking whether FF on Win or your Android tablet can view the new version of the file. craig -- craig sanders <cas@taz.net.au> BOFH excuse #261: The Usenet news is out of date

On Mon, Mar 26, 2012 at 10:27:28AM +1100, Brian May wrote: ...
Most programs display this fine, including Firefox and Chromium that come with the latest Ubuntu. If I look at the file, I can't see any signs of missing regions or other corruption (not including spots from the original scanned image of course).
Firefox under windows displays a message that the image cannot be displayed due to errors.
If you have imagemagick installed, what does identify --verbose suspect.jpg give you? I've had strange occurances with CMYK jpegs (although Firefox should be able to handle that..) Karl

On Mon, Mar 26, 2012, at 10:27 AM, Brian May wrote:
I have an Apache server that serves a large static jpeg file. It originally came from a scanned photo.
Most programs display this fine, including Firefox and Chromium that come with the latest Ubuntu. If I look at the file, I can't see any signs of missing regions or other corruption (not including spots from the original scanned image of course).
Firefox under windows displays a message that the image cannot be displayed due to errors.
Android 2.3.4 running on my Galaxy S2. says "An internal server error occurred. Please try again later." which is nonsense, as the apache log file says the server provided the file without errors.
Programs like Gimp, gthumb, and display all seem to load the file ok.
Any ideas?
Run "jpeginfo -c" on the JPEG file and see if it reports any errors. I have found it to work well on a range of malformed JPEG images. You can get it from http://www.kokkonen.net/tjko/projects.html and there is a package for Ubuntu. Regards Graeme

On 26 March 2012 19:53, Graeme Cross <gcross@fastmail.fm> wrote:
Run "jpeginfo -c" on the JPEG file and see if it reports any errors. I have found it to work well on a range of malformed JPEG images.
Looks fine to me: brian@sys05b:~/Downloads$ jpeginfo -c frank_003.jpg frank_003.jpg 9752 x 9676 24bit JFIF N 5946895 [OK] brian@sys05b:~/Downloads$ identify --verbose frank_003.jpg frank_003.jpg JPEG 9752x9676 9752x9676+0+0 8-bit DirectClass 5.947MB 0.000u 0:00.000 identify: unable to open image `--verbose': @ error/blob.c/OpenBlob/2489. brian@sys05b:~/Downloads$ identify -verbose frank_003.jpg Image: frank_003.jpg Format: JPEG (Joint Photographic Experts Group JFIF format) Class: DirectClass Geometry: 9752x9676+0+0 Resolution: 4800x4800 Print size: 2.03167x2.01583 Units: PixelsPerInch Type: TrueColor Endianess: Undefined Colorspace: RGB Depth: 8-bit Channel depth: red: 8-bit green: 8-bit blue: 8-bit Channel statistics: Red: min: 6 (0.0235294) max: 255 (1) mean: 53.8332 (0.211111) standard deviation: 51.604 (0.202369) kurtosis: 4.55959 skewness: 2.18813 Green: min: 9 (0.0352941) max: 255 (1) mean: 54.671 (0.214396) standard deviation: 51.3301 (0.201294) kurtosis: 4.59683 skewness: 2.19549 Blue: min: 9 (0.0352941) max: 255 (1) mean: 56.3935 (0.221151) standard deviation: 51.058 (0.200228) kurtosis: 4.57194 skewness: 2.19332 Image statistics: Overall: min: 6 (0.0235294) max: 255 (1) mean: 41.2244 (0.161664) standard deviation: 50.4332 (0.197777) kurtosis: 5.44944 skewness: 2.24724 Rendering intent: Undefined Interlace: None Background color: white Border color: rgb(223,223,223) Matte color: grey74 Transparent color: black Compose: Over Page geometry: 9752x9676+0+0 Dispose: Undefined Iterations: 0 Compression: JPEG Quality: 84 Orientation: Undefined Properties: date:create: 2012-03-27T09:28:00+11:00 date:modify: 2012-03-27T09:27:54+11:00 jpeg:colorspace: 2 jpeg:sampling-factor: 2x2,1x1,1x1 signature: 18ba93cddf88717f67bd8157d17a27c2df75b60ff6d055d05c810a60d0a488e9 Artifacts: verbose: true Tainted: False Filesize: 5.947MB Number pixels: 94.36MB Pixels per second: 47.66MB User time: 1.980u Elapsed time: 0:02.979 Version: ImageMagick 6.6.0-4 2011-06-15 Q16 http://www.imagemagick.org -- Brian May <brian@microcomaustralia.com.au>

On Tue, Mar 27, 2012 at 09:32:24AM +1100, Brian May wrote:
On 26 March 2012 19:53, Graeme Cross <gcross@fastmail.fm> wrote:
Run "jpeginfo -c" on the JPEG file and see if it reports any errors. I have found it to work well on a range of malformed JPEG images.
Looks fine to me:
brian@sys05b:~/Downloads$ jpeginfo -c frank_003.jpg frank_003.jpg 9752 x 9676 24bit JFIF N 5946895 [OK]
brian@sys05b:~/Downloads$ identify --verbose frank_003.jpg frank_003.jpg JPEG 9752x9676 9752x9676+0+0 8-bit DirectClass 5.947MB 0.000u 0:00.000 identify: unable to open image `--verbose': @ error/blob.c/OpenBlob/2489.
Whoops. Sorry about that :-)
brian@sys05b:~/Downloads$ identify -verbose frank_003.jpg Image: frank_003.jpg Format: JPEG (Joint Photographic Experts Group JFIF format) Class: DirectClass ...
Looks fine to me too. Very mysterious. Karl

Hi, On 27 March 2012 09:32, Brian May <brian@microcomaustralia.com.au> wrote:
... brian@sys05b:~/Downloads$ identify -verbose frank_003.jpg Image: frank_003.jpg Format: JPEG (Joint Photographic Experts Group JFIF format) Class: DirectClass Geometry: 9752x9676+0+0 ...
Number pixels: 94.36MB
... 94 megapixels is an unusually *large* image. At 3 bytes per pixel (or 4 if any alpha-channel stuff is happening) this would take 283 (or 377) MB of memory to render the image. And then the web browser may make another copy to compose it into a huge page, before downscaling it to fit the viewable window. I'm not surprised that some programs can handle it, but other programs not. John

On 27 March 2012 10:22, John Mann <john.mann@monash.edu> wrote:
And then the web browser may make another copy to compose it into a huge page, before downscaling it to fit the viewable window.
I'm not surprised that some programs can handle it, but other programs not.
Hmm. I didn't think of this aspect. Will have to check how much RAM this Windows XP system has that is failing, my guess is probably not much by modern standards (which always seems to be on the increase). -- Brian May <brian@microcomaustralia.com.au>
participants (5)
-
Brian May
-
Craig Sanders
-
Graeme Cross
-
John Mann
-
Karl Billeter