Talk:Exif/Archives/2023

Display links

While trying to reorganize the external links I couldn't quite decide what to do with the ones listed under 'Display'. I mean, most of the programs/libraries listed under 'Extraction' can also display the Exif information. Martin Geisler 23:13, 11 Dec 2004 (UTC)

Seeing as Wikipedia is not an internet directory, we really don't need to have links to every bit of software out there that handles EXIF data. Most of the links should go, IMO. Chuck 17:19, August 24, 2005 (UTC)

Agreed (again ☺). I recommend you delete Manipulation, Extraction, and Display link sections. Barefootguru 20:10, 24 August 2005 (UTC)

Wikimedia wish

Wikimedia could display automatically the EXIF data in the pages for uploaded images.

And soon after the above note, MediaWiki started doing so :-) - David Gerard 20:12, 20 August 2007 (UTC)

Image rotation issue

"Also, be aware that many low-end Microsoft Windows programs rotate the image degrading JPEG quality. If you want to rotate the image without losing image quality look for programs like jpegtran or exiftran."

What does that have to do with EXIF? Should it be in this article at all? Chuck 21:52, August 18, 2005 (UTC)

It has zero relevance and should be removed. Barefootguru 05:26, 19 August 2005 (UTC)

Done. I also rewrote the rest of that section, which, even after deleting the quoted sentences above, was still about twice as long as it needed to be for the information it conveyed. Chuck 17:12, August 24, 2005 (UTC)

Great. I further shortened it! BTW, watch your capitalisation of Exif. While I personally think it should be uppercased, the spec defines it as Exif. Barefootguru 20:10, 24 August 2005 (UTC)

Camera Makernotes

Howdy. I'm the author of a library for decoding Exif data in Java. In practice, the most complex areas of Exif surrounds the variations of non-standardised camera manufacturer makernote data. Is this something that should be documented in Wikipedia? I imagine the content would consist of lists of codes, and discussion about each manufacturer's implementations (e.g. incorrect directory offsets, alternative endianess, etc). If people agree that this sort of reference material belongs here, then please advise upon how I might add it. Some of it would be quite volumous, and I'd expect it belongs on another page. Seeking suggestions! --Drewnoakes 17:28, 16 May 2006 (UTC)

In my opinion, some general discussion along those lines would be appropriate, but an extensive list of details about each individual manufacturer's non-standard implementation might be a bit much. Is there an external site which covers this? Perhaps a general discussion of just a paragraph or two, along with a link to the external page for more details, might be appropriate. Chuck 17:30, 17 May 2006 (UTC)

IMHO a detailed reference wouldn't be bad in a separate article, the same way there're lots of lists/comparisons articles. --Outlyer 15:56, 29 July 2006 (UTC)

I agree that a discussion of this could be useful. I would help to contribute here where I can Boardhead 15:39, 11 September 2006 (UTC) (Phil Harvey, ExifTool author)

If we can find the documentation, detailing manufacturers' individual variations on Exif would be fantastically useful information to provide. I'm not sure it's actually all gathered in one place anywhere else. The individual variations can be infuriating, e.g. Canon's - David Gerard 20:15, 20 August 2007 (UTC)

http://www.exif-search.com/ may be of value for make/model variations. 15:56, 11 November 2013 (UTC) — Preceding unsigned comment added by 174.100.252.179 (talk)

Windows XP damages exif tags

The reference dates back to 2001. Is this assertion still valid?

Answer: Yes the assertion is still valid.

Rotating images in Windows XP still causes metadata damage. Suprisingly the Makernote seems to survive. Other JPEG Application segments are rearranged, but otherwise left intact. The following tags are deleted :

 * Orientation
 * Special Processing (Custom Rendered)
 * Exposure Mode
 * White Balance
 * Auto white balance
 * Digital Zoom Ratio
 * Equivalent Focal Length In 35mm Film
 * Scene Capture Type
 * Gain Control
 * Contrast
 * Saturation
 * Sharpness
 * Subject Distance Range
 * Interoperability IFD

Using the "Properties Summary Tab" of Windows XP does far worse damage - to EXIF, XMP, and Photoshop IRB (including IPTC) metadata. Some metadata will remain intact, some will be modified, some moved to other places, and some deleted altogether. See this forum post for more information

Not true; please read it again. Applying changes with either OK or Apply will damage the Exif data, but simply viewing and canceling the dialog box will not damage the Exif data. jdstroy 05:50, 13 July 2007 (UTC)

I will be deleting the assertion that the corruption of Exif tags by windows XP was fixed in a XP service pack. This assertion is false. I am running XP SP3 and have seen evidence of Exif corruption first hand. When I posted about my observations on the ExifTool forum, the creator of ExifTool(Phil Harvey) did not disagree that my observations were evidence of XP SP3 corrupting Exif tags. I will provide this information as a reference although Im not sure if a forum thread is considered a valid reference. Either way, what I have seems more valid than the unreferenced statement that is there now. Im a long time reader of wikipedia but this is my first time editing. So correct me if I am wrong :) (Odog502 (talk) 03:44, 20 February 2010 (UTC))

Linux Instructions

On Linux, a subset of Exif data can be seen by right clicking the file and selecting properties. Most Linux image viewers would give the full set of Exif data. Under KDE? Gnome? Maybe someone should mention the root library that allows accessing Exif data? --Mdwyer 15:13, 28 June 2006 (UTC)

I use GNOME and it does, just tested KDE and XFCE and don't seem to show info. I'm udpating the article (and also replacing Linux with UNIX). --Outlyer 15:40, 29 July 2006 (UTC)

screenshot

is this gnome under linux? Image:Eog_EXIF.png

it looks like mac, and the caption says: Eye of Gnome Screenshot showing Exif data of an image on a Linux system

--200.55.101.214 00:12, 29 June 2006 (UTC)

If you look closely, It's actually (confusingly) Gnome running with an OS X-lookalike theme. —Xavid 08:46, 5 July 2006 (UTC)

Should we replace it by a screenshot that use a more standard theme for Gnome? I would says yes. -- hub 14:45, 9 September 2006 (UTC)

Image only?

I incidently noticed that EXIF metadatas do not only concern 'image file format used by digital cameras', while testing a small script to rename my camera files by using their EXIF metadata. While batch-working on the files contained in a directory, it attempted to work on an Excel file. Sure enough, I did a 'exiftool blabla.xls', and here came a couple of metadatas, among which a 'MIME Type : image/vnd.fpx'. Is it worth mentioning that in the article, or why not finding a pointer to a HOWTO about taking Excel pics with your average DSLR :-) --Olivier Debre 14:33, 25 August 2006 (UTC)?

Exif is only about images. Actually only about JPEG and TIFF. Unlike XMP. But ExifTool do more that just Exif...., including XMP -- hub 14:46, 9 September 2006 (UTC)

ExifTool is recognizing FlashPix-formatted information in your XLS file. Very interesting, I didn't realize this existed. The EXIF specification actually contains a whole section on FlashPix information, so this could actually be considered EXIF... Boardhead 15:16, 6 February 2007 (UTC)

Rotation, EXIF tags and XMP

I'd like the article to mention that Adobe's XMP is probably the 'new EXIF' and is a vast improvement in every regard. I believe it has an open license.

Also, there's considerable ambiguity about the Exif orientation tags. If you rotate an image some editors add new tags, others revise the existing tags. If there are two sets of tags some editors get confused, others don't. (GraphicConverter (Mac) complains about two tags, but Apple iPhoto seems to create them.)

There's a number of things that XMP does poorly with regard to metadata. It is certainly not an improvement in every regard:

• It is not designed for any kind of binary metadata, hence anything large (such as large tables of settings, authentication hashes, or thumbnails) have to be encoded with something like base64
• The text format is not well suited for small images, since it takes up far more space than the equivalent EXIF metadata. This could also be a problem for JPEG images where the largest allowable segment is 64kb.
• It is still not widely distributed (especially in cameras) and is really only well supported in Adobe products.
• XML is a very complex format, and even though XMP restricts use of some XML features, it is still overly complex. This may not be a problem for large companies with deep pockets, but it is a big problem for individuals or small companies developing small applications. Also, as a result of this complexity, it is easy to generate valid XMP which can not be read by your average utility. Boardhead 13:47, 8 February 2007 (UTC)

The orientation tag in Exif is a problem, as are the thumbnails, as often programs will try to preserve the Exif information by simply copying it to the new image. There is no clear answer to this, as in a simple program, it is much easier to copy the Exif block intact than to parse, change and encode it. In these cases there is the choice of having out of date Exif, or having no Exif info at all. --Ozhiker 11:03, 7 November 2006 (UTC)

Problems section: Possible original research

I tagged this problem as "original research" and "citation needed":

The JPEG and standard TIFF file formats supported by the standard are both limited to 24 bit colour. Many modern cameras can capture significantly more data than this but can only make use of it in a proprietary 'raw' format, hence the Exif standard helps reduce the motivation for camera manufacturers to provide higher colour-depth capabilities.

The rewrite clarifies some details (albeit at the expense of making section longer), but misses the point. The problem wasn't use of "POV" language, but was that the statement was clearly speculation- unattributed and thus possibly original research (i.e. one person's opinion). That was why it was "POV"; not the use of language. I should have made that clearer in my comment; sorry.

I would appreciate references to some reputable voices in the photo industry backing up this speculation. Thank you.

Fourohfour 11:34, 15 November 2006 (UTC)

The Exif standard specifically states that colour depth is always 24 bits.[1] Many modern cameras can capture significantly more data than this (e.g. the Nikon D70 captures 36 bits of colour per pixel). Since Exif/DCF files cannot represent this colour depth, many manufacturers have developed proprietary, non-compatible RAW image formats.

This is what it looks like now. Just stick to the bare facts and leave any speculation out of the article. If there is doubt about the accuracy or verifiability of some information then be bold and remove it. Everything is still in the old revisions, you can't break anything by being bold. It is likely that no one will fix it for you anyway, especially if they need to look for hidden comments in the article. MartinDK 13:07, 26 November 2006 (UTC)

On the contrary, the people they were aimed at (i.e. editors of that section) *will* see them; specifically someone wanting to remove the tags, or misinterpreting the reason they were put there (as happened before).

Although I'm happy with the removal in this case, the "nothing is lost" argument is misleading. The info is still there, but not obvious to anyone not looking for it, and after some time will need reworked to go back into a changed article. Fourohfour 14:03, 27 November 2006 (UTC)

I would agree with that point of view. However, the problem is that usually when articles are tagged nothing really happens. Very few people bother to actually fix the article. There is a huge backlog of pages tagged as one or the other thing. In some cases half the article consists of tags. That's why I think you should just be bold, especially when the original research was so blatant as in this case. MartinDK 08:04, 28 November 2006 (UTC)

I give the original authors, or people who actually care enough, the chance to fix and/or reference these things. Someone normally removes the uncited stuff soon enough anyway, if that doesn't happen. Fourohfour 11:41, 29 November 2006 (UTC)

This is nonsese, of course. The background for raw files has nothing to do with EXIF. And whether the standard provides for more than 24 bits or not, the fact is that all raw formats that I know use EXIF, even if the standard doesn't provide for it. I've removed the statement and a second similar one. Groogle (talk) 07:41, 24 August 2016 (UTC)

exif 2.21

There's a EXIF 2.21 on the canon EOS 350D and 400D. nothing in the article about this newer version. --70.111.218.254 20:08, 25 November 2006 (UTC)

I have a copy of a 2.2.1 draft, but I believe the official 2.2.1 version is under the control of the ISO, and hence not accessible to your average person (unless you can afford it). This is likely the reason why this version is not well distributed. Boardhead 19:58, 24 February 2007 (UTC)

I had a look on http://www.iso.org and found no standards and only one document (ISO Bulletin, Feb 2003 PDF), which just mentions Exif as an influence on the JPEG 2000 metadata structure. Do you have any more detail on the ISO connection, which would mean it's not an unmaintained specification? - David Gerard 20:22, 20 August 2007 (UTC)

I just did some searching, and found that you can purchase the 2.21 specification from the JEITA web site for 3100 yen. Boardhead (talk) 18:07, 9 April 2009 (UTC)

Yes, there's EXIF 2.21 on a lot of newer cameras, like Canon 450D, Canon 1000D, Nikon D700 and so on - at least, according to the 'File formats' row of the table. There is even free viewer handling EXIF 2.21 Hardzsi (talk) 06:51, 30 July 2008 (UTC)

Exif 2.21 is officially out since July 11st 2003 and most any digital camera today adheres to this newer version of the standard. The article should be updated. -- 16:28, 30 December 2008 (UTC) —Preceding unsigned comment added by 84.63.13.155 (talk)

EXIF Capitalization

The article states that "Exif" is the official capitalization on the acronym according to the specs. However, specs for EXIF were translated to English from a Japanese source document, and the specs don't explicitly mention presentation of the acronym. I have a hard time believing that using "Exif" was an intentional departure. Googling "EXIF capitalization" turns up a bunch of open-source code that seems to be standardizing on "Exif", but I couldn't find anything else authoritative. Anyone know more about this? Oasisbob 21:12, 31 December 2006 (UTC)

The JEITA website uses "Exif" even on Japanese pages, so it seems very likely that the Japanese version of the spec uses that capitalization too. In any case, the English translation is an official one, and it uses "Exif" all the way through, so it's clearly intentional. (I don't understand what you mean by an "intentional departure". Departure from what?) --Zundark 16:14, 6 February 2007 (UTC)

While I believe that either Exif or EXIF is acceptable, I think the WikiPedia page should use the same form as the official Exif documentation. However, earlier today the article was changed to "EXIF" throughout. I vote to change it back. Boardhead 20:01, 24 February 2007 (UTC)

Main template added to Exif

I've added the Main template to the Exif section. Though that is not necessarily a child of this article, it is a topic that delves in more detail then this one. David Spalding (☎ ✉ ✍) 17:55, 10 August 2007 (UTC)

You're referring to your edit of Image file formats. Dicklyon 18:16, 10 August 2007 (UTC)

jhead

I added a link to jhead (http://www.sentex.net/~mwandel/jhead/) to the Applications for Editing Exif section. However, it was removed with the comment "revert personal-page link". I'd like to put it back since it is a useful tool for editing Exif data, but wanted to discuss it first. --Ishi Gustaedr 13:36, 4 September 2007 (UTC)

It's generally not a good idea to link to personal pages, and especially not those with software downloads. If the software is useful and credible, link to an independent page that says so. Dicklyon 15:46, 4 September 2007 (UTC)

Makes sense. Would linking to either the freshmeat page at http://freshmeat.net/projects/jhead/ or the Free Software Directory page at http://directory.fsf.org/jhead.html be acceptable? I think you can list yourself in freshmeat so it's not really independent, but it does allow comments and ratings. I'm not sure what the criteria is for being listed in directory.fsf.org. (BTW, the link for ExifTool is to a personal page, although it is a personal page at a university as opposed to a hosting site.) —Preceding unsigned comment added by Ishi Gustaedr (talk • contribs) 16:55, 4 September 2007 (UTC)

Those might be OK. Here's a site with link, description, and review. Dicklyon 17:14, 4 September 2007 (UTC)

Geolocation section

It should be noted that even with a GPS card, the geolocation information will be limited to the location of the camera (lat, long, alt), and not of the image itself. Unless the camera has some fairly accurate sensor for determining azimuth the information is not very useful to the user. Furthermore most consumers don't "see" the world in this geographic framework. —Preceding unsigned comment added by 12.110.112.30 (talk) 14:20, 12 September 2007 (UTC)

Knowing where the camera was when the picture was taken gives the approximate location of the contents of the picture, and allows the possibility of further research to determine the actual location -- a great improvement over having no information on the location. GPS coordinates can be converted to more useful information, such as a map location, automatically by software. -96.233.28.166 (talk) 13:38, 22 June 2009 (UTC)

Expand your mind: What happens if you point the camera upwards and take a night picture of the stars? The GPS information can only be used to narrow down the possible picture location to half the sky -- not really very useful. Boardhead (talk) 16:38, 14 July 2009 (UTC)

I have an Apple 3GS32 iPhone and what my local (Houston, TX, USA) Emergency Operations (911) folk told me when I ran a test back in Spring of '10 after I bought it, was that my model had was Cell Tower triangulation, and not true (e.g. satellite) GPS. I'm not a cell phone geek, so this might be something to check out and verify. For me, when I take photos with my iPhone and run them through Google Locate, they generally come up anywhere from a couple houses to a block or so off. Ranger Jim (talk) 12:41, 22 February 2011 (UTC)Ranger Jim

Merger proposal

Someone has proposed merging Camera filename structure into this article. This makes no sense at all, as it has nothing to do with Exif. --Zundark (talk) 10:38, 25 January 2008 (UTC)

Exactly, and since they didn't bother to start a discussion in support of that idea, I took the liberty to change the proposal to merge into an article on that topic. But I had forgotten to remove the mergefrom tag from Exif; it's gone now. Dicklyon (talk) 17:01, 25 January 2008 (UTC)

Editing EXIF with a Mac?

The article implies that EXIF information can only be viewed on a Mac; is it not possible to edit EXIF values such as Author or Title with a Mac? —Preceding unsigned comment added by Apepper (talk • contribs) 16:14, 19 January 2010 (UTC)

Exif information can be viewed on an computer equipped with suitable software. — Quicksilver^{T @} 18:26, 9 April 2012 (UTC)

Little known security tag

I have removed the comment about the little known security tag. The tag does not encrypt the contents. If the tag is little known, then few are using it so it has little impact. Restore reason sounds as if automatic stripping should be done, but there is no indication that is done. It also assumes that someone who is inept enough to leave the EXIF tags in the photo would know enough to set the security tag. The security tag topic is WP:UNDUE. Glrx (talk) 04:59, 24 January 2013 (UTC)

Supported file formats - what does this mean exactly?

First it gives JPEG DCT, TIFF and WAV as the formats to which Exif applies, and then states that "It is not supported in JPEG 2000, PNG, or GIF."

Does this mean that

1. JPEG DCT, TIFF and WAV are the formats covered in the Exif standard?
2. EXIF is covered in the standards pertaining to these formats?

Clearly it isn't a matter of the formats in which Exif data can be embedded - PNG, for instance, has a chunk system that enables any digitally representable metadata to be stored.

If the answer is 1, a further question worth asking is: Does Exif extend JPEG DCT, TIFF and WAV by providing a means to store metadata in them, or does it make use of a metadata infrastructure that was already present in these file formats? Is an Exif JPEG file still valid as a standard JPEG file? — Smjg (talk) 22:45, 19 December 2013 (UTC)

Indeed, I've just had a brief look at the standard, and it's quite hard to make sense of. In one place it seems to state that it's designed to be backward-compatible with JPEG and TIFF, and elsewhere it describes it as if it's a whole new file format. Or is the point that Exif JPEG is a subset of JPEG, and likewise Exif TIFF is a subset of TIFF, designed for devices to implement instead of going to the expense of having a full JPEG/TIFF decoder, and providing a common format for the otherwise application-specific extension areas present in these formats? Maybe I just need to read it in more detail. But it would be good if we can write something that answers the questions I've posed here, for the benefit of our readers so they don't have to find their way through complicated specs to get at this information. — Smjg (talk) 23:18, 19 December 2013 (UTC)

History of Exif before version 2.1

The article does not mention any Exif versions before 2.1 (1998), although the initial release (which version?) is stated to have been in 1995. Perhaps someone aware of the early history of the Exif standard could add the relevant info to the article. At least I would find that interesting. Thanks. --Matthiaspaul (talk) 16:29, 15 April 2014 (UTC)

Exif Dangers

I think Exif Dangers is a useful and unique link, and does not match any criteria in the list at WP:ELNO. It should be returned to the External links section. Ozusut (talk) 21:29, 22 October 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Exchangeable image file format. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20070928011541/http://blogs.23.nu/disLEXia/stories/5751/ to http://blogs.23.nu/disLEXia/stories/5751

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 04:10, 18 October 2015 (UTC)

Requested move 8 August 2016

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Moved (non-admin closure) — Andy W. (talk · ctb) 18:43, 19 August 2016 (UTC)

---

Exchangeable image file format → Exif – The acronym is the WP:COMMONNAME and it is an unambiguous title, like JPEG. – nyuszika7h (talk) 19:46, 8 August 2016 (UTC)

• Support. The long name is very rarely used (even by the Exif specification itself). --Zundark (talk) 20:08, 8 August 2016 (UTC)
• Support – Exif is the common name and, contrary to the TIFF case, there is no ambiguity with other subjects using this abbreviation. — JFG ^talk 04:51, 19 August 2016 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Citation for lack of time zone support

Under "Problems" the claim is made that EXIF doesn't support time zones, and it has been flagged "citation needed". I disagree: if EXIF supports time zones (I'm pretty sure it doesn't), then there should be a citation. I've removed the flag. Groogle (talk) 07:45, 24 August 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Exif. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://www.webcitation.org/68fwWWiVz?url=http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf to http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:34, 26 September 2017 (UTC)

Problems, Technical section vague; needs clarification

Unusually good article, however, quoting article:

Problems
Technical
The Exif format has a number of drawbacks, mostly relating to its use of legacy file structures.  [list of problems]

"mostly relating to its use of legacy file structures?" Which ones? This implies the problem is now fixed. (?) OK. Since when? What's the divide between legacy and fixed? When (year) are we safe? Or...if not fixed...other appropriate clarification (or examples?) needed. Cheers!
--2602:306:CFCE:1EE0:35E7:576D:803C:9EB8 (talk) 13:24, 30 June 2018 (UTC)Doug Bashford

The "legacy" file structure is TIFF. So it's not fixed (and not fixable, without changing the format completely). --Zundark (talk) 13:44, 30 June 2018 (UTC)

Bummer! Thanks. Shouldn't these problems/explanations be made explicit? Else be removed/reworded in the article?
Doug Bashford — Preceding unsigned comment added by 2602:306:CFCE:1EE0:BCCC:1306:CE70:60 (talk) 14:03, 2 July 2018 (UTC)

Not listed in disadvantages but should be

This needs to be clarified by someone with more technical acumen than I have. Because of ExIf, there are two fundamentally irreconcilable ways to turn a photo that was taken with your camera held sideways. One is by moving the pixels around. The other is by having an ExIf instruction that says "rotate the image upon opening it". When the image is opened in an environment that DOES NOT UNDERSTAND ExIf, the image will be sideways. A friend was seeing his images correctly oriented on his computer, and e-mailing them to friends or putting them on the Internet, where SOME users would report seeing them sideways but other users wouldn't have the issue.

ExIf is the source of this problem.

If I just right-click a photo-file in my Windows file-managing directory (not using any photo-related software application) and instruct a rotation, the pixels move around and any ExIf about orientation is deleted. So what I see is what is really there and I can e-mail it or post it where people whose environments do and don't understand ExIf will all see the same thing. But I am afraid that not all versions of Windows do it this way.

And I've used a computer where ExIf WAS understood, made the mistake of thinking that my pixels were all in the right place because it APPEARED to be that way to my eyes, and e-mailed something that was sideways. This, I think, is an utterly unfair misrepresentation to the user of what's in the file. Are the pixels in the right place or not? Or is something merely CONNING you into believing that the pixels are in the right place because it won't display the photograph until after executing an ExIf instruction to rotate it in such fashion as gulls an innocent victim into BELIEVING (in good faith and from no bad intent, but still contrary to fact) that the pixels are in the right place?74.64.104.99 (talk) 13:21, 15 December 2019 (UTC)Christopher L. Simpson

I've experienced this problem (image displayed as desired in image viewer, but sideways when inserted into a document). You can add it to the article if you like, but really we ought to have a reference (that is, a reliable source saying that it's a problem). --Zundark (talk) 16:55, 15 December 2019 (UTC)