Ovation Pro/JPEG Info

Hi,

I’ve been told that rotated JPEG files don’t render correctly in Ovation Pro on Beagle. Tests seem to show that JPEG Info is not returning the correct values for the x and y pixels in a JPEG.

This seems unlikely to me, but I wonder if anyone can offer any comments before I produce a demo of the problem.

We’ve already tested this from a four line piece of Basic.

Tests seem to show that JPEG Info is not returning the correct values for the x and y pixels in a JPEG.

From version 1.36 of SpriteExtend the API has been fixed to match the documentation, and the XY size is only returned if bit 0 of R0 is set before calling JPEG_[File]Info. If it isn’t, those two registers are preserved.

Additionally, check for SpriteExtend >= 1.39, which allows DHT markers to appear before SOF markers. You can list the markers using djpeg (inside !ChangeFSI) with the verbose switch on.

We’ve already tested this from a four line piece of Basic.

I can confirm that setting bit 0 in R0 now causes the right dimensions to be returned by your test program.

Hi,

Many thanks. Caught out by the old thing of not setting up correct input values. By the look of it, I originally used JPEG Info where I didn’t need xpix and ypix, setting R0 to 0, and then copied the code somewhere else and just read off the x and y values.

A fixed version of Ovation Pro will appear soon.

By the way, why would I worry about SOF and DHT markers.

Great, thanks! I wonder why turning alignment exceptions off fixes the problem though?

On alignment execeptions… ISTR there was no effect on the Basic demo. So that is not relevant to RISC OS.

From inside OP I’ve not seen the results of the debug/log file, to see if the values change. Might just be luck – if address exceptions change the address of the memory used for the JPEG. However if they do this consistently I might start to worry about why.

Ok, the new !RunImage works fine anyway, thanks very much. If there’s any other testing you need me to do, just ask!

why would I worry about SOF and DHT markers

You shouldn’t ever need to, it was a bug which was introduced in SpriteExtend 1.35 by mistake and fixed in 1.39 after someone found a rare JPEG with the markers in that order.

Nothing to see here, move along folks…