Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TIF metadata field count #65

Closed
ben-manes opened this issue Jan 9, 2018 · 6 comments
Closed

TIF metadata field count #65

ben-manes opened this issue Jan 9, 2018 · 6 comments
Labels

Comments

@ben-manes
Copy link
Contributor

An integration partner shared this screenshot of warnings. I don't think its blocking, as the issue was regarding increasing our default DPI setting, but thought you should know in case there is an offset mistake somewhere.

image

@dragon66
Copy link
Owner

dragon66 commented Jan 9, 2018

@ben-manes I don't know the details regarding how icafe is used in your case: did you generate tiff with icafe? manipulate it with icafe or other.

The specific tiff field with name DateTime is a ASCII field and the count is expected to be 20 with the format specified by the specification.

When reading the tiff field, icafe will follow the field type and count without any assumption. So if the field for DateTime with a length different than 20, it will read to the length. In this case, if the discrepancy is only for the DateTime field, it will not propagate to other field thus ruin all the other fields.

In your case, if after the DateTime field, the process still can read correct tiff field instead of garbage, it is an indicator that the DateTime field itself is a bit off track and no big deal for the other part of the image, otherwise, something could be wrong with the whole image/the reader.

Hope this explains something.

By the way, I didn't see any part icafe will write this field to the tiff create by it but very probably it will copy the same field to some kind of output image when it is used in other ways than generate tiff itself - like split, merge, etc.

Wen

@ben-manes
Copy link
Contributor Author

I think that you write it in TIFFWriter.java#L487. The image is fine and wasn't a problem.

In our case we have to create multi-page TIFFs for integrations with legacy products that our customers own. Our usage is very simple, but they are finicky given they are often using mainframe or similarly aged products. The source images are downscaled JPEGs that were originally taken on a mobile phone (jpeg), sent as webp to reduce the byte size, transformed (cropped, white balanced, etc) and converted back to jpeg for browser compatibility. Most of those transformations are done using opencv Java bindings. When sending to external systems, they often require TIFFs and we use icafe for that step.

/** Creates a TIFF with a page per image. */
public static void create(TiffSettings settings) {
  try (FileOutputStream fileOutput = new FileOutputStream(settings.destination().toFile());
      RandomAccessOutputStream rout = new FileCacheRandomAccessOutputStream(fileOutput)) {
    BufferedImage[] bufferedImages = new BufferedImage[settings.images().size()];
    for (int i = 0; i < settings.images().size(); i++) {
      bufferedImages[i] = ImageIO.read(settings.images().get(i).toFile());
    }

    TIFFOptions tiffOptions = new TIFFOptions();
    tiffOptions.setTiffCompression(settings.compression());
    tiffOptions.setXResolution(settings.xResolution());
    tiffOptions.setYResolution(settings.yResolution());
    tiffOptions.setJPEGQuality(100);

    ImageParam imageSetting = ImageParam.getBuilder()
        .colorType(settings.colorType())
        .imageOptions(tiffOptions)
        .build();
    TIFFTweaker.writeMultipageTIFF(rout, new ImageParam[] { imageSetting }, bufferedImages);
  } catch (IOException e) {
    throw new UncheckedIOException(e);
  }
}

@AutoValue @AutoBuilder
public static abstract class TiffSettings {
  public abstract Path destination();
  public abstract List<Path> images();
  public abstract Compression compression();
  public abstract ImageColorType colorType();
  public abstract int xResolution();
  public abstract int yResolution();

  public static MultipageTiff_TiffSettings_Builder builder() {
    return MultipageTiff_TiffSettings_Builder.builder()
        .colorType(FULL_COLOR)
        .compression(LZW)
        .xResolution(72)
        .yResolution(72);
  }
}

@dragon66
Copy link
Owner

dragon66 commented Jan 9, 2018

@ben-manes you know icafe more than me now! I vaguely remember wrote that somewhere and did a search this morning but didn't find it!

Interesting. I will take a look at that part and related things to see if I need to enforce something.

Great find. Thank you.

By the way, which part of the application code logged that warning? I guess it's not icafe.

@ben-manes
Copy link
Contributor Author

ben-manes commented Jan 9, 2018 via email

@dragon66
Copy link
Owner

dragon66 commented Jan 9, 2018

I took a look at the DateTime formatting in TIFFWriter and checked with the tag format requirement, looks like I added a time zone there which does make sense but that caused the field length to become 24 instead of 20. I have checked in the fix.

dragon66 pushed a commit that referenced this issue Jan 9, 2018
@dragon66 dragon66 added the bug label Jan 9, 2018
@ben-manes
Copy link
Contributor Author

Thanks a bunch for all your hard work and quick responses on this library :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants