Can be the JPEG loading routine updated to read images with correct rotation using EXIF information?
:S the WHAT!?
Digital cameras saves metadatas inside JPEG files, they are called EXIF. There is a metadata that saves the device's orientation, so the photos will be displayed correctly even if the camera was rotated.
Example: iPhone saves the photos as 2592x1936, no matter if the phone was landscape or portrait when taken it. If the phone was portrait, it saves a metadata saying "rotate 90ยบ the image when displaying it"
When I have time, I will look for it.
I have found a document called "how to read an image exif rotation in VisualBasic" http://www.vb-helper.com/howto_net_read_exif_orientation.html that could help you.
Can you implement it? If not, I will implement my own rotation routine.
Anyway, thanks.
Implementing reading of metadata is simple enough Ampos as I'm sure you're aware. Be it EXIF data or ID1 ID2 tags in mp3's. I was just in the toilet thinking of writing a routine to strip metadata from files or possibly pre-populating it with pre-determined data in a batch file fashion.
Would be handy if we could access meta info from within GLB though and write to it too, but as I say it's simple enough :)
can anyone find info where to get these information from? I have no idea, and the VB code you posted uses some VB library that gains access to that data.
This library any use : http://www.exiv2.org/doc/index.html (http://www.exiv2.org/doc/index.html) ?
The EXIF especification is here http://www.exif.org/specifications.html
I have made a few more research, and the key is:
(hex:)
01 12 00 03 00 00 00 01 00 0X
(01 12 is the orientation tag id, 00 03 is SHORT, 00 00 00 01 is only 1 value and 00 0X de rotation needed (1-nothing, 3-180, 6=90 and 8=-90).
Time and time again you get proven right that it was a bad idea to include jpg support in GLBasic :-)
I have checked 4 files from different cameras (iOS, 2xNikon and Canon)
In all the cases, the 00 0X values are stored in offset 0x36 from the start of the file (the pos +0x36 holds the 00 and +0x37 holds the 0X). In iOS and Nikon it is 00 0X and Canon uses 0X 00. Also noted all other values are big-endian or the hell is called (bytes swaped)
So iOS and Nikon are
01 12 00 03 00 00 00 01 00 0X
and Canon
12 01 03 00 01 00 00 00 0X 00
bastards...
If it safe to do a Rotation=byte(start+0x36)+byte(start+0x37)?
Checked jpeg files saved by photoshop and there was not exif orientation information, so you will have to look for 01 12 00 03 00 00 00 01, if fails, 12 01 03 00 01 00 00 00, and if fail again, ignore rotation.
yikes.
Could you write your own using LOADSPRITEMEM and then check the bytes yourself in the file and rotate the image bytes in the array?
Rotating an image in an array is easy:
FUNCTION Rotate90right%: img%[], out%[], w%, h%
REDIM out%[w*h]
LOCAL src%, dst%
LOCAL line% = dst% + h%-1
FOR y% = 0 to h%-1
dst = line; dec line
for x%=0 to w-1
out[dst] = img[src]; inc src; inc dst, h
next
next
untested, but that should work.