I've written an AutoHotkey function that I use to get the the size of a image in a file -- bitmap, jpg, etc. My function works plenty fast but I've always wondered if there was a way to do it without loading the entire image into memory. For large image files, it could speed up some tasks considerably.

I stumbled across this stackoverflow post that included a few solutions. Paulo Scardine posted some Python code that looks like the most complete way to do it. He later enhanced and converted his solution to Rust which he published here. I've looked at the Rust code. It's small but there more than a few things in the code that I don't understand.

Expert Challenge

Anyone smarter and more patient than me interesting in converting the Rust code into an AutoHotkey function? I'm sure I've got a few internet or karma point laying around that can be used as payment. Or if you already have some AutoHotkey code to do it, I would love to see it.

I've got GIF and PNG working for the most part. The file formats are fairly straightforward although the conversion to big endian caught me off guard there for a second. I still need to find some files with the older file format to finalize this part.

I'm working on JPG now. I'm making some progress but I'm still having difficulty understanding some of the syntax (more on that later). The Exif function from shajul (thanks jNizM) is helpful but it is limited to working on the Exif file format. Many jpg files don't have Exif tags. Also, the script doesn't work on x64. That's another problem altogether.

This instruction reads from the file and converts some of the data but it doesn't do anything with the results. It's only real purpose is the advance the file pointer. Can anyone tell me with some certainty how many bytes are read here? It's at least 6 bytes but I can't identify the exact value.

I'm not sure if the file system is a reliable source for this information. In your example, I was able to get the function to return some information (was not the right information but it was something) for a jpg file but only if the file had Exif tags. Edit: Now that I think about it, this information is probably only available on NTFS. Something tells me that this wouldn't work on anything else. FAT32, CD, DVD, floppy, etc.

Also, I'm not sure if using a fixed column number is reliable. On my computer, there was some folder name stuff in columns 176 and 178. I was able to find image size stuff in columns 31 and 33. The information was the same for both columns. The format was something like "?3257 x 2246?" where the "?" character is an unprintable character.

I finally got JPEG file format working before I crashed. But who knows what it will look like in the light of day. The JPEG file format will be tough to thoroughly test because the format has changed many (many) times over the years and it supports a large number of tags. This should be fun.

I also got BMP working. I plan to get a few more formats working (TIF, WMF (maybe), and others) before calling it done deal. If anyone is interested in helping me to test it, I will publish a prototype here before I published the function in the Scripts forum.

Thanks very much for working on this interesting project.
Two formats I'd be interested in: jxr/wdp and webp. Hopefully they're simple.
(The svg format is also worth mentioning.)
(There's also icon files: (min/)max size.)

I'd be interested in animated gifs: is animated/frame count.
If you've happened to find any interesting links re. those.

Using your script, are you getting significantly better speeds for non-jpegs? How about jpegs?

I'd be interested in animated gifs: is animated/frame count.
If you've happened to find any interesting links re. those.

I've created a class (adapted from code published by other AHK authors) that uses this information so this is definitely get-able information. The method used is 99%+ reliable. Unfortunately there are a very small number of gifs out there where the frame count does not match the actual number of frames in the file. A problem for another topic.

Using your script, are you getting significantly better speeds for non-jpegs? How about jpegs?

It's too soon the in the development process to identify but I suspect for most files, there won't be much improvement simply because of the way the file system accesses files. The whole purpose of this project is to improve performance so yes, this is definitely on the radar.

I have a function that loads the image as icon, cursor, or bitmap and then uses built-in system functions to identify the image size. I'll still need this function because it would impractical to write code for many things, especially images loaded in modules (Ex: MyStuff.dll).

I finally got the TIFF format working. This format was much more complex than I imagined and finding someone who had written code to extract this information was not easy.

I need your help. The function supports TIFF in the little endian format and big endian format but finding TIFF images stored in the big endian format has proven to be very difficult. If anyone has or knows where I can find TIFF files in the big endian format, please let me know. These would be old TIFF files created on Motorola or IBM chips. Stuff created on old Apple Mac for example. The files will have "MM" in the first two bytes of the file.

Attached is the first pass at the function. I've attached a near-ready-to run script that includes the necessary functions. You will need to make a minor change to point to image files on your computer. Please note that there is still some debug code in the function.

Success or failure, I would like to know about it. Here's the rub, if you have a problem, I can't fix it unless I can get my hands on the image file. If you can't part with it, that's OK but if you can, let me know where I can find it or PM me with a copy. If you request it, I will destroy the image after testing.

OK. The accuracy problem for EMF has been fixed. However, the calculation was adjusted to match GDI+. See the function documentation for more information.

As before, I've attached a near-ready-to run script that includes the necessary functions. You will need to make a minor change to point to image files on your computer.

I have very few EMF and WMF files for testing. Some of the EMF files were generated from other file types just to create more EMF files to test. I fear that my test results for EMF and WMF data is skewed and doesn't really represent what really out there. If you have any EMF and/or WMF files, please include those files in your tests.

I'm also still looking for big endian TIFF files. These would be old TIFF files created on Motorola or IBM chips. Stuff created on an old Mac for example. The files will have "MM" in the first two bytes of the file.

Feedback would be appreciated, especially if you find a problem. Thank you for your assistance.