TIFF CCITT T.6 - WRITING - IIOMetadataNode PHOTOMETRIC_INTERPRETATION = WhiteIsZero seems not working.

[agharta]

Hi all,
Writing a tiff metadata many attributes will be applied to output tiff, like TAG_RESOLUTION_UNIT & TAG_X/Y_RESOLUTION....but TAG_PHOTOMETRIC_INTERPRETATION doesn't works!

The output tiff's TAG_PHOTOMETRIC_INTERPRETATION is always Black is Zero!

Try it.

bi = scaleImage(bi, BufferedImage.TYPE_BYTE_BINARY, (int) d.getWidth(), (int) d.getHeight());
TIFFImageWriter writer = getImageWriter();//load tiff writer
TIFFImageWriteParam writeParams = (TIFFImageWriteParam) writer.getDefaultWriteParam();
writeParams.setCompressionMode(TIFFImageWriteParam.MODE_EXPLICIT);
writeParams.setCompressionType("CCITT T.6");
 //set METADATA
IIOMetadata streamMetadata = writer.getDefaultStreamMetadata(writeParams);
ImageTypeSpecifier imageTypeS = ImageTypeSpecifier.createFromRenderedImage(bi);
IIOMetadata imageMetadata = writer.getDefaultImageMetadata(imageTypeS, writeParams);
//
String nativeFormat = "com_sun_media_imageio_plugins_tiff_image_1.0";
IIOMetadataNode customMeta = new IIOMetadataNode(nativeFormat);
IIOMetadataNode ifd = new IIOMetadataNode("TIFFIFD");
customMeta.appendChild(ifd);
createTIFFFieldNode(ifd, TIFF.TAG_PHOTOMETRIC_INTERPRETATION, TIFF.TYPE_SHORT, (short) 0); /*0 = WhiteIsZero, 1 = BlackIsZero*/
imageMetadata.mergeTree(nativeFormat, customMeta);
//
//write output
File fx = new File(toDir + "/" + f.getName());
ImageOutputStream imageOutputStream = ImageIO.createImageOutputStream(new FileOutputStream(fx));
writer.setOutput(imageOutputStream);
writer.write(streamMetadata, new IIOImage(bi, null, imageMetadata), writeParams);
writer.dispose();
imageOutputStream.close();




static void createTIFFFieldNode(final IIOMetadataNode parentIFDNode, int tag, short type, Object value) {
        IIOMetadataNode fieldNode = new IIOMetadataNode("TIFFField");
        parentIFDNode.appendChild(fieldNode);

        fieldNode.setAttribute("number", String.valueOf(tag));

        switch (type) {
            case TIFF.TYPE_ASCII:
                createTIFFFieldContainerNode(fieldNode, "Ascii", value);
                break;
            case TIFF.TYPE_BYTE:
                createTIFFFieldContainerNode(fieldNode, "Byte", value);
                break;
            case TIFF.TYPE_SHORT:
                createTIFFFieldContainerNode(fieldNode, "Short", value);
                break;
            case TIFF.TYPE_RATIONAL:
                createTIFFFieldContainerNode(fieldNode, "Rational", value);
                break;
            default:
                throw new IllegalArgumentException("Unsupported type: " + type);
        }
    }

static void createTIFFFieldContainerNode(final IIOMetadataNode fieldNode, final String type, final Object value) {
        IIOMetadataNode containerNode = new IIOMetadataNode("TIFF" + type + "s");
        fieldNode.appendChild(containerNode);

        IIOMetadataNode valueNode = new IIOMetadataNode("TIFF" + type);
        valueNode.setAttribute("value", String.valueOf(value));
        containerNode.appendChild(valueNode);
    }

[haraldk]

Hi,

This is as expected. Currently, only a subset of values are kept from the metadata. There are some related issues open already, regarding adding support for more values from metadata, see #412 and #416.

Other values are always taken from the actual image, like width, height and photometric interpretation, to make sure the data written is consistent.

It should be possible to write image with photometric interpretation WhiteIsZero (0), though. You just need to invert the colors in the color map (the IndexColorModel) and invert your data to match so that the image data is indeed 0 for white and 1 for black (ie. the same way the TIFFImageReader reads WhiteIsZero).

It could be possible to add support for letting the metadata decide, if the value from the metadata is compatible with the actual image. But what would you expect the output to be, if your image data is BlackIsZero and your metadata is WhiteIsZero? Should it look the same (ie. inverting the color values while writing)? Or should it look inverted (ie. write the values as is, with the opposite interpretation)? It's not really obvious which solution is the correct one in this case...

Anyway, hope that helps!

--
Harald K

[haraldk]

Hi @agharta

Have you had any time to look into the suggestions above? Is the suggested solution/workaround satisfactory, or do you have any input on how this feature should be implemented?

Best regards,

--
Harald K

[agharta]

Hi Harald, Sorry for my late. Your suggestion is valid but my original tiff file is already WhiteIsZero (|0|). The output become BlackIsZero (|1|). If I try to view the output file with any OS software, the image data (WhiteIsZero) is taken. Seems that the metadata value BlackIsZero is ignored. Plus, if I open the output file with an image editor (eg,  gimp) and I overwrite it, the metadata will be forced to WhiteIsZero. So: 1) Opening a metadata WhiteIsZero image and saving it with your lib converts metedata to BlackIsZero. Please test it, may be my bad implementation. 2) Metadata photometric interpretation seem ignored in "common" viewer software, image data has precedence. 3) Gimp (I have not tested other softwares) force BlackIsZero metadata to WhiteIsZero. In any case, I think that the "result" aka image data  - what the user can see  - should be the primary information. Hope to helped you and sorry for my bad english, Best regards, Agarta Il 22/03/19 13:41, Harald Kuhr ha scritto:

…

Hi @agharta <https://github.com/agharta> Have you had any time to look into the suggestions above? Is the suggested solution/workaround satisfactory, or do you have any input on how this feature should be implemented? Best regards, -- Harald K — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFeBshQ40vyR13GzG_Oc6vwmBjNaU7leks5vZM-GgaJpZM4b5O1h>.

[haraldk]

Just to make some clarifications, photometric interpretation isn't really meta data, it is used to instruct a TIFF reader/viewer how the image data is to be interpreted. Similarly there's no way to know for sure what interpretation should be used by just looking at the image data.

However, there is a known issue that some common TIFF software infers the photometric interpretation from the compression value, and ignore the value of photometric interpretation. This is of course because CCITT encodings originates from the fax world, where the paper is blank (0) and ink is the "value" (1). I don't believe it's correct, but I know it's common (this kind of explains your points 2 and 3).

So, perhaps we should always write CCITT encodings (or even bi-level b/w in general) in WhiteIsZero, because it is more compatible?

I need to think more about the implications of such a change.

Still, if your image is WhiteIsZero, there is code in the reader to preserve it, so I think your point 1 is incorrect. At least I cannot reproduce it, and my tests shows it's kept as is. Please show me your code, if you want me to look further into that.

Best regards,

--
Harald K

[agharta]

Hi Harald, You known Tiff better than me, that's the way: I'm a stupid developer that uses your libs and my opinion is quoted as -32 ;-) Your Idea about CITT and forced WhiteIsZero makes sense for me. Other users could disagree.... Exploring my code I've see my error: orgin image was already altered in BlackIsZero....I'm a stupid man..... So You are right, forgive me.....again, I'm a stupid man. WhiteIsZero is keeped. Best Cheers, Agharta Il 22/03/19 15:48, Harald Kuhr ha scritto:

…

Just to make some clarifications, photometric interpretation isn't really meta data, it is used to instruct a TIFF reader/viewer how the image data is to be interpreted. Similarly there's no way to know for sure what interpretation should be used by just looking at the image data. However, there is a known issue that some common TIFF software infers the photometric interpretation from the /compression/ value, and ignore the value of photometric interpretation. This is of course because CCITT encodings originates from the fax world, where the paper is blank (0) and ink is the "value" (1). I don't believe it's correct, but I know it's common (this kind of explains your points 2 and 3). So, perhaps we should always write CCITT encodings (or even bi-level b/w in general) in WhiteIsZero, because it is more compatible? I need to think more about the implications of such a change. Still, if your image is WhiteIsZero, there is code in the reader to preserve it, so I think your point 1 is incorrect. At least I cannot reproduce it, and my tests shows it's kept as is. Please show me your code, if you want me to look further into that. Best regards, -- Harald K — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFeBshv-AOFdQofb_2mrV0ulVbAKjI9oks5vZO08gaJpZM4b5O1h>.

[haraldk]

No worries! We all make mistakes. I've made quite a few myself... ;-)

I've added special test case for preserving WhiteIsZero is the TIFFImageWriterTest but I also think we should make it the default for FAX encodings. I'll keep this issue open as a reminder.

--
Harald K

[karthick89cpt]

Hi Harald,

Can you please let us know if this issue WhiteIsZero resolved

Thanks
Karthick Kathiresan

[haraldk]

@karthick89cpt

Hi Karthick,

This issue is based on a misunderstanding, so there's nothing to resolve really.

---

I've left it open, as I consider making WhiteIsZero the default for all FAX encodings, this is not yet done. But it doesn't stop you from reading/writing images with WhiteIsZero photometric interpretation.

Best regards,

--
Harald K