dng metadata tag
Added by D Anderson over 5 years ago
Hi!
Just recently started testing exiv2 out and learnt how to work with set/add/delete command. This speeds up things considerably when using "set" on in some cases thousands of files.I compare this to perl based exiftool and I do my work on mac os X. My workflow atm is to grab metadata information from a dng file by using the exiv2 -pt command. However not all tags are showing. Inside the dng file there is a Frame Rate and Timecode tag which I also like to be able to grab from the file and then copy recursively to around a thousand of dng files. I don,t know why they are not showing? Could it be because those two tags was inserted in the dng file with exiftool? Or is the tag not included in the specs somehow? For now I,ve been using a series of tags and adding them like this. $matx_01, $matx_02 and $wib being my variables grabbed through terminal command line. Would be nice to be able to add Frame Rate and Timecode data as well. Included a file for checking.
exiv2 -M"set Exif.Image.ColorMatrix1 SRational $matx_01" -M"set Exif.Image.ColorMatrix2 SRational $matx_02" -M"set Exif.Image.AsShotNeutral Rational $wib" -M"set Exif.Image.UniqueCameraModel Ascii Canon EOS 5D Mark III"
Replies (23)
RE: dng metadata tag - Added by Alan Pater over 5 years ago
The FrameRate and TimeCodes tags are not yet included in exiv2.
According to exiftool, your sample file includes TimeCodes Tag 0xc763 and FrameRate Tag 0xc764.
Please open an New Issue here requesting that these tags and any others that you notice missing be added.
RE: dng metadata tag - Added by Alan Pater over 5 years ago
As a note, these tags appear to be included in the CinemaDNG spec.
RE: dng metadata tag - Added by D Anderson over 5 years ago
Thanks Alan. Just created an issue report.
RE: dng metadata tag - Added by D Anderson over 5 years ago
Yes, you,re right, cdng. Could there be a conflict with regular dng files? From my testing files open fine in programs like acr and Davinci Resolve.
RE: dng metadata tag - Added by Robin Mills over 5 years ago
RE: dng metadata tag - Added by D Anderson over 5 years ago
Now I,m trying to build a static version of Robin Mills changes by running some different commands
Trying to follow some different steps
http://dev.exiv2.org/projects/exiv2/wiki/How_do_I_build_Exiv2_on_the_XYZ_platform
Last attempt was this command
make config cd exiv2-0.25 make clean ; make config ; ./configure --enable-static --disable-shared ; make
I always end up with this. Something with my clang version on mac OS X El Capitan. It it ain,t too much trouble maybe I could get a static version uploaded or a hint to where the solution to my problem would be?
Thanks.
ld: can't write output file: ../bin/exiv2 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [exiv2] Error 1 make: *** [all] Error 2
RE: dng metadata tag - Added by Robin Mills over 5 years ago
I've reproduced this. I'm rather surprised and will have to investigate this evening. I can't remember the last time I built static on the Mac. The build server builds dynamic libraries, so you can't collect it from there.
I think this might be caused by the linker attempting to link a static/i386 version of a dependant library. For the dynamic library, we link:
502 rmills@rmillsmbp:~ $ otool -L $(which exiv2) /usr/local/bin/exiv2: /usr/local/lib/libexiv2.14.dylib (compatibility version 15.0.0, current version 15.0.0) /usr/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) /usr/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) 503 rmills@rmillsmbp:~ $I've rebuild and installed static versions of expat and zlib.
861 rmills@rmillsmbp:/usr $ find . -name "*.a" 2>/dev/null | grep -e libz -e expat ./local/lib/libexpat.a ./local/lib/libz.a 862 rmills@rmillsmbp:/usr $ find . -name "*.a" 2>/dev/null | grep -e libz -e expat | xargs lipo -info input file ./local/lib/libexpat.a is not a fat file input file ./local/lib/libz.a is not a fat file Non-fat file: ./local/lib/libexpat.a is architecture: x86_64 Non-fat file: ./local/lib/libz.a is architecture: x86_64 863 rmills@rmillsmbp:/usr $I've rebuilt exiv2 without nls support to avoid depending on libiconv and libintl. And still, it doesn't link.
./configure --enable-static --disable-shared --disable-nls --without-libiconvI don't have any more time at the moment (it's 09:56 in England). I'll investigate this evening. Perhaps there's a linker switch you can specify (with LDFLAGS=) to give you more information.
RE: dng metadata tag - Added by D Anderson over 5 years ago
I got it to work after some investigation. The solution was already to be found here. Great documentation and script solutions.
http://clanmills.com/exiv2/clang.shtml
Solution creating a universal binary. So it seems anyway. Hopefully It doesn,t start searching for some dylib down the road :).
cd exiv2-0.25 make clean ; make config ./configure --disable-shared --enable-static CC=clang CXX=clang++ make
RE: dng metadata tag - Added by Robin Mills over 5 years ago
Ah, I never read my own documentation! Glad that's fixed. In v0.27, I'd add building static libraries to the build server's repertoire.
RE: dng metadata tag - Added by Robin Mills over 5 years ago
This is all rather odd. Your command-line failed for me AND now I can build with $ sudo make distclean ; make config ; ./configure --enable-static --disable-shared ; make -j
The good news is that it builds AND passes the test suite.
You don't need to worry about searching for dependent dynamic libraries! I attach my script depends which will find the dynamic library binding stack. You're good, there's nothing suspicious in the brew.
The command $ otool -L executable
shows the dependencies of an executable. I've build bin/exiv2 (static) and bin/.libs/exiv2 (dynamic).
887 rmills@rmillsmbp:~/gnu/exiv2/ttt $ ls -alt bin/exiv2 bin/.libs/exiv2 -rwxr-xr-x+ 1 rmills staff 2757204 26 Apr 20:19 bin/exiv2 -rwxr-xr-x+ 1 rmills staff 218356 26 Apr 20:17 bin/.libs/exiv2 888 rmills@rmillsmbp:~/gnu/exiv2/ttt $Here's the output of tool -L on them:
888 rmills@rmillsmbp:~/gnu/exiv2/ttt $ otool -L bin/exiv2 bin/exiv2: /usr/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) 889 rmills@rmillsmbp:~/gnu/exiv2/ttt $ otool -L bin/.libs/exiv2 bin/.libs/exiv2: /usr/local/lib/libexiv2.14.dylib (compatibility version 15.0.0, current version 15.0.0) /usr/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) 890 rmills@rmillsmbp:~/gnu/exiv2/ttt $As you can see, the principal difference is that bin/.libs/exiv2 requires libexiv2.14.dylib. When you run depends, it runs otool -L on every dependency recursively. It uses tsort to resolve the bind stack. Voila:
890 rmills@rmillsmbp:~/gnu/exiv2/ttt $ ~/bin/macosx/depends bin/.libs/exiv2 /usr/lib/system/libsystem_kernel.dylib /usr/lib/system/libdyld.dylib /usr/lib/system/libxpc.dylib /usr/lib/system/libsystem_pthread.dylib /usr/lib/system/libsystem_c.dylib /usr/lib/system/libsystem_platform.dylib /usr/lib/system/libsystem_blocks.dylib /usr/lib/system/libsystem_malloc.dylib /usr/lib/system/libsystem_asl.dylib /usr/lib/system/libsystem_sandbox.dylib /usr/lib/system/libcompiler_rt.dylib /usr/lib/libSystem.B.dylib /usr/lib/libDiagnosticMessagesClient.dylib /usr/lib/libc++.1.dylib /usr/lib/libauto.dylib /usr/lib/libobjc.A.dylib /usr/lib/system/libunwind.dylib /usr/lib/system/libdispatch.dylib /usr/lib/system/libmacho.dylib /usr/lib/system/libkeymgr.dylib /usr/lib/system/libsystem_info.dylib /usr/lib/system/libsystem_notify.dylib /usr/lib/system/libsystem_trace.dylib /usr/lib/system/liblaunch.dylib /usr/lib/system/libcommonCrypto.dylib /usr/lib/system/libcorecrypto.dylib /usr/lib/system/libsystem_network.dylib /usr/lib/system/libsystem_configuration.dylib /usr/lib/system/libsystem_coretls.dylib /usr/lib/system/libsystem_networkextension.dylib /usr/lib/system/libsystem_m.dylib /usr/lib/system/libsystem_dnssd.dylib /usr/lib/system/libsystem_secinit.dylib /usr/lib/libc++abi.dylib /usr/lib/system/libquarantine.dylib /usr/lib/system/libsystem_coreservices.dylib /usr/lib/system/libremovefile.dylib /usr/lib/system/libcache.dylib /usr/lib/system/libunc.dylib /usr/lib/system/libcopyfile.dylib /usr/lib/libz.1.dylib /usr/lib/libicucore.A.dylib /usr/lib/libiconv.2.dylib /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation /usr/local/lib/libintl.8.dylib /usr/local/lib/libz.1.dylib /usr/local/lib/libexpat.1.dylib /usr/local/lib/libexiv2.14.dylib /Users/rmills/gnu/exiv2/ttt/bin/.libs/exiv2 891 rmills@rmillsmbp:~/gnu/exiv2/ttt $As you can see, it's only at the top of the stack (libintl.8.dylib and later) that you enter the domain of non-system libraries. Notice the stack includes /usr/lib/libz.1.dylib (required by system libraries) and /usr/local/libz.1.dylib required by libexiv2.14.dylib. If depends works well for you and you find it useful, then be assured that I wrote this one morning when I was bored. If it crashes miserably and doesn't work, then I've no idea who wrote it!
At the moment, our buildserver's daily build is MSVC:2005/8/10/12/13/15 dynamic 32/64 and Cygwin/Linux/MinGW/MacOS-X: dynamic/64. For v0.27, I'll probably expand that to include some static builds (and perhaps some 32bit Unix builds).
depends.py (2.73 KB) depends.py |
RE: dng metadata tag - Added by D Anderson over 5 years ago
Very nice stuff.
Youre command $ sudo make distclean ; make config ; ./configure --enable-static --disable-shared ; make -j works great here. Produces the same universal build as with the clang command I used. ./configure --disable-shared --enable-static CC=clang CXX=clang++
Didn,t know about the $ otool -L executable. That,s a nice little command.
Just tried it and got these babies in terminal
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
Exiv2 is still considered static although showing dylib dependencies? Just tried another mac and exiv2 seems to work fine and those dependenices were on that machine. Maybe Xcode includes them?
Curious about the bin/.libs/exiv2(dynamic). Why bother with dynamic builds? Faster? This is a noob question. Static seems simplier to work with.
THe purpose of your depends script is to tsort the dependencies in various library folders? For checking stuff or does it affect exiv2 functions?
RE: dng metadata tag - Added by Robin Mills over 5 years ago
When you link dynamic libraries, your executable is much smaller as it doesn't include the library. The library is a shared file. So if you're linking a small application and a single library, static is simple and easy to use. However for larger applications which use many libraries, static is better avoided.
887 rmills@rmillsmbp:~/gnu/exiv2/ttt $ ls -alt bin/exiv2 bin/.libs/exiv2 -rwxr-xr-x+ 1 rmills staff 2757204 26 Apr 20:19 bin/exiv2 -rwxr-xr-x+ 1 rmills staff 218356 26 Apr 20:17 bin/.libs/exiv2 888 rmills@rmillsmbp:~/gnu/exiv2/ttt $In this case you have linked exiv2 into your application, however the exiv2 code links expat, libz, libintl and libiconv dynamically.
Run depends on Safari.
933 rmills@rmillsmbp:~/gnu/exiv2/ttt $ depends /Applications/Safari.app/Contents/MacOS/Safari | wc 274 274 19157 934 rmills@rmillsmbp:~/gnu/exiv2/ttt $274 dynamic libraries. I think Apple like dynamic libraries!
depends has nothing to do with exiv2. It's a general purpose script that I find useful. Another useful tip when debugging dynamic library loading issues is to set the environment string DYLD_PRINT_LIBRARIES when running an executable. See man (1) dyld. This causes the loader to list libraries as they are loaded:
934 rmills@rmillsmbp:~/gnu/exiv2/ttt $ DYLD_PRINT_LIBRARIES=1 exiv2 ~/Downloads/*.dng dyld: loaded: /usr/local/bin/exiv2 dyld: loaded: /usr/local/lib/libexiv2.14.dylib dyld: loaded: /usr/local/lib/libintl.8.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /usr/local/lib/libz.1.dylib dyld: loaded: /usr/lib/libc++.1.dylib dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation ........ dyld: loaded: /usr/lib/libz.1.dylib File name : /Users/rmills/Downloads/M28-1507_1_2016-04-25_0001_C0000_000001.dng ... 935 rmills@rmillsmbp:~/gnu/exiv2/ttt $Anyway, we've wandered off topic into the subject of the dynamic loader on MacOS-X.
I added 3 other CDNG Tags to exiv2 last night. Regrettably, I can't find a file to test those tags. Ssshhhhs. The samples on http://www.cinema-dng.com are hosted by Vimeo and I don't know how to download a streaming link into a file! Anyway, I have added the code for the 3 tags, and if you know how to test them I'd appreciate your help.
It would appear that CDNG is being actively developed and there may be many more tags to be added. If this is so, we need another issue (target = 1.0) to investigate and deal with them.
RE: dng metadata tag - Added by D Anderson over 5 years ago
Thanks for claryfying a thing or two. Dynamic=runtime with some overhead but smaller. Static=Compile time etc, was something I found from watching a youtube vid yesterday :).
Just checked some cdng samples from here
http://nofilmschool.com/2012/08/blackmagic-john-brawley-release-raw-cinema-camera-files-for-download
but couldn,t find the additional tags. Probably not implemented. Wasn,t in metadata when checking with exiftool either. I,ll see if I can find some other samples to verify the tags actually working.
One problem is inconsistency of how cdng and dng specs are used. Different NLE will behave different depending on what they choose to respect in the dng/cdng specs.
note. I might have found a "set" bug regarding the default metadata tag. Or did you choose to make this tag non writable?
issue here
http://dev.exiv2.org/issues/1180
RE: dng metadata tag - Added by D Anderson over 5 years ago
So got the clang complaining again and here was the solution again. For anybody building static builds.
For this to work
cd exiv2-0.25 make clean ; make config ./configure --disable-shared --enable-static CC=clang CXX=clang++ make
Had to add sudo on make. deleted make config as well.
cd exiv2-0.25 make clean ; ./configure --disable-shared --enable-static CC=clang CXX=clang++ sudo make
RE: dng metadata tag - Added by Robin Mills over 5 years ago
Daniel
I think you should put the sudo on
as this will really clean up the system Then regenerate the ./configure script with: $ sudo make distclean
And then configure and build with: $ make config
./configure --disable-shared --enable-static CC=clang CXX=clang++; make -j ; sudo make install ; make -j samples
There is something not right about the build when you move between versions of the library. I suspect we might be reading the include files from /usr/local/include/exiv2 and not <exiv2dir>/include/exiv2. I've noticed that when I have to build v0.23 or v0.24, things are often not OK when I go back to building the trunk. I'll have a sniff into this one day soon.
I hope you're having a nice long weekend. Weather's beautiful in England.
RE: dng metadata tag - Added by Robin Mills over 5 years ago
I've realised what is causing this! The autotools build exiv2 into <exiv2dir>/bin/exiv2. However when building shared, libtool builds the binary into <exiv2dir>/bin/.libs/exiv2 and generates a bash script <exiv2dir>/bin/exiv2 which has some magic with which it knows how to execute bin/.libs/exiv2 without installing it into /usr/local/bin/exiv2 (and uses the library bin/.libs/libexiv2.14.dylib instead of /usr/local/lib/libexiv2.14.dylib).
When you perform a static build, it tries to do an incremental link. When the linker discovers the bash script in bin/exiv2 it correctly says "Not an x86_64 executable". Regrettably, he doesn't report which file, or say "what's this bash script doing here?". I think this is a bug in autotools. For sure, autotools and MacOS-X are not happy bed-fellows. There are also issues with the .lo and .la files. These are more autotools/libtool magic which are getting into conflict with static/shared builds. Grrrrr. What a mess.
The bash script is horrible mistake on MacOS-X. It might work on Linux (although I suspect it has identical issues). The correct solution on MacOS-X is to to build @rpath into the executable's install_name table. This is exactly what the CMake build does:
1041 rmills@rmillsmbp:~/gnu/exiv2/ttt/build $ otool -L bin/exiv2 bin/exiv2: @rpath/libexiv2.14.dylib (compatibility version 14.0.0, current version 14.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) 1042 rmills@rmillsmbp:~/gnu/exiv2/ttt/build $And the bash script is totally broken on all platforms from the debugger. Debugging: shared:
bin/.libs/exiv2
static: bin/exiv2
I'm not too sure why your work-around with CC=clang CXX=clang++
works for you. Maybe autotools has hidden magic to clean up <exiv2dir>/bin when you mention the clang monster by name. "Oh, mighty dragon of the Apple build, please weave your magic spells".
I tried updating Makefile and config/Makefile.in to cleanup bin/.libs and .lo and .la files. That totally broke the build, so I haven't submitted that. We'll be discussing this again.
RE: dng metadata tag - Added by D Anderson over 5 years ago
hehe, that,s a lot of philosophy around the static building :). I actually have no idea what makes this work on my mac but it does. Or, at least the functions I need for now. I tested the binary on a friends computer as well so it seems ok. Only caveat is not being able to write "subimage" default scale tag but I used the 2014 build as a workaround for now. Are you sure There isn,t a simple stop for writing subimage tags? I know exiftool doesn,t allow all tags to be written.
Sweden is a showing the best of weather right now. Just got back from photographing a short eared owl which came rather close. Going back tomorrow.
RE: dng metadata tag - Added by Robin Mills over 5 years ago
I thought you were in Sweden. I've been to your beautiful country many times. I worked for a Finnish company for 7 years. My wife and I are planning a trip on my friend's boat to Åland at the end of July. Enjoy your photography and being back at work. Summer's almost here.
I'm not a metadata engineer and didn't write Exiv2. However I've learnt a lot about the structure of image files by adding the option -pS in v0.25 and -pR (on the trunk) and will be in v0.26. This recursively dumps tiff and other image structures. I've just found and fixed a bug in -pR using your file: M28-1507_1_2016-04-27_0001_C0000_000002.dng. r4295. I've attach the output of -pR using r4295. So now I know the source of the data in Exif.SubImage1.xxx.
I've opened a new issue #1182. "Exiv2 is unable to update any Exif.SubImageN.xxx tag such as Exif.SubImage1.DefaultScale in a DNG". If it's easy, I will fix it. I may have to defer it as I have a lot to finish for v0.26 code complete in June.
About the static build
Can you try some little tests for me with the build (preferably on a clean machine)
- Build shared (the default)
- make clean
- build static (don't use your CC=clang magic)
Builds or moans about x86_64?
Delete bin/exiv2 and build again. Builds, moans or what?
Robin
Dumping your DNG with -pR using r4295
There's a recursive TIFF in your file at offset 842.
STRUCTURE OF TIFF FILE (II): /Users/rmills/Downloads/M28-1507_1_2016-04-27_0001_C0000_000002.dng address | tag | type | count | offset | value 10 | 0x00fe NewSubfileType | LONG | 1 | 1 | 1 22 | 0x0100 ImageWidth | LONG | 1 | 128 | 128 34 | 0x0101 ImageLength | LONG | 1 | 96 | 96 46 | 0x0102 BitsPerSample | SHORT | 3 | 470 | 8 8 8 58 | 0x0103 Compression | SHORT | 1 | 1 | 1 70 | 0x0106 PhotometricInterpretation | SHORT | 1 | 2 | 2 82 | 0x010e ImageDescription | ASCII | 1 | 0 | 94 | 0x010f Make | ASCII | 6 | 476 | Canon 106 | 0x0110 Model | ASCII | 8 | 482 | Canikon 118 | 0x0111 StripOffsets | LONG | 1 | 1422 | 1422 130 | 0x0112 Orientation | SHORT | 1 | 1 | 1 142 | 0x0115 SamplesPerPixel | SHORT | 1 | 3 | 3 154 | 0x0116 RowsPerStrip | SHORT | 1 | 96 | 96 166 | 0x0117 StripByteCounts | LONG | 1 | 36864 | 36864 178 | 0x011c PlanarConfiguration | SHORT | 1 | 1 | 1 190 | 0x0131 Software | ASCII | 14 | 490 | Magic Lantern 202 | 0x0132 DateTime | ASCII | 20 | 504 | ................... 214 | 0x013b Artist | ASCII | 1 | 0 | 226 | 0x014a SubIFDs | LONG | 1 | 842 | 842 STRUCTURE OF TIFF FILE (II): /Users/rmills/Downloads/M28-1507_1_2016-04-27_0001_C0000_000002.dng address | tag | type | count | offset | value 844 | 0x00fe NewSubfileType | LONG | 1 | 0 | 0 856 | 0x0100 ImageWidth | LONG | 1 | 1600 | 1600 868 | 0x0101 ImageLength | LONG | 1 | 540 | 540 880 | 0x0102 BitsPerSample | SHORT | 1 | 14 | 14 892 | 0x0103 Compression | SHORT | 1 | 1 | 1 904 | 0x0106 PhotometricInterpretation | SHORT | 1 | 32803 | 32803 916 | 0x0111 StripOffsets | LONG | 1 | 38286 | 38286 928 | 0x0115 SamplesPerPixel | SHORT | 1 | 1 | 1 940 | 0x0116 RowsPerStrip | SHORT | 1 | 540 | 540 952 | 0x0117 StripByteCounts | LONG | 1 | 1515520 | 1515520 964 | 0x011a XResolution | RATIONAL | 1 | 1100 | 1100/0 976 | 0x011b YResolution | RATIONAL | 1 | 1108 | 1108/0 988 | 0x011c PlanarConfiguration | SHORT | 1 | 1 | 1 1000 | 0x0128 ResolutionUnit | SHORT | 1 | 2 | 2 1012 | 0x828d CFARepeatPatternDim | SHORT | 2 | 131074 | 2 2 1024 | 0x828e CFAPattern | BYTE | 4 | 33620224 | .... 1036 | 0xc61a BlackLevel | LONG | 1 | 2047 | 2047 1048 | 0xc61d WhiteLevel | LONG | 1 | 15000 | 15000 1060 | 0xc61f DefaultCropOrigin | LONG | 2 | 1116 | 0 0 1072 | 0xc620 DefaultCropSize | LONG | 2 | 1124 | 1600 540 1084 | 0xc68d ActiveArea | LONG | 4 | 1132 | 0 0 540 1600 END /Users/rmills/Downloads/M28-1507_1_2016-04-27_0001_C0000_000002.dng 238 | 0x8298 Copyright | ASCII | 1 | 0 | 250 | 0x8769 ExifTag | LONG | 1 | 1148 | 1148 STRUCTURE OF TIFF FILE (II): /Users/rmills/Downloads/M28-1507_1_2016-04-27_0001_C0000_000002.dng address | tag | type | count | offset | value 1150 | 0x829a ExposureTime | RATIONAL | 1 | 1346 | 1346/0 1162 | 0x829d FNumber | RATIONAL | 1 | 1354 | 1354/0 1174 | 0x8822 ExposureProgram | SHORT | 1 | 0 | 0 1186 | 0x8827 ISOSpeedRatings | SHORT | 1 | 0 | 0 1198 | 0x9000 ExifVersion | UNDEFINED | 4 | 825373232 | 0221 1210 | 0x9003 DateTimeOriginal | ASCII | 20 | 1362 | ................... 1222 | 0x9201 ShutterSpeedValue | SRATIONAL | 1 | 1382 | 1382/0 1234 | 0x9202 ApertureValue | RATIONAL | 1 | 1390 | 1390/0 1246 | 0x9204 ExposureBiasValue | SRATIONAL | 1 | 1398 | 1398/0 1258 | 0x9205 MaxApertureValue | RATIONAL | 1 | 1406 | 1406/0 1270 | 0x9207 MeteringMode | SHORT | 1 | 0 | 0 1282 | 0x9209 Flash | SHORT | 1 | 0 | 0 1294 | 0x920a FocalLength | RATIONAL | 1 | 1414 | 1414/0 1306 | 0x9290 SubSecTime | ASCII | 4 | 0 | ... 1318 | 0x9291 SubSecTimeOriginal | ASCII | 4 | 0 | ... 1330 | 0xa405 FocalLengthIn35mmFilm | SHORT | 1 | 0 | 0 END /Users/rmills/Downloads/M28-1507_1_2016-04-27_0001_C0000_000002.dng 262 | 0x9216 TIFFEPStandardID | BYTE | 4 | 1 | ... 274 | 0xc612 DNGVersion | BYTE | 4 | 257 | ... 286 | 0xc613 DNGBackwardVersion | BYTE | 4 | 257 | ... 298 | 0xc614 UniqueCameraModel | ASCII | 22 | 524 | Canon EOS 5D Mark III 310 | 0xc61e DefaultScale | RATIONAL | 2 | 546 | 10/0 9/0 322 | 0xc61e DefaultScale | RATIONAL | 2 | 562 | 5/0 4/0 334 | 0xc61e DefaultScale | RATIONAL | 2 | 578 | 1/0 2/0 346 | 0xc61e DefaultScale | RATIONAL | 2 | 594 | 1/0 1/0 358 | 0xc621 ColorMatrix1 | SRATIONAL | 9 | 610 | 3617/0 5000/0 64123/65535 10000/0 65533/65535 ... 370 | 0xc622 ColorMatrix2 | SRATIONAL | 9 | 682 | 3361/0 5000/0 65409/65535 2000/0 64573/65535 ... 382 | 0xc627 AnalogBalance | RATIONAL | 3 | 754 | 1/0 1/0 1/0 394 | 0xc628 AsShotNeutral | RATIONAL | 3 | 778 | 7681/0 13200/0 1/0 406 | 0xc62a BaselineExposure | SRATIONAL | 1 | 802 | 802/0 418 | 0xc62b BaselineNoise | RATIONAL | 1 | 810 | 810/0 430 | 0xc62c BaselineSharpness | RATIONAL | 1 | 818 | 818/0 442 | 0xc62e LinearResponseLimit | RATIONAL | 1 | 826 | 826/0 454 | 0xc764 FrameRate | SRATIONAL | 1 | 834 | 834/0 END /Users/rmills/Downloads/M28-1507_1_2016-04-27_0001_C0000_000002.dng
1091 rmills@rmillsmbp:~/gnu/exiv2/ttt $ exiv2 -pa --grep Subimage/i ~/Downloads/M28-1507_1_2016-04-27_0001_C0000_000002.dng Exif.SubImage1.NewSubfileType Long 1 Primary image Exif.SubImage1.ImageWidth Long 1 1600 Exif.SubImage1.ImageLength Long 1 540 Exif.SubImage1.BitsPerSample Short 1 14 Exif.SubImage1.Compression Short 1 Uncompressed Exif.SubImage1.PhotometricInterpretation Short 1 Color Filter Array Exif.SubImage1.StripOffsets Long 1 38286 Exif.SubImage1.SamplesPerPixel Short 1 1 Exif.SubImage1.RowsPerStrip Short 1 540 Exif.SubImage1.StripByteCounts Long 1 1515520 Exif.SubImage1.XResolution Rational 1 180 Exif.SubImage1.YResolution Rational 1 180 Exif.SubImage1.PlanarConfiguration Short 1 1 Exif.SubImage1.ResolutionUnit Short 1 inch Exif.SubImage1.CFARepeatPatternDim Short 2 2 2 Exif.SubImage1.CFAPattern Byte 4 0 1 1 2 Exif.SubImage1.BlackLevel Long 1 2047 Exif.SubImage1.WhiteLevel Long 1 15000 Exif.SubImage1.DefaultCropOrigin Long 2 0 0 Exif.SubImage1.DefaultCropSize Long 2 1600 540 Exif.SubImage1.ActiveArea Long 4 0 0 540 1600 1092 rmills@rmillsmbp:~/gnu/exiv2/ttt $
RE: dng metadata tag - Added by D Anderson over 5 years ago
Well now everything seems to work as it,s supposed to. All kinds of goodies in the bin folder and no complaining. I attached the terminal output(attached .txt files) from compiling as you described. Downloaded a fresh exiv2-0.25 build and started out like this.
cd exiv2-0.25 sudo make distclean make config ./configure --disable-shared --enable-static ; make -j ; sudo make install ; make -j samples
I then ran the same command again after erasing all files from bin folder and it recreated all files without complaining.
Please check the attached .txt files for further troubleshooting.
See you guys in Åland then ;). I actually never been to Åland. Been to Öland and Gotland but never Åland.
Terminal output.txt (61.8 KB) Terminal output.txt | First run on a clean download | ||
Terminal output_make_clean.txt (66.6 KB) Terminal output_make_clean.txt | Second run |
RE: dng metadata tag - Added by Robin Mills over 5 years ago
Thanks for doing this. Looks like a happy result. There is code in Makefile (and config/Makefile.in) to remove bin. Something wrong. I'll investigate.
I looked at the code for SubImage1. Andreas made major changes concerning sub images last year. Maybe it worked before those changes. I'll investigate. Gotta get on with house building today.
Our Finnish friend Veli-Veikko keeps his boat in Parainen and we've sailed in the Archipelago about 6 times with him. We only went twice while we lived in Silicon Valley for 14 years. We're planning to go boating/boozing with him week beginning July 30. You can get the ferry from Kapellskar (or Stockholm) to Mariehamn. It's beautiful in Åland. http://clanmills.com/2002/Finland/
RE: dng metadata tag - Added by D Anderson over 5 years ago
There is code in Makefile (and config/Makefile.in) to remove bin. Something wrong. I'll investigate.
You,re right. Don,t know why I emptied bin folder manually. Everything seems in order. Bin is erased as well. Sorry