Exiv2

After r3650 pngimage.cpp compiles with one warning on MSVC.

pngimage.cpp
..\..\src\pngimage.cpp(160): error C2220: warning treated as error - no 'object' file generated
..\..\src\pngimage.cpp(160): warning C4146: unary minus operator applied to unsigned type, result still unsigned


It is rather strange that the first argument of BasicIo::seek is an unsigned type in case of MSVC.

int seek(uint64_t offset, Position pos)


It either maps to _fseeki64 or std::fseek which both take a signed type.

Thanks for finding this Thomas. May I leave you to submit the patch when Andreas gets your SVN account set up. When you submit, you can take a look at Jenkins to see that it builds.

I'm rather doubtful about the FileIO object's ability to handle files > 3GB. It could even struggle with files > 1.5GB. This didn't matter much before the video code arrived. It's one of the matters I'd like the video guys to investigate.

This is an interesting find, Thomas. I thought I had the option set in MSVC to say "treat warnings as errors". Perhaps I relaxed that condition during the integration of webready and did not restor it. I much prefer treating warnings as errors. Better to deal with warnings as soon as they surface.

I don't use that "treat warnings as errors" when I build the supporting libraries (expat, zlib, curl, ssh and openssl). I don't want to modified one line of the library code - so I ignore library build warnings.

You're welcome to raise an issue report about this and we can deal with it when you're done with the MemIO stuff, or when I return from vacation.

It indeed should have never worked out for blen != 0. Do you have a test file and exiv2 command line I can check with?

-pX is not implemented correctly when the XMP packet spans multiple segments.

652 rmills@rmillsmbp:~/gnu/exiv2/trunk/test $ exiv2 -pX data/exiv2-bug922.jpg 
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.0-jc003">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about="" 
        xmlns:GFocus="http://ns.google.com/photos/1.0/focus/" 
        xmlns:GImage="http://ns.google.com/photos/1.0/image/" 
        xmlns:GDepth="http://ns.google.com/photos/1.0/depthmap/" 
        xmlns:xmpNote="http://ns.adobe.com/xmp/note/" 
      GFocus:BlurAtInfinity="0.018819768" 
      GFocus:FocalDistance="16.068678" 
      GFocus:FocalPointX="0.4351852" 
      GFocus:FocalPointY="0.39444447" 
      GImage:Mime="image/jpeg" 
      GDepth:Format="RangeInverse" 
      GDepth:Near="10.917767524719238" 
      GDepth:Far="38.58317565917969" 
      GDepth:Mime="image/png" 
      xmpNote:HasExtendedXMP="B9AC266F143C5DB7510D1CBEC51C924A"/>
  </rdf:RDF>
</x:xmpmeta>

B9AC266F143C5DB7510D1CBEC51C924A
... deleted ...
B9AC266F143C5DB7510D1CBEC51C924A
653 rmills@rmillsmbp:~/gnu/exiv2/trunk/test $ 

In researching this, I've discovered that XMP packets can be blank padded to enable applications to modify the XMP in-line. What a good idea! Adobe people are really smart. I'll probably update -pX output to remove trailing blanks.

#3702. Extract Extended XMP (spans more than one 65k segment). Remove blank lines. I still have to implement -dI.

r3744 removed the stripping of blank lines in the XML. It's better not to do this in Exiv2. An external tool such as xmllint can deal with this. -pX extracts the XMP packet "as is" with blank lines.

I have a partially working implementation for -dI, but now taking a break for the rest of the day :)

Thanks, already read the forum posts, right after reading this item from the todo list. Will do, right now i have added a set of function to toggle flag a for the image to tell writeMetaData to disable writing app13_ that way i can call it from the Erase action, problem i have right now is i'm either overwriting or underwriting some data not sure and will require a bit more investigation and tinkering but those two APP13 blocks are gone. Also need to read more on the jpg format to see where i may have messed up. because now i end up with APP2 blocks for the problem file.

That's an interesting approach that I hadn't considered. I was just going to remove the blocks. I intended to binary copy the file leaving out the dead blocks. Can be done "in-line" in printStructure without bothering with readMetadata() or writeMetadata().

There's always more than one way to do things of course - however that was how I intended to deal with it.

I thought about that as well when i first saw what you had already added in but then it dawned on me that this could be useful in the future for other formats in case something similar happens.Its a bit more complex but should provide more flex in future since there will already be a mechanism to forward that info to the write function. Copy pasting all those functions too each file format and renaming them took most of the morning.

Well, if you think that's the way to do this, please do that. If you discover that kpsIptcErase is no longer used, could you totally remove it from the code base:

917 rmills@rmillsmbp:~/gnu/exiv2/trunk $ find . -name "*.?pp" -exec grep -H kpsIptc {} \;
./include/exiv2/image.hpp:                 , kpsIccProfile    , kpsIptcErase
./src/actions.cpp:            rc = printStructure(std::cout,Exiv2::kpsIptcErase);
./src/actions.hpp:          @brief Print image Structure information (used by ctIptcRaw/kpsIptcErase)
./src/jpgimage.cpp:        if ( bPrint || option == kpsXMP || option == kpsIccProfile || option == kpsIptcErase ) {
./src/jpgimage.cpp:                            // and dumping the XMP in a post read operation similar to kpsIptcErase
./src/jpgimage.cpp:                    } else if ( option == kpsIptcErase && std::strcmp(signature,"Photoshop 3.0") == 0 ) {
./src/jpgimage.cpp:        if ( option == kpsIptcErase ) {
./src/webpimage.cpp:        if ( bPrint || option == kpsXMP || option == kpsIccProfile || option == kpsIptcErase ) {
889 rmills@rmillsmbp:~/gnu/exiv2/trunk $ 

Incidentally, there's something similar to be fixed because -iX is removing the MakerNote #1064.

Thank You for getting involved. I'm so exhausted with Exiv2. You are getting the wind back in my sails. Thank You.

I've thought of something else about this. I believe it's a spec violation to have two IPTC blocks in a JPEG (and probably other formats that support IPTC). Simply saying "don't write IPTC", or "don't write JPEG/APP3/PhotoShop" might not be the correct fix. I have in mind that -dI will exterminate IPTC totally from the file. The option -dX exterminates XMP blocks.

And let me explain my thinking which are not tablets of stone. You are welcome to think differently about this.

The origin of printStructure() was work done by Tuan on the webready project. Tuan was a GSoC student. Very clever and able young man. Alison are going on vacation with him in Vietnam in December. He was curious about how the metadata was stored in the files. He added JpegImage::printStructure() and PngImage::printStructure() which he accessed from option --struct in exifprint.cpp. This was so useful, it was made available as exiv2 -pS in v0.25 which also had -pX and TiffImage::printStructure(). For v0.26, I added -pR and support dumping for IPTC blocks. Maybe v0.27 -pR will dump MakerNotes.

Exiv2 has supported for a long time -{i|d|e}tgt where tgt: {a|e|i|x}+. These options operate on the file foo.exv (which is a pure metadata jpg).

I've been thinking to support -{p|d}TGT where TGT: {E|I|X|C|-}+.

This is why -ix and -iX are different. exiv2 -ix foo.abc reads XMP from foo.exv. exiv2 -iX foo.abc reads XML from foo.xml

TGT: -i- means "read from stdin". TGT: -e- means "write to stdout" instead of foo.exv.

I hope you find that this explanation helpful. The essential point I want to make is that I had in mind that -dI would be a file operation that doesn't involve readMetadata() or writeMetadata() and is a file maintenance/repair feature. If I have confused you, just proceed as you think best!

I'm not exactly my married to my idea lol. Definitely gives me stuff to ponder.

Glad i could help it's tough to work on a project mostly solo; i know, i also think i need to reread the jpg specs. I'll be taking a closer look at it in the morning. Vietnam eh, sounds interesting i take it that it's a first time visit there?

It's good to work alone. I get to do what I think is best with little interference. On the other hand, when I'm swamped with too much to do, I get discouraged. Gilles insisting that we do WebP for v0.26 is a good example of interference. The priority is to finish v0.26, not to start new stuff. Anyway, WebP is done and now you're helping me to finish v0.26. So everything's going well.

Item 1 on our bucket list was to do huge things to our house. We're almost done. Item 2 is a "round the world" trip. Tuan comes from Vietnam and lives in Singapore. We'll visit Team Exiv2 members along the way. Christmas and New Year with Australian friends in Melbourne. We'll make our first visit to India, Vietnam, Singapore, NZ and Peru. http://clanmills.com/BucketList.shtml

Indeed, and nice set of places to visit. I had Australia and NZ on my list, maybe thailand as well for S-E Asia.