What all info can be derived out of an image?
-gps data
-tags
-time taken
I am trying to do some data engineering and just wondering what all information I can extract out of an image? Anyone have any ideas on this?
That would depend on the file format.
Some image file formats specify means for storing meta data.
There is no guarantee that this meta data fields are actually used so even if the file format provides meta data the file may contain no useful meta information.
For most image formats, width, height and pixel depth, full stop. Sometimes physical pixel size, though you can doubt the "updatedness".
Tiff and Jpeg have provisions to include innumerable information tags, most of which are optional and some of which can be user-defined (and of course will be unsupported by existing readers).
Image tags are a jungle and are just ignored by most users/implementors. There is no standardization, because there is no need, and any attempt to be "complete" ends-up in ridiculous enumerations.
https://en.wikipedia.org/wiki/Exif#Example
Related
I already did a lot of research and realized that clear information about "How to generate PDF/A-1a" or "...convert to PDF/A-1a" is really rare. I found some information to convert to PDF/A-1a via GhostScript, but I didn't make it to get it working. So, maybe there are some necessary conditions for the data missing in the first place. Conditions like propper metadata of the PDF, structured data for readability by a screen reader, alternative text for pictures, and a declaration of the given language of the text. I need a proper working GhostScript command with the corresponding gs version and the mandatory file conditions to generate or even convert to PDF/A-1a. PDF/A-1b means nothing to me because I'm already able to convert to that.
Thanks for any help.
I am hunting for duplicates in my photo albums, and I stumbled upon some image pairs for which (seemingly) all visual data is the same, all EXIF tags are the same, except this "Interoperability IFD" field. For one image pair I checked it is 4896 and 4908 for the two files.
I'm pretty sure it is the same photo taken, it was just imported twice in different time/ways. What does this tag mean?
This is a byte offset into the Interoperability IFD "table". EXIF can contain several "tables" (list of "IDs" and "values"). Some table items are not actual data, but references to further "tables" (e.g. 0x8769 ExifTag, 0x8825 GPSTag or 0xA005 IopTag). This offset can of course vary depending in which order an implementer chooses to save the exif information and its different "tables".
Since your software seems to simply output this value, it might be safe to assume that it does not follow this offset to read the additional tags inside the Interoperability IFD "table" (tags 0x0001-0x0002 and 0x1000-0x1002).
Source https://www.exiv2.org/tags.html
How to convert image.png or image.bmp to integer array? (do not use any non-standard library)
Please ignore chunks that are not directly related to image data.(IHDR、IEND...etc.)
thank you very much.
SOLVED: I should use binary I/O function in stdio.h to read image file. thanks
If you have to read images into arrays without any image processing libraries you need two things:
You need means to read files in general.
You need to know the internal structure of the file formats you want to read.
So for png refer to https://www.w3.org/TR/2003/REC-PNG-20031110/
This document will tell you where to find the image dimensions, pixel data and other features. It's basically a manual for software developers on how to use this standard format properly.
Some image formats will require additional work like decrompression.
Given a HL7 file which I know that in its TXA segment there's a byte code of an image, how can I extract that image?
I know my question might be blurry, but that's the details I have
EDIT: The TXA segment is as follows:
TXA|1|25^PathologyResultsReport|8^HTML|||||||||||||||||||908^מעבדת^פתולוגיה^^^^^^^^^^^^20110710084900|||PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXN0cmljdC5kdGQiPg0KPGh0bWw+PGhlYWQ+PG1ld...
+PGJyLz48L3RkPjwvdHI+DQo8dHI+PHRkPg0KPC90ZD48L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPjxTb2ZUb3ZOZXdDb2x1bW4gLz48L3RyPjxTb2ZUb3ZOZXdMaW5lIC8+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==|
Thanks in advance
From reading the documentation it appears that images are stored in this form:
OBX||TX|11490-0^^LN||^IM^TIFF^Base64^
SUkqANQAAABXQU5HIFRJRkYgAQC8AAAAVGl0bGU6AEF1dGhvcjoAU3ViamVjdDoAS2V5d29yZHM6~
AENvbW1lbnRzOgAAAFQAaQB0AGwAZQA6AAAAAABBAHUAdABoAG8AcgA6AAAAAABTAHUAYgBqAGUA~
YwB0ADoAAAAAAEsAZQB5AHcAbwByAGQAcwA6AAAAAABDAG8AbQBtAGUAbgB0AHMAOgAAAAAAAAAA~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAP4ABAABAAAAAAAAAAAB~
(681 lines omitted)
1qqQS/cFpaSVeD1QP1/SX1VJfpPSfXr+tIOKrN2aSrB8OHoH1kfz2tnPLpB/6WkksJ0w5G6WKVNe~
vSisJQdhLdQjODpbznVXXDMPdBNhVtBNpOqqtkY60qYoJxQK17cUoS0v4ijYztCapqqYUKmIUJhJ~
sKqoIO2opiqr7lupIMFBBhNQmtOIzG4naS7XsQuDBLFOP/gAgAgAAKMHAACcBgAACRcAALcYAAC4~
EwAA5RoAALQXAADyBAAAnAMAAD8LAADbEQAA5CgAAJtBAABTVQAAOHAAAOyHAAA=|||||||F
This looks like a simple structure, where the image data is base64 encoded and stored as a long stream, you know its an image because it has ^IM and the image type because of ^TIFF
More specifically:
When an image is sent, OBX-2 must contain the value ED which stands for encapsulated data. The components of OBX-5 must be as described below.
The first component, source application, must be null.
Component 2, type of data, must contain IM, indicating image data.
Component 3, data subtype, must contain TIFF
Component 4, encoding, must contain Base64
Base64 encoding of non-structured (standard HL7) data, normally in an OBX (but could be anywhere) is the norm. Older systems may have a 32K or 64K byte limit, and when that happens the data will be spread over multiple segments.
The target system will first have to potentially concatenate multiple segments and then decode the Base64 encoding.
The target system must know what the expected data type is so that it can be properly displayed or further decoded/interpreted.
This would be a great question on our new StackExchange site for IT Healthcare: http://area51.stackexchange.com/proposals/51758/healthcare-it
Is there a good way to see what format an image is, without having to read the entire file into memory?
Obviously this would vary from format to format (I'm particularly interested in TIFF files) but what sort of procedure would be useful to determine what kind of image format a file is without having to read through the entire file?
BONUS: What if the image is a Base64-encoded string? Any reliable way to infer it before decoding it?
Most image file formats have unique bytes at the start. The unix file command looks at the start of the file to see what type of data it contains. See the Wikipedia article on Magic numbers in files and magicdb.org.
Sure there is. Like the others have mentioned, most images start with some sort of 'Magic', which will always translate to some sort of Base64 data. The following are a couple examples:
A Bitmap will start with Qk3
A Jpeg will start with /9j/
A GIF will start with R0l (That's a zero as the second char).
And so on. It's not hard to take the different image types and figure out what they encode to. Just be careful, as some have more than one piece of magic, so you need to account for them in your B64 'translation code'.
Either file on the *nix command-line or reading the initial bytes of the file. Most files come with a unique header in the first few bytes. For example, TIFF's header looks something like this: 0x00000000: 4949 2a00 0800 0000
For more information on the TIFF file format specifically if you'd like to know what those bytes stand for, go here.
TIFFs will begin with either II or MM (Intel byte ordering or Motorolla).
The TIFF 6 specification can be downloaded here and isn't too hard to follow