Shut Up Legs
Down Under Member
Yes, I know: another one of those "What xyz did you do today?" threads. Sometimes, though, I feel the need to share what software code I've written recently with other people (and hopefully those who understand what on earth I'm babbling on about will reply with something interesting.
Today, it's reading JPEG metadata:
Yesterday, I was trying to write some code (in a Windows C++ executable) to read just enough of a JPEG image file to get the values of its width and height attributes, i.e. its resolution metadata. The motivation for this is that I'm writing an image-displaying screen saver for Windows, and I wanted to add a feature where the user could filter the images to be displayed by minimum width and/or height in pixels, so that the screen saver doesn't do annoying things such as display tiny little thumbnail images (like the Windows image display screen saver does, and this is one of the reasons I started writing my own).
I'm already using the FreeImage image-processing library to load the images, then OpenGL to display them on the virtual screen saver window canvas, but the main drawback of FreeImage is that to know the resolution of the image, you have to load the entire file, and so I was searching for a way to get the resolution by scanning through as few bytes of the file as possible.
Simple enough, I thought: there's a table somewhere near the start of the file with various parameters stored in it, right? Wrong!
A few JPEG standards later:
JPEG (JFIF): http://www.w3.org/Graphics/JPEG/
JPEG (EXIF): www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
I know a little bit more about where the width and height are stored, but I'm still working on my final solution for JPEGs. Then, I'll have to do the same for a few other commonly-occurring image formats in Windows, e.g. BMP, GIF and PNG.
For some JPEGs, the width and height are available in the SOF0 (Start Of Frame 0) header, and are easily enough read. But for others encoded using the EXIF standard (see below), accessing these 2 values involves reading the EXIF header, following pointers to the offset of other headers, etc. and isn't so straightforward.
One thing I plan to do, though, is look at the source code of FreeImage (and similar libraries), to get hints on what kind of code I need to write for my size-filter. This may speed things up a bit.
As a typical example: I have a roughly 1.5MB JPEG image file for which I was getting incorrect width and height values by just reading the SOF0 header: it was giving me 160x120 instead of the actual 4000x3000 (i.e. it's a 12Mpixel JPEG). So for this one, which happens to be an EXIF-encoded JPEG, I need to use the more complex approach, and hopefully will have to scan through no more than about 2KB or so, before finding the attributes I need.
Once I have the algorithms all worked out, I'll write the size-determining code in a library, then link it into my screen saver executable.
Geeky regards,
--- Victor.
Today, it's reading JPEG metadata:
Yesterday, I was trying to write some code (in a Windows C++ executable) to read just enough of a JPEG image file to get the values of its width and height attributes, i.e. its resolution metadata. The motivation for this is that I'm writing an image-displaying screen saver for Windows, and I wanted to add a feature where the user could filter the images to be displayed by minimum width and/or height in pixels, so that the screen saver doesn't do annoying things such as display tiny little thumbnail images (like the Windows image display screen saver does, and this is one of the reasons I started writing my own).
I'm already using the FreeImage image-processing library to load the images, then OpenGL to display them on the virtual screen saver window canvas, but the main drawback of FreeImage is that to know the resolution of the image, you have to load the entire file, and so I was searching for a way to get the resolution by scanning through as few bytes of the file as possible.
Simple enough, I thought: there's a table somewhere near the start of the file with various parameters stored in it, right? Wrong!
A few JPEG standards later:
JPEG (JFIF): http://www.w3.org/Graphics/JPEG/
JPEG (EXIF): www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
I know a little bit more about where the width and height are stored, but I'm still working on my final solution for JPEGs. Then, I'll have to do the same for a few other commonly-occurring image formats in Windows, e.g. BMP, GIF and PNG.
For some JPEGs, the width and height are available in the SOF0 (Start Of Frame 0) header, and are easily enough read. But for others encoded using the EXIF standard (see below), accessing these 2 values involves reading the EXIF header, following pointers to the offset of other headers, etc. and isn't so straightforward.
One thing I plan to do, though, is look at the source code of FreeImage (and similar libraries), to get hints on what kind of code I need to write for my size-filter. This may speed things up a bit.
As a typical example: I have a roughly 1.5MB JPEG image file for which I was getting incorrect width and height values by just reading the SOF0 header: it was giving me 160x120 instead of the actual 4000x3000 (i.e. it's a 12Mpixel JPEG). So for this one, which happens to be an EXIF-encoded JPEG, I need to use the more complex approach, and hopefully will have to scan through no more than about 2KB or so, before finding the attributes I need.
Once I have the algorithms all worked out, I'll write the size-determining code in a library, then link it into my screen saver executable.
Geeky regards,
--- Victor.