kamadak / exif-rs Goto Github PK

if read_from_container(&mut bufreader) is called sometime after the read_to_end() has been called on the same File, read_from_container() will always fail with error InvalidFormat("Unknown image format")

The mitigation is to place the read_from_container() before the read_to_end() and to try_clone() the File when passing its reader to the read_from_container().

I have only tested this on Windows 10. All versions 0.5.x and 0.4 seem to be affected. I have not tested on earlier versions of the library.

I am unsure if this behavior is known, but it should be documented as the operation fails otherwise silently aside from the aforementioned error which is incorrect; the data on disk is not corrupt, just the handle.

I am packaging the kamadak-exif crate for Fedora and we have a requirement to ship license files. Please add a separate license file to git (named LICENSE or similar). Thanks!

Hi! I'm trying the sample code to output the EXIF metadata for all images in a directory:

for entry in std::fs::read_dir(root).unwrap() {
    let file = std::fs::File::open(entry.unwrap().path()).unwrap();
    println!("File: {:?}", file);
    let mut bufreader = std::io::BufReader::new(&file);
    let exif = exif::Reader::new().read_from_container(&mut bufreader).unwrap();
    for f in exif.fields() {
        println!("{} {} {}",
                f.tag, f.ifd_num, f.display_value().with_unit(&exif));
    }
}

But the call to read_from_container is failing for all images I throw at it, e.g. jpeg, png. These are files that are confirmed to have EXIF metadata through identify -verbose <filename>

The error I'm seeing is:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotFound("JPEG")', src/main.rs:19:80

Any idea what I'm doing wrong?

Hi, thank you so much for making this library.

I'm new to Rust and find that it's quite hard to use this library. Basically I would like to get some basic info from an JPG image like: width, height, datetime taken, resolution, ...

Could you please include a simple code snippet that demonstrate how to get those data from an image's exif?

exif-rs tells me "Truncated IFD count" when reading exif data for this file, exiftool is fine and does not complain.

Looks like github includes the original image, to be on the safe side, image sha1 is d43813088933be5b76f99905521abaa35e9c52d7.

Is reading of IPTC and/or xmp tags on the horizon?

Trying to read exif data from a Canon CR2 file and get this error:

    InvalidFormat(
        "Unexpected next IFD"
    )

Here is an example CR2 file: https://www.imaging-resource.com/PRODS/canon-1dx/E1DXINBI000050.CR2.HTM

I'm using kamadak-exif = "0.3.0"

Steps to replicate:

1. Put a CR2 file in /tmp/E1DXINBI000050.CR2
2. add kamadak-exif = "0.3.0" to Cargo.toml
3. run cargo run

Here is some code to replicate the error:

extern crate exif;

use std::fs::File;
use std::io::BufReader;

use exif::*;

fn main() {
    let reader = File::open("/tmp/E1DXINBI000050.CR2")
        .map(BufReader::new)
        .map(|mut r| Reader::new(&mut r))
        .unwrap();

    // Output the error
    if reader.is_err() {
        println!("{:#?}", reader.err());
        panic!("fail");
    }   
    let reader = reader.unwrap();
    let field = reader.get_field(Tag::DateTime, false).unwrap();

    if let Value::Ascii(ref vec) = field.value {
        let date = DateTime::from_ascii(vec[0]).unwrap();
        println!("{:#?}", date);
    }  
}

Update: let me know if you need any more info or if there is something else I can do to help with this.
I don't have a direct understanding of the EXIF format to try to solve this my self

Tried this with a Nikon NEF file and that works fine so it's only the Canon CR2 format so far

According to #12, support for EXIF data in WebP files can probably be accomplished using img-parts (which seems to have some partial support for WebP files) and kamadak-exif for parsing the raw Exif block. Are you interested in supporting this format natively as well?

I forked rexif to add support for writing GPS tags to it, but upstream hasn't been touched in over a year, the only tests it has are the ones I've added, and I've had to spend time improving the implementation. On the other hand, this library seems to have come on leaps and bounds since I last saw it, and I'm wondering if I should maybe switch my efforts.

Do you plan on adding write support, and if not, would you be interested in a pull request adding it?

seems like Reader type doesn't hold anything
i would like to see functions without &self requirements

Thanks for your library!

I do have a problem with the following image

The following code panics with the error:
thread 'main' panicked at 'called Result::unwrap()on anErr value: NotFound("JPEG")', src/main.rs:19:63

fn main() {
    let img = File::open("./Lüftung2.jpg").unwrap();
    let mut bufreader = BufReader::new(&img);
    let exifreader = exif::Reader::new();
    let exif = exifreader.read_from_container(&mut bufreader).unwrap();
}

Unfortunately, I don't know anything about JPEGs and if the image is malformed or if it is a bug. But I am happy to help if there are any questions.

Here is the output of ImageMagick and exiftool:

➜  image-test git:(master) ✗ identify -verbose Lüftung2.jpg 
Image:
  Filename: Lüftung2.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Mime type: image/jpeg
  Class: DirectClass
  Geometry: 960x1280+0+0
  Resolution: 72x72
  Print size: 13.3333x17.7778
  Units: PixelsPerInch
  Colorspace: sRGB
  Type: TrueColor
  Base type: Undefined
  Endianness: Undefined
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
  Channel statistics:
    Pixels: 1228800
    Red:
      min: 36  (0.141176)
      max: 255 (1)
      mean: 155.556 (0.610025)
      standard deviation: 50.0169 (0.196145)
      kurtosis: -1.58156
      skewness: -0.497433
      entropy: 0.755686
    Green:
      min: 32  (0.12549)
      max: 255 (1)
      mean: 152.572 (0.598321)
      standard deviation: 54.5694 (0.213998)
      kurtosis: -1.58949
      skewness: -0.498145
      entropy: 0.757643
    Blue:
      min: 28  (0.109804)
      max: 255 (1)
      mean: 148.58 (0.582668)
      standard deviation: 58.4767 (0.22932)
      kurtosis: -1.60867
      skewness: -0.48949
      entropy: 0.765525
  Image statistics:
    Overall:
      min: 28  (0.109804)
      max: 255 (1)
      mean: 152.236 (0.597005)
      standard deviation: 54.3543 (0.213154)
      kurtosis: -1.54607
      skewness: -0.515057
      entropy: 0.759618
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Background color: white
  Border color: srgb(223,223,223)
  Matte color: grey74
  Transparent color: black
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 960x1280+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: JPEG
  Quality: 90
  Orientation: Undefined
  Properties:
    date:create: 2023-02-06T16:22:51+00:00
    date:modify: 2023-02-06T16:15:45+00:00
    jpeg:colorspace: 2
    jpeg:sampling-factor: 2x2,1x1,1x1
    signature: ae7bf3b446d5765574b619e147fb764e092b47ebc8de29b09e34ee8168aa721e
  Artifacts:
    filename: Lüftung2.jpg
    verbose: true
  Tainted: False
  Filesize: 84886B
  Number pixels: 1228800
  Pixels per second: 87.8001MB
  User time: 0.010u
  Elapsed time: 0:01.013
  Version: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

➜  image-test git:(master) ✗ exiftool Lüftung2.jpg 
ExifTool Version Number         : 12.40
File Name                       : Lüftung2.jpg
Directory                       : .
File Size                       : 83 KiB
File Modification Date/Time     : 2023:02:06 17:15:45+01:00
File Access Date/Time           : 2023:02:06 17:22:51+01:00
File Inode Change Date/Time     : 2023:02:06 17:22:51+01:00
File Permissions                : -rw-rw-r--
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Resolution Unit                 : inches
X Resolution                    : 72
Y Resolution                    : 72
Image Width                     : 960
Image Height                    : 1280
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Image Size                      : 960x1280
Megapixels                      : 1.2

I've noticed that floating point values are sometimes represented with unnecessarily high precision. I think DisplayValue should either cap the precision to a fixed value or there should be a method on DisplayValue to do so.

Here you can find the image which produces this issue.
https://dvbkeaxv2fqwj.cloudfront.net/images/DSC06403.jpeg

read_raw(&self, data: Vec<u8>) should be taking a reference, eg: data: &[u8]. Is there any reason not to do so here?

Are there any plans to support reading exif from PNG files (supported since PNG 1.2)? If you are interested, I might be even be able to contribute a PR.

Crates.io lists kamadak-exif as version 0.4.0, and points to this repository. Here, the version number is 0.3.1. Has the master repository moved, or is it just a forgotten push?

Hi @kamadak thanks for the library just wondering whether this library will get maintenace updates and happy for the people use it as last release was over a year ago whether that matters considering the library doesn't have much deps to go with ?

I'm currently dealing with some vendor-specific maker notes.

Is that within the scope of this project?

I know GIF and PNG don't support pure Exif but they do support metadata fields of some sort. I'm wondering if this library supports that or is planning to support it.

HEIF is the default one for photos taken with iOS since version 11.

Targeting jhspetersson/fselect#65

First of, I know this issue isn't strictly related to this repository. But this is the first BSD library I am using, so want to make sure I do it correctly.

I am new to rust, and am building a CLI program to help sort images based on date. I want to distribute it as a compiled binary.

Is there a recommended way to "reproduce" the copyright notice? The 2nd clause states:

2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

The simplest way I can think of is to store it in a str literal, and then some CLI flag to print it. But wondering if there might be a recommended / better way

After searching for the tag corresponding to the camera's ISO, the exiftool source has some enlightening comments about the PhotographicSensitivity tag:

https://github.com/exiftool/exiftool/blob/74dbab1d2766d6422bb05b033ac6634bf8d1f582/lib/Image/ExifTool/Exif.pm#L1942-L1952

(Data from my own camera(s) seems to back this up). In light of that, would it be possible to add a doc comment to indicate that Tag::PhotographicSensitivity is actually just ISO? -- the name chosen in the EXIF 2.3 spec is not very intuitive.

I'm happy to submit a PR myself, just wanted to check whether it was something you'd be in favor of.

There are several different ways this method can fail.

This return a Result with an enum that implements the Error trait that captures the failure mode and returns it to the end user.

After upgrading my exif dependency to 1.5.1 from 0.3.1, photos that used to be parsed successfully are now generating errors saying "Invalid TIFF Byte Order" when my program calls read_raw. I've used the linux exif CLI tool on my test photo and it does not show any errors on the same file. I can find a way to share the file if that would be useful.

I have a JPEG image generated by a FLIR camera:

I traced through this library and it looks like the child IFD for Tag::GPSInfoIFDPointer has a next_ifd_offset of -1 (i.e. 0xFF_FF_FF_FF) instead of 0, which causes this library to fail with InvalidFormat("Unexpected next IFD").

The file is able to be parsed using exiftool. I traced through its Perl code and it seems like exiftool only parses the next IFD if the tag is known to have a next IFD. So maybe it's safe to just ignore the next IFD offset for child IFDs instead of validating the offset? That would allow this library to read EXIF metadata from files like this one. What do you think?

Hello, I've taken a look in the docs of the exif::experimental::Writer module and I didn't find any method to change the metadata of an image. The only example that I've seen in docs is this one at the top of the page:
Example kadamak-exit writer

But this code only encodes the metadata in bytes, there's not any example adding this metadata to an image.

Is there any method to do this or the crate was discontinued? Thanks in advance for any answer.

Library incorrectly reads content of Orientation tag from some images taken with Samsung Galaxy S7(I don't know if it's relevant to other cameras).
Following two images have taken in landscape and portrait. But library always return "0" for Orientation tag value.

Other software like exiftool or shotwell viewer is able to detect difference.

exif-rs gives me Truncated field value while exiftool is fine reading the image.

The image sha1 is 62e07a2e8c76cb6fb5e5cff70526b1e382eae423