JPEG formats and SpriteExtend

I’ve just had TechWriter fail to display a couple of jpegs with the message that they are a format SpriteExtend can’t support. Can anyone advise if there is a way to fix this without losing any info/details from the image?

The files display with WeCantCallItImageMasterAnyMore and NetSurf. The former of these gives format details that look the same as for example that TechWriter does display. So I don’t know what the difference is.

Jim

The JPEG bounty is concerned with improving SpriteExtend’s support for different JPEG types. You probably want to try the softload version from the bounty thread, and leave some feedback there for whether it does/doesn’t work (the latest update is a bit lacking in feedback so far)

I’ve just tried the new version and it fixed my problem OK. :-)

I’ve said this in the relevant thread. However I noticed the previous message there says something about ‘no bug reporting’. I’m not sure what was meant but maybe that’s why no-one has said anything until now.

Jim

So I don’t know what the difference is.

Most likely “progressive” JPEG. The difference is traditional JPEG encodes line by line while progressive is interleaved, the idea being that a slow modem link could get you seeing a JPEG faster by rendering every ‘n’ lines (and filling in the gaps with copies) and then going back to fill in the copy lines with real image data. This sort of thing mattered when 56K modems were common and getting them to connect much above 33K wasn’t; but now that many people are on broadband, perhaps the utility of progressive JPEG is in allowing the images to fight the plethora of advertising…?

Wiki says: There is also an interlaced progressive JPEG format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data. However, support for progressive JPEGs is not universal.

The default SpriteExtend supports standard JPEG. It doesn’t support progressive. That’ll be the difference, most likely.

Hmm… I’ve looked at ChangeFSI, PhotoDesk, SwiftJPEG, ThatOneThatDavidPillingWrote, and PrivateEye and there’s not a single one of them that tells you what type of JPEG it is dealing with. You get “JPEG” and you might get the colour format and/or channels, but nothing says “Baseline”, “Progressive”, etc. Hmmm…

Chances are your non-working JPEG will look like this using the original SpriteExtend:

>SYS "JPEG_PlotFileScaled", "$.images.snowcrash/jpeg", 0, 0, 0, 0

JPEG format is not supported by this version of the SpriteExtend module
>

or it’ll fail to load and display with SwiftJPEG.

…

Took me a while. Had to search all over for a JPEG that threw an error. Progressive isn’t unheard of, but it isn’t commonplace.

Part of the puzzle for me is that these are from batches of jpegs, all of which I’d created using GIMP. So far as I know, I exported them in the same way every time. yet some were OK, but others not. However maybe I did something different which I’ve now forgotten.

If anyone wants to investigate, the jpegs are all for a demo site I did at

http://jcgl.orpheusweb.co.uk/temp/MoCdemo/allcollections.html

The jpegs for, say, the ‘QUAD R’ and ‘UNI83’ were OK, but those for the ‘Marconi’ and Gecophone’ weren’t, and needed the new version of SpriteExtend.

Jim

If anyone wants to investigate

Using the iMac’s Preview App the Marconi radio and Gecophone jpegs are flagged as “Progressive 1” whereas the Quad Mk1 is not.

Gimp can save as Progressive, it is in Export’s Advanced Options.

HTH.

Jim: Just a thought when you say “all of which I’d created using GIMP” were they all created from scratch in GIMP or where some based on images originally created elsewhere?
Could you have created different types of jpegs in GIMP?
Colour depth, progressive/non progressive…

All the photos were taken using the same camera onto the same SD card. I then transferred the raw images to one of my Linux boxes, and processed the ones I wanted. (Mainly scaled them down and cropped them, with a bit of tweaking to the gamma and sharpness.)

It is quite possible that I did something somehow different. But so far as I recall, I just ‘exported’ each result from GIMP as a jpeg. So if I changed something relevant, I don’t know what I did. Mind you, I do forget a lot these days…

I think it likely that it was something I did differently. Just that I can’t recall what it would have been!

Jim

I think it likely that it was something I did differently.

I wonder if something somewhere might be on auto-pilot! Anyway progressive or not seems be the issue, which “goes away” with the ROOL beta SpriteExtend in that JPEGs of either sort render, in the sense that all JPEGs just render on the Mac or Ubuntu.

The awkward bit is divining what the progressive-ness of a JPEG is. The Mac’s Preview App is very good at metadata. I haven’t found anything similar for Ubuntu yet.

The Ubuntu ‘jpeginfo’ command line tool seems to be able to show this, ‘Identify’ in ImageMagick can do the same and there is a port of that for RISC OS – endless scope here for time wasting.

Wow! Thanks, David. I didn’t realise that ImageMagick had been ported. That’s quite useful info.

Jim