Returning to a subject raised about a year ago - and remembering Eric the (unforgettable) Emu …

I had problems with JPEG files from digital cameras which didn't seem to return the right size info when interrogated by EE's method.

I've since returned to this and find there's nothing much on the web to help with this and resorted to trial & error.

The situation seems to be as follows :-

In bytes 7 to 10 of the record in the EE-type JPEG file has "JFIF" and the procedure works.

In the digital camera file (being a format extended to store lots of info on camera exposure, etc.) one finds "Exif". In this case the size info follows the second occurrance of \FFC0\ rather than the first.

If anyone out there knows or suspects this is wrong or has anything else to add, I'd not be alone in hearing.

Eric's routine fails if the delimiter actually appeared as part of the compressed pixel array as a doublebyte. As jpegs are inherently compressed, there is a bucketload of code required to decompress these adequately to avoid the problem.

I'll take another look at Eric's notes to see if there is a better method. After looking through tens of thousands of bytes of hex, the published routine was the best that Eric could come up with - like you he couldn't find many practical examples of adaptable code on the Internet.

Originally the article was only intended to offer bitmap and gif coordinates (which exist in fields in the header - easier to get to). The *.jpg code was a late addition.

Eric would have only tested the routines on adult sites, and not in a comprehensive fashion, as the library of available scanned emu images are quite limited in number. Eric possibly forgot to add code to avoid the staples.

Don't the ImageMan libraries have a method that can compute this for you?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don

From the Imageman web site one can download the current Imageman help file. It indicates that its capabilities include reading the pixel height and width as well as a capability to zoom and pan.

Given the facilities in OI for graphic images it really surprises me that inbuilt routines haven't been added to OI to do these things as part of OI product development and enhancement. They are so basic to image display which lots of people now want and expect.

Steve

Yes, there's always a danger of hitting freak codes. However, I understand that the size info is in the header with the graphics data afterwards. In which case, is it likely to find \FFC0\ in the header? I and our clients have used the Emu Method for quite a while on non Exif files and I haven't yet met or heard of this problem. We'll see how it goes with Exif looking for the second \FFC0\.

There must be lots of folk out there doing this. What do they do and do they encounter any problems with the Emu Method (whether or not they staple their photos)?

For jpegs, I don't think the dimension data is in the header.

Yeah there are freak codes - and seemingly about a 1 in 65536 chance of landing on the wrong doublebyte and misreading the dimensions.

But I haven't actually examined the statistical likelihood of a mis-read, and it could actually be a lot less, owing to the rare incidence of midnight purple and iridescent green in the condensed palette.

I know for a fact that Eric Emu never owned a camera in his whole life. He wouldn't have had access to non-JFIF format images from cameras at the time that article was written sometime in 1996.

Steve

steve@state-of-the-art.com.au

I agree Richard.

Such functionalty would be a great bonus for inclusion in the OI toolset. I would like to scroll, pan and zoom images too.

We could all spend the time doing this, and never do it properly, but in this day and age such functionality is expected in a development environment.

Maybe the OLE controls in OI 7 can go a long way to doing this, and much more besides. Part of our problem is that in the past with OI we just do stuff and it works, and you can do it in a fraction of the time it takes someone in VB or C to do it. This is great and no real Revelation (or Pick pased) developer would argue.

We have though been limited to access to the real flash stuff of Windows development, and only now with the Tab control, splitter bar, and OLE have the ability to create 'proper' Windows applications.

The problem here is that most of us have little or no exposure to the tricks of the trade, and rely on Revelation to help us out.

This they should do, as all other application development environment providers do, but they have not got the millions of developers and funding for this. So, it will be a slow process, but there is light.

Sorry for the rant and rave

Colin

Thanks, folks.

I've just printed out the Exif file spec from wakwak.com. It looks like gobbledegook but maybe, with a bit of peace and quiet, a ray of light may shine through. I'll also try to get the JFIF spec and ditto.

If this leads anywhere, I'll report here in due course.

Don't apologise, Colin! The whole raison d'etre of something like OI is to take the tech stuff away from the likes of us and enable us to provide our clients with what they want and expect. This now includes good graphics viewing including zoom and pan. This seems much more important than some of the items of seemingly lesser relevance which are appearing in OI.

It seems that in my Exif files I had indeed hit a spurious \FFC0\ which was why it seemed that the Exif had the size after the second such string whereas for JFIF it was after the first.

By a mix of decoding an article from the web and a good deal of trial and error the definitive story seems to be as follows:-

The JPEG starts with \FFD8\ and then a series of :-

\FFxx\ block markers where xx defines the type

\ssss\ being the block size before the next marker

\dddd…..\ being the data

The block size is the size of the block size plus data size - i.e. two bytes more than the data size.

The final end of file marker is \FFD9\

The \FFC0 marker denotes the block containing the image size. It is five bytes long with the image size in bytes 2 to 5. What byte 1 does is a mystery.

My code is therefore as follows …

Open JPEGFileName to FV else return

OSBRead HTxt from FV at 0 Length 50000

If HTxt1,2#\FFD8\ then goto FError;* Must start \FFD8\

HT=HTxt7,4

If HT#'JFIF' and HT#'Exif' then Goto FError;* File type

Pos=3

Loop

Ch=HTxtPos,2

until Ch=\FFD9\

DL=256*seq(HTxtPos+2,1)+seq(HtxtPos+3,1)

until Ch=\FFC0\

Pos+=DL+2

repeat

If Ch=\FFC0\ then

S=HTxtPos+5,4

PDim(2)=256*seq(S1,1)+seq(S2,1)

PDim(1)=256*seq(S3,1)+seq(S4,1)

end else Return '*ERROR*'

Colin,

I see it from a different perspective.

Firstly, Windows programming is all about "black boxes". Basic programs can call third party controls (dll/ocx) to access functionality which is (ultimately) housed in parts of Windows anyway. So one way is to circumvent the third party control and go straight to Windows via the API. All depends on how trustworthy the black box is to use.

In some cases the file formats involved are standards outside Windows. In such cases we either defer to Revelation or we deduce our own interfaces based on some hex-staring and pattern recognition skills.

In this thread we see an example of some generic Basic code (for OI or for AREV) that provided a starting point to get jpg dimensions. Free, compact, and useful in JFIF context only, about 99.9 percent of the time.

And Richard has opened the topic, exchanged some thinking, done some experimentation, and come up with a better solution. In doing so, he's further improved the power of the toolset, then shared the results for everyone to gain benefit from, in the spirit of the original code posted.

If even one quarter of the lurkers here posted code when they *know* they have a solution to a problem raised, it would help. Many take the view that this erodes commercial advantage. It does, in a sense, but it expands the market offering, which stands to provide more benefit to the community in the long term, as it builds the advantage in using the toolset.

When Sprezzatura publish useful code and tips in SENL, then you're seeing the benevolence of the vintage proponents of Revelation produces offering freely of their expertise. This shows enormous largesse. When Carl Pates or Aaron Kaplan or Andrew McAuley sit down over several weekends and put together SENL articles, they are helping everyone here in their unpaid time.

This is hardly cause to be despondent. Quite the opposite.

Good comments Steve.

I am not despondent, and I agree that the forum (due to its contributors) is where all the black boxes have holes put in them so that we can all see in side.

I too offer advice on things that I have made available, such as access to the GDI.DLL for graphics.

It is often the case though, that with pressure, time, or just their own need, Revelation add stuff to the product to make these things available. They are proactive in asking the user base what they want to add, and this is a good sign of forward thinking, to which we are all grateful.

The developers though in many cases have to search and resolve the issues using said black boxes, before Revelation make them available as part of the general toolset.

I am not having a moan, just enjoying a good discussion.

Colin

Not forgetting the inestimable contribution of the Emu ;)

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Well if you look at the new feature list for OI 7.1, there's some seriously powerful functionality being added. And a huge workload of testing for the Development Team and for the Beta Testers.

Then there's the future stuff that has yet to be announced - wait until Vegas in 2005!

One recent example was David Goddard in Australia in October this year wrestling with third party controls (black boxes) for some new functionality (can't say what it was - because it's yet to be announced ).

Mike Ruane and David Goddard, in under 12 hours in a Sydney hotel room, during the International Spectrum Conference, managed to get the functionality working from the native OI32 product *without* using the third party control - simply using Basic+. What started as an idea late one evening became a working reality inside a few hours of testing.

So there is new OI functionality happening *all the time*.

View this thread on the Works forum...