Orientation in IIQ Files
Added by Robert Bieber over 3 years ago
libexiv2 doesn't currently seem to support the orientation tag in IIQ files, or at least not ones from the Leaf Credo digital backs. The exiv2 command-line tool doesn't show anything for Exif.Image.Orientation, and in Darktable on import the images from this camera don't automatically adjust to the correct orientation.
So I guess first question would be if the core devs would have any interest in taking this up as a feature request? I do have RAW files for the Credo 40 up on raw.pixls.us, but I realize that mine is a pretty niche use case and I can definitely understand if it's not exactly a top priority.
If it's not, my other question is how much effort do you think it would be for a software engineer with no prior experience with exif interpretation (and scant little experience with RAW files in general) to come up with a patch to add support? It seems that the functionality already exists in exiftool, so there's some open-source code I can look at that does what I want to do, but I'm not sure how much of a learning curve it would be for me to get up to speed with the project in general
Replies (5)
RE: Orientation in IIQ Files - Added by Robin Mills over 3 years ago
The quickest way to fix this is to assign this to a member of Team Exiv2. Please attach a test file and I'll have a look at it today. It's probably an easy fix for somebody familiar with the code and the architecture of metadata. If your file is larger than the Redmine limit of 20mb, please share the file on Google/DropBox/OneDrive and I will copy it to our test files on our buildserver.
RE: Orientation in IIQ Files - Added by Robert Bieber over 3 years ago
Appreciate it, thanks. Here's a link to one of the samples I have up currently: https://raw.pixls.us/getfile.php/1972/nice/Leaf%20-%20Credo%2040%20-%20IIQ%20L%20(4:3).IIQ
Let me know if you need one in vertical orientation as well, I can dig one up if necessary.
RE: Orientation in IIQ Files - Added by Robin Mills over 3 years ago
Thanks. The news isn't good. I'm using the current 'master' in development:
562 rmills@rmillsmbp:~/Downloads $ exiv2 Leaf\ -\ Credo\ 40\ -\ IIQ\ L\ \(4_3\).IIQ.tiff Exiv2 exception in print action for file Leaf - Credo 40 - IIQ L (4_3).IIQ.tiff: tiff directory length is too large 563 rmills@rmillsmbp:~/Downloads $When I debug your file (with the -pR feature added in v0.26):
539 rmills@rmillsmbp:~/Downloads $ exiv2 -pR Leaf\ -\ Credo\ 40\ -\ IIQ\ L\ \(4_3\).IIQ.tiff STRUCTURE OF TIFF FILE (II): Leaf - Credo 40 - IIQ L (4_3).IIQ.tiff address | tag | type | count | offset | value 35074798 | 0x00fe NewSubfileType | LONG | 1 | | 0 35074810 | 0x0100 ImageWidth | SHORT | 1 | | 608 35074822 | 0x0101 ImageLength | SHORT | 1 | | 456 35074834 | 0x0102 BitsPerSample | SHORT | 3 | 35075216 | 8 8 8 35074846 | 0x0103 Compression | SHORT | 1 | | 1 35074858 | 0x0106 PhotometricInterpretation | SHORT | 1 | | 2 35074870 | 0x010e ImageDescription | ASCII | 14 | 35075222 | HyperFocal: 0 35074882 | 0x010f Make | ASCII | 5 | 35075236 | Leaf 35074894 | 0x0110 Model | ASCII | 9 | 35075241 | Credo 40 35074906 | 0x0111 StripOffsets | LONG | 1 | | 34145708 35074918 | 0x0115 SamplesPerPixel | SHORT | 1 | | 3 35074930 | 0x0116 RowsPerStrip | LONG | 1 | | 456 35074942 | 0x0117 StripByteCounts | LONG | 1 | | 831744 35074954 | 0x011a XResolution | RATIONAL | 1 | 35075250 | 4096/12 35074966 | 0x011b YResolution | RATIONAL | 1 | 35075258 | 4096/12 35074978 | 0x011c PlanarConfiguration | SHORT | 1 | | 1 35074990 | 0x0128 ResolutionUnit | SHORT | 1 | | 2 35075002 | 0x02bc XMLPacket | ASCII | 16384 | 35075266 | <?xpacket begin='' id='W5M0MpCeh ... 35075014 | 0x8298 Copyright | ASCII | 1 | | 35075026 | 0x8769 ExifTag | LONG | 1 | | 35091650 STRUCTURE OF TIFF FILE (II): Leaf - Credo 40 - IIQ L (4_3).IIQ.tiff address | tag | type | count | offset | value 35091652 | 0x4746 Rating | SHORT | 1 | | 0 35091664 | 0x829a ExposureTime | RATIONAL | 1 | 35091896 | 4000/1000000 35091676 | 0x829d FNumber | RATIONAL | 1 | 35091904 | 350/100 35091688 | 0x8822 ExposureProgram | SHORT | 1 | | 1 35091700 | 0x8827 ISOSpeedRatings | SHORT | 1 | | 100 35091712 | 0x9000 ExifVersion | UNDEFINED | 4 | | 0220 35091724 | 0x9003 DateTimeOriginal | ASCII | 20 | 35091912 | 2017:11:26 17:00:30 35091736 | 0x9004 DateTimeDigitized | ASCII | 20 | 35091932 | 2017:11:26 17:00:30 35091748 | 0x9102 CompressedBitsPerPixel | RATIONAL | 1 | 35091952 | 3/1 35091760 | 0x9201 ShutterSpeedValue | SRATIONAL | 1 | 35091960 | 796578/100000 35091772 | 0x9202 ApertureValue | RATIONAL | 1 | 35091968 | 36147/10000 35091784 | 0x9204 ExposureBiasValue | SRATIONAL | 1 | 35091976 | 0/1000 35091796 | 0x9208 LightSource | SHORT | 1 | | 255 35091808 | 0x920a FocalLength | RATIONAL | 1 | 35091984 | 800/10 35091820 | 0x927c MakerNote | UNDEFINED | 34145700 | 8 | IIIICwaR........................ ... Exiv2 exception in print action for file Leaf - Credo 40 - IIQ L (4_3).IIQ.tiff: tiff directory length is too large 540 rmills@rmillsmbp:~/Downloads $You can see that we threw an exception at the MakeNote. It's 34,145,700 bytes. Almost the whole file!
563 rmills@rmillsmbp:~/Downloads $ ls -alt Leaf\ -\ Credo\ 40\ -\ IIQ\ L\ \(4_3\).IIQ.tiff -rw-r--r--@ 1 rmills staff 35092025 8 Apr 07:47 Leaf - Credo 40 - IIQ L (4_3).IIQ.tiff 564 rmills@rmillsmbp:~/Downloads $I see that v0.25 reports some metadata without an exception. The exception 'tiff directory length is too large' was added last year (in v0.26, I think) and is set at 500. I've changed that (locally) to 5000 without success. I increased it to 50000 and got the exception:
invalid type value detected in Image::printIFDStructure: 30531My judgement is that we'll have to study this MakerNote and write a decoder. This is major task. No current team member has written a makernote decoder! It's common (I'm currently involved in an investigation of Canon's new .CR3 format) that the manufacturer provides no documentation for their MakerNote and it has to be reverse engineered by the Open Source Community.
Exiv2 is used by many open-source projects including darktable which determines orientation by calling Exiv2.
Can you say something about the genesis of this file type as I've never heard of Leaf/Credo/IIQ. As you've already speculated, Team Exiv2 has limited resources and lots of work-in-progress. Dealing with this file type is unlikely to assigned high priority - unless you persuade us that otherwise! As the marketing people would say "What is the business case for supporting this file type?".
The team is having a meeting at my home in England in May. https://github.com/Exiv2/exiv2/issues/225 The top priority feature for v0.28 is "Improved raw image code and test" http://dev.exiv2.org/news/3
I've opened an issue about this: http://dev.exiv2.org/issues/1342 "Support for IIQ Raw Files" and copied your file to our buildserver for future work. http://exiv2.dyndns.org:8080/userContent/testfiles/1342/
RE: Orientation in IIQ Files - Added by Robert Bieber over 3 years ago
Thanks for looking into it
Can you say something about the genesis of this file type as I've never heard of Leaf/Credo/IIQ
Sure, IIQ is the RAW format for current medium format digital backs manufactured by Phase One and Leaf (Phase One bought Leaf, which is why they have the same RAW format now), as well as older Phase One backs. For current backs that's the Leaf Credo line and the Phase one IQ1 and IQ3 series, and I think there's a whole long list of older Phase One backs that use it. Collectively I'd guess these make up a very significant chunk of the medium format digital backs in use (maybe even a majority? I think Hasselblad is the only real competitor), but of course that's not a huge market. I don't think there's a whole lot of people using a combination of MF digital backs and open source photo tools.
It's common (I'm currently involved in an investigation of Canon's new .CR3 format) that the manufacturer provides no documentation for their MakerNote and it has to be reverse engineered by the Open Source Community.
exiftool seems to be able to show the orientation info now, and latest UFRaw (although not dcraw, I guess they have some enhancements of their own to the RAW decoder) is able to correctly render vertical images, so it looks like there's some OS implementations of this out there. Whether they'll be easy to port over or not I don't know, but if it's not something that's likely to get attention soon I might start digging into it myself whenever I get sufficiently tired of manually rotating my photos in Darktable. It's a pretty minor annoyance, so it probably won't end up that high on my list either ;)
RE: Orientation in IIQ Files - Added by Phil Harvey over 3 years ago
Yes, the PhaseOne IIQ maker notes contain the raw image data, so they are big. But I would guess that the Exiv2 error may be because the maker notes are being interpreted as a standard TIFF format, which they are not. However, the format of these maker notes is known -- see Image::ExifTool::PhaseOne::ProcessPhaseOne() for a code example.
Adding support for these maker notes should be fairly high priority because as Robert said these are some of the most popular medium-format cameras, and have a strong user base of professional photographers.