Loading ...
Sorry, an error occurred while loading the content.

Re: eraseThumbnail broken in svn?

Expand Messages
  • Andreas Huggel
    ... Hi Mike! Yes, quite a lot has changed since 0.17.1. In SVN, we have added TIFF, PNG and JPEG2000 write support. With the TIFF patch, a number of
    Message 1 of 12 , Jul 31, 2008
    View Source
    • 0 Attachment
      > gth-exiv2-utils.cpp:620: error: 'class Exiv2::ExifData' has no member
      > named 'eraseThumbnail'
      > make[3]: *** [gth-exiv2-utils.lo] Error 1
      > make[2]: *** [all-recursive] Error 1
      > make[1]: *** [all-recursive] Error 1
      > make: *** [all] Error 2
      >
      > Has something changed?

      Hi Mike!

      Yes, quite a lot has changed since 0.17.1. In SVN, we have added TIFF,
      PNG and JPEG2000 write support. With the TIFF patch, a number of
      incompatible core-API changes were introduced
      1) for the new TIFF parser itself
      2) for the planned consolidation of metadata containers in a later
      future release (in this category, Exif thumbnail support has been
      moved into its own classes (ExifThumb and ExifThumbC)
      3) for a more stable API and for future Win DLL support (to reduce and
      simplify the API)

      See this thread: http://uk.groups.yahoo.com/group/exiv2/message/1237
      with comments from Gilles (digiKam) and Udi (ufraw) and here:
      http://uk.groups.yahoo.com/group/exiv2/message/1323

      Andreas
    • avtechmjc1
      Ugh... API changes... could you give me a clue as to what code would replace this: image1- exifData().eraseThumbnail(); to purge IFD1 generally? - Mike
      Message 2 of 12 , Aug 1, 2008
      View Source
      • 0 Attachment
        Ugh... API changes... could you give me a clue as to what code would
        replace this:

        image1->exifData().eraseThumbnail();

        to purge IFD1 generally?

        - Mike
      • Andreas Huggel
        ... This is from the exiv2 utility (actions.cpp): int Erase::eraseThumbnail(Exiv2::Image* image) const { Exiv2::ExifThumb exifThumb(image- exifData());
        Message 3 of 12 , Aug 1, 2008
        View Source
        • 0 Attachment
          > Ugh... API changes... could you give me a clue as to what code would
          > replace this:
          >
          > image1->exifData().eraseThumbnail();
          >
          > to purge IFD1 generally?
          >

          This is from the exiv2 utility (actions.cpp):

          int Erase::eraseThumbnail(Exiv2::Image* image) const
          {
          Exiv2::ExifThumb exifThumb(image->exifData());
          std::string thumbExt = exifThumb.extension();
          if (thumbExt.empty()) {
          return 0;
          }
          exifThumb.erase();
          if (Params::instance().verbose_) {
          std::cout << _("Erasing thumbnail data") << std::endl;
          }
          return 0;
          }

          To be honest I don't remember why it checks the extension,
          it doesn't look right now. If you find out, please let me know.

          -ahu.
        • avtechmjc1
          ... Thanks, I was just about to post a never mind reply, after finding that. ... I was wondering about that... Anyway... I m running into a different issue.
          Message 4 of 12 , Aug 1, 2008
          View Source
          • 0 Attachment
            > This is from the exiv2 utility (actions.cpp):

            Thanks, I was just about to post a "never mind" reply, after finding that.

            > To be honest I don't remember why it checks the extension,
            > it doesn't look right now. If you find out, please let me know.

            I was wondering about that...

            Anyway... I'm running into a different issue. My metadata copying code
            isn't working. Is that expected with the new API? I had, roughly:

            Exiv2::Image::AutoPtr image1 = Exiv2::ImageFactory::open (from_file);
            image1->readMetadata();
            Exiv2::ExifData &ed = image1->exifData();

            (tweak ed, inserting updated date, etc)

            Exiv2::Image::AutoPtr image2 = Exiv2::ImageFactory::open (to_file);
            image2->setExifData (image1->exifData());
            image2->writeMetadata();

            Anything obviously wrong here?

            - Mike
          • Andreas Huggel
            ... [...] ... No, this looks perfectly ok. Can you provide some more details or a reproducer for the issue? Andreas
            Message 5 of 12 , Aug 1, 2008
            View Source
            • 0 Attachment
              > Anyway... I'm running into a different issue. My metadata copying code
              > isn't working. Is that expected with the new API?

              [...]

              > Anything obviously wrong here?

              No, this looks perfectly ok. Can you provide some more details or a
              reproducer for the issue?

              Andreas
            • avtechmjc1
              ... Andreas, I never resolved this issue due to a crippling lack of free time, and now 0.18 is here... Could you take a peek at gthumb trunk? When I try to
              Message 6 of 12 , Dec 19, 2008
              View Source
              • 0 Attachment
                --- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
                >
                > > Anyway... I'm running into a different issue. My metadata copying code
                > > isn't working. Is that expected with the new API?
                >
                > [...]
                >
                > > Anything obviously wrong here?
                >
                > No, this looks perfectly ok. Can you provide some more details or a
                > reproducer for the issue?

                Andreas,

                I never resolved this issue due to a crippling lack of free time, and
                now 0.18 is here... Could you take a peek at gthumb trunk? When I try
                to write metadata during certain operations, it fails entirely with
                this message:

                TIFF array element tag 43 has wrong type

                Here's how to reproduce:

                1) Download the test image at
                http://www.avtechpulse.com/downloads/test.jpg

                2) Get gthumb trunk:

                svn co http://svn.gnome.org/svn/gthumb/trunk
                cd trunk
                ./autogen.sh --prefix=/usr CFLAGS="-Wall -ggdb"
                make
                make install
                gthumb

                3) Browse to the folder containing test.jpg. Select test.jpg. If the
                metadata sidebar is not showing, press Ctrl+2. It should show lots of
                metadata.

                4) Press enter to open the image.

                5) Press Alt+c to load the crop screen. Select an area, press "Crop",
                then press "Save".

                6) Click on "Close" to return to the browser view.

                7) The metadata sidebar should show that no metadata is present. The
                console output should show what was supposed to be written, and the
                above-mentioned tiff error.


                The relevant subroutine is here:
                http://svn.gnome.org/viewvc/gthumb/trunk/libgthumb/gth-exiv2-utils.cpp?annotate=2459#l571

                It's the "image2->writeMetadata();" that seems to fail.


                - Mike
              • Andreas Huggel
                Hi Mike, The test image, error message and reference to your code are good starting points. However, from experience, it is more efficient if we do this
                Message 7 of 12 , Dec 19, 2008
                View Source
                • 0 Attachment
                  Hi Mike,

                  The test image, error message and reference to your code are good
                  starting points.

                  However, from experience, it is more efficient if we do this together
                  and I refrain from debugging your application. Can you try this for a
                  start, to check in particular, if the type of tag Exif.CanonCs.0x002b
                  is "Short" before the Exif data is written:

                  In the method that you pointed out, insert code to print the Exif data
                  just after it is read and again, just before it is written, and post
                  that here. Something like this should do the job (from
                  samples/exifprint.cpp):

                  Exiv2::ExifData::const_iterator end = ed.end();
                  for (Exiv2::ExifData::const_iterator i = ed.begin(); i != end; ++i) {
                  std::cout << std::setw(44) << std::setfill(' ') << std::left
                  << i->key() << " "
                  << "0x" << std::setw(4) << std::setfill('0') <<
                  std::right
                  << std::hex << i->tag() << " "
                  << std::setw(9) << std::setfill(' ') << std::left
                  << i->typeName() << " "
                  << std::dec << std::setw(3)
                  << std::setfill(' ') << std::right
                  << i->count() << " "
                  << std::dec << i->value()
                  << "\n";
                  }

                  Andreas
                • avtechmjc1
                  ... Thanks Andreas! Exif.CanonCs.0x002b shows up as Ascii before it is written, not Short . Just so you understand the code, we first read the file and
                  Message 8 of 12 , Dec 19, 2008
                  View Source
                  • 0 Attachment
                    --- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
                    > However, from experience, it is more efficient if we do this together
                    > and I refrain from debugging your application. Can you try this for a
                    > start, to check in particular, if the type of tag Exif.CanonCs.0x002b
                    > is "Short" before the Exif data is written:

                    Thanks Andreas!

                    Exif.CanonCs.0x002b shows up as "Ascii" before it is written, not "Short".

                    Just so you understand the code, we first read the file and store the
                    metadata in a basic name/value string pairs (metadatum->full_name,
                    metadatum->raw_value). Then the image is cropped and saved without
                    metadata. Then we try to re-insert the metadata from the saved
                    name/value pairs.

                    In other words, in this operation, nothing is loaded from
                    image1->exifData(). It comes from the stored name/value string pairs,
                    and we count on exiv2 to automagically handle the typing issues.

                    And it looks like the handling of Exif.CanonCs.0x002b goes wrong.

                    So... what next?

                    - Mike
                  • Andreas Huggel
                    ... Short . Ok. That explains the error that you re seeing. Exif.CanonCs.* tags are stored in an array of unsigned shorts (in the value of
                    Message 9 of 12 , Dec 19, 2008
                    View Source
                    • 0 Attachment
                      > Exif.CanonCs.0x002b shows up as "Ascii" before it is written, not
                      "Short".

                      Ok. That explains the error that you're seeing. Exif.CanonCs.* tags
                      are stored in an array of unsigned shorts (in the value of
                      Exif.Canon.CameraSettings), their type must be "Short".

                      > In other words, in this operation, nothing is loaded from
                      > image1->exifData(). It comes from the stored name/value string pairs,
                      > and we count on exiv2 to automagically handle the typing issues.

                      I'm still working on the magical bits ;) In the meantime, this is what
                      happens in a line like ed["Exif.CanonCs.0x002b"] = std::string(value):

                      1) op[] looks up the tag in ed and creates a new metadatum if it's not
                      there
                      2) op= sets the value. But first, if the metadatum has no value yet, a
                      new empty value is created. The type is taken from Exiv2's tag lookup
                      tables. If the tag is not found in the table, the type defaults to Ascii.

                      So when the tags are set from the stored name/value string in gthumb,
                      I believe this will reset the type of the tag to Exiv2's default type
                      for that tag and if Exiv2 doesn't know the tag, the type will become
                      "Ascii". Usually this happens quietly except for array element tags
                      which need to have a specific type(*).

                      To check if this hypothesis is correct, you could try this: Set an
                      unknown tag in an image (without a Canon makernote) to something other
                      than an Ascii string, process it with gthumb and check the tag
                      afterwards, eg:

                      exiv2 -M"set Exif.Image.0x1234 Long 1234" image.jpg


                      I think it would be better to preserve whatever types the tags in the
                      image already have. I don't see why gthumb should change any tag type.
                      Eg, for some tags the Exif standard allows a choice of types, but
                      Exiv2 defaults to just one of them. There is really no reason to
                      change if the original tag happens to have another valid type.

                      One way to do this would be to store type information together with
                      tag names and values and create a value of that type explicitly
                      instead of letting Exiv2 determine the type. Another way could be to
                      keep the original ExifData (IptcData and XmpData) container instead of
                      converting it to a key/value string pair and build a C interface to
                      access it from other parts of gthumb.

                      > And it looks like the handling of Exif.CanonCs.0x002b goes wrong.

                      (*) One can argue that there is an inconsistency in Exiv2 itself with
                      regards to these array tag types and that they should default to the
                      correct type, since it is known. I'll open a bug for this, but I
                      consider this a detail.
                    • Andreas Huggel
                      ... http://dev.robotbattle.com/bugs/view.php?id=593
                      Message 10 of 12 , Dec 19, 2008
                      View Source
                      • 0 Attachment
                        > (*) One can argue that there is an inconsistency in Exiv2 itself with
                        > regards to these array tag types and that they should default to the
                        > correct type, since it is known. I'll open a bug for this, but I
                        > consider this a detail.

                        http://dev.robotbattle.com/bugs/view.php?id=593
                      • avtechmjc1
                        ... Thanks for all the suggestions, Andreas! I ve patched my code so that the original metadata is copied from a backup of the original file, to preserving
                        Message 11 of 12 , Dec 20, 2008
                        View Source
                        • 0 Attachment
                          > I think it would be better to preserve whatever types the tags in the
                          > image already have. I don't see why gthumb should change any tag type.

                          Thanks for all the suggestions, Andreas!

                          I've patched my code so that the original metadata is copied from a
                          backup of the original file, to preserving typing. The modified
                          metadata is then written from the string pairs. And everyone is happy :-)

                          - Mike
                        Your message has been successfully submitted and would be delivered to recipients shortly.