From customer i have request to send images in .JIF format (JFIF) . I have java aplication, but i coould not google anithing to topic of how to convert to that image type, i could even hardly google anithing to ".JIF" format itself.
EDITED :
Can somebody advice how to convert Exif image to JFIF in java ? And how to add coments to this JFIF image?
(tried to use jheader library sadly ended with nullpointer exception, not much more choices on google.)
Edit: Converting Exif JPEGs to JFIF JPEGs:
If you don't mind losing some quality (due to lossy JPEG re-encoding), you can convert the image as simply as:
File inFile = ...;
File outFile = ...; // Feel free to use ".jif" as extension
if (!ImageIO.write(ImageIO.read(inFile), "JPEG", outFile)) {
System.err.println("Could not write JPEG format"); // Should never happen
}
This will work, because the default JPEGImageWriter plugin only supports JFIF format. And because we don't read the metadata, the old Exif information will just be lost. Doing it this way, will not allow you to add comments, however.
To add comments, you could still use standard ImageIO API, but we'll have to access the metadata, making the code more verbose. See JPEG Metadata Format Specification for more information on the metadata format. If you need to convert comments from the Exif metadata, please update your question to specific on that, as it requires further parsing of the meta data and extra support not currently in the ImageIO API.
File inFile = ...;
File outFile = ...; // Feel free to use ".jif" as extension
BufferedImage image = ImageIO.read(inFile);
ImageWriter jpegWriter = ImageIO.getImageWritersByFormatName("JPEG").next(); // Should be a least one
// To write comments, we need to add it to the metadata
ImageWriteParam param = jpegWriter.getDefaultWriteParam();
IIOMetadata metadata = jpegWriter.getDefaultImageMetadata(ImageTypeSpecifier.createFromRenderedImage(image), param);
IIOMetadataNode root = (IIOMetadataNode) metadata.getAsTree("javax_imageio_jpeg_image_1.0");
IIOMetadataNode markerSequence = (IIOMetadataNode) root.getElementsByTagName("markerSequence").item(0); // Should be only one
// Insert a "COM" marker, with our comment
IIOMetadataNode com = new IIOMetadataNode("com");
com.setAttribute("comment", "Hello JFIF!");
markerSequence.appendChild(com);
// Merge edited metadata
metadata.mergeTree("javax_imageio_jpeg_image_1.0", root);
ImageOutputStream output = ImageIO.createImageOutputStream(outFile);
try {
jpegWriter.setOutput(output);
// Write image along with metadata
jpegWriter.write(new IIOImage(image, null, metadata));
}
finally {
output.close();
}
jpegWriter.dispose();
This way, we still re-encode the image in lossy JPEG, but we convert from Exif to JFIF and add comments.
Now, there is still another option, to do this completely lossless. But it does require a bit of a deeper understanding of the JIF segment structure, and how the Exif and JFIF formats work. Unfortunately, there's no standard Java API (that I know of) to do this, so you will have to roll your own. Feel free to use my JPEG segment parsing code as a starting point. The JHeader project you linked also looks very promising, but I don't have any experience with this library, so I can't provide any advice there.
Here's the basic idea:
Parse/skip the marker segments until the SOS (Start of Scan) segment (the data following the SOS will be the compressed image data).
Write the SOI marker (0xffd8)
Create an APP0/"JFIF" marker (I think you can just use defaults here, see JFIF segment for details). You can write 0, 0 for the thumb dimensions, and skip writing thumbnail data.
Add your COM segments with whatever comments you need (possibly extracted from the Exif metadata)
Write the SOF, DHT, DQT etc. standard segments as-is from the original stream (skip the APP1/"Exif" and other "custom" segments).
Write the SOS marker and the image data from the original stream
In theory, this should work. You might have some minor color space issues, as the Exif data might contain different color spaces (normally sRGB or AdobeRGB1998), while JFIF doesn't have a defined color space. If you need this add an APP2/"ICC_PROFILE" segment with the required profile (after step 3).
Good luck! :-)
Note: This is not a complete answer, but instead an attempt to clarify why you need to talk to your client, and figure out what is wrong with your JPEGs and what he actually means by "JIF".
First an foremost, JPEG is not a file format. JPEG is a still image compression standard. Part of this standard (usually referred to as "Annex B") is a description of an interchange format, sometimes referred to as JIF. The standard also specifies a full file format known as SPIFF, but this format is not very widespread (and I don't think this is what you want).
The files you find everywhere, referred to as "JPEG files" (and I assume this is what you refer to as "Classic JPEG"), is usually in one of two slightly different flavors of basically the same file format:
The most basic format is JFIF. This format starts with a SOI marker, immediately followed by an APP0 marker with "JFIF" (null-terminated) as its identifier. According to the original JFIF specification "The JPEG File Interchange Format is entirely compatible with the standard JPEG interchange format; the only additional requirement is the mandatory presence of the APP0 marker right after the SOI marker." (this part is left out of the ITU and ISO versions of the specification, but still applies). Put simply, JFIF constrains the JPEG data to be 1 or 3 components, encoded as either Y or YCbCr, and highly recommends baseline DCT, Huffman coded compression.
The other common format is Exif. This format starts with a SOI marker, immediately followed by an APP1 marker with "Exif" (null-terminated) as its identifier. This format is developed by the digital camera manufacturers, and allows much richer meta data to be recorded within the file (in the form of a TIFF meta data structure). From what I understand, Exif constrains the JPEG data to be 3 components, encoded as YCbCr, using baseline DCT, Huffman coded compression (the last part may be just a an interoperability recommendation, the language in the spec is a little hard to read...).
Both of these formats contains the same "segment" layout and the image data is compatible, but still they are mutually exclusive, due to the requirement of having "their" marker as the first segment in the stream (because of this, also a "third" format exists, which is a JFIF for compatibility, but still contains an Exif segment for richer meta data).
Yet another family of "JPEG files" lacks both JFIF and Exif markers, but still follows the same segment layout, with SOI, APPn markers, SOF, DHT, DQT, SOS and EOI markers, as described in "Annex B" (JIF). Most decoders will decode these images as well.
TL;DR: To summarize, what all the "JPEG" file formats have in common, is that they use JPEG compression, and follows the JIF structure. Because of this, it is somewhat hard to understand what someone means by "convert classic JPEG to JIF".
"Classic JPEG" is JIF.
First of all you need to read that image then you must write that image into the dimensions and format you want.
You must use ImageIO class and BufferedReader to read images
To write them use Graphics2D class
Replace format name with jif
File inputFile = new File(inputImagePath);
BufferedImage inputImage = ImageIO.read(inputFile);
// creates output image
BufferedImage outputImage = new BufferedImage(scaledWidth,
scaledHeight, inputImage.getType());
// scales the input image to the output image
Graphics2D g2d = outputImage.createGraphics();
g2d.drawImage(inputImage, 0, 0, scaledWidth, scaledHeight, null);
g2d.dispose();
// extracts extension of output file
String formatName = outputImagePath.substring(outputImagePath
.lastIndexOf(".") + 1);
// writes to output file
ImageIO.write(outputImage, formatName, new File(outputImagePath));
Related
Can anyone, at least in abstract, describe to me what to do if I have an arbitrary image file (that I know the layout of and other specifications) and I need to convert image files like .jpg, .tga and .png into that format.
ImageIO does not know this format. It's a custom format. I want to create a tool that will be able to work with this format = to be able to write this custom from jpg,png,tga etc.
How do I specify the things like the Header the custom image format is supposed to be saved (written) with?
Example: convert penguin.png into penguin.xyz where .xyz is a custom image format.
My idea: I could input the source image's (any common image file) bitmap data into a buffer, then add the specifications of the custom image file to the buffered image data and then write the new image file (my arbitrary image file).
I've been looking for 3 days, can't find a tutorial for this. Should I tackle this problem once I get some more experience?
I am using the BufferedImage class to read in an image as pixels which I then use bit shifting to get their appropriate components into separate int arrays. This works OK.
I have used this reference site to manually perform DCT functions with the pixel arrays.
Methods used: forwardDCT(), quantitizeMatrix(), dequantitzeMatrax(), inverseDCT()
which then are fed back into a resultant image array to reconstruct the JPEG file, which I then use BufferedImage's write() method to write the pixel data back out as the image.
This works perfectly, and I can view the image. (Even better the value I use to compress visually works).
My question is, is there a way to write the quantitize coefficients as the compressed values as a JPEG?
Because the BufferedImage write() method is used to input pixel data, rather than coefficient data?
Hope this is clear.
Thanks
Ultimately the DCT calculation is just one step in the whole JPEG encoding process. A complete implementation also has to deal with quantization, Huffman encoding, and conforming with the JPEG standard.
Java effectively just gives you an interface to a JPEG encoder that lets you do useful things like save images.
The ImageWriter that ImageIO.write() uses for JPEG images depends on your system. The default ImageWriter for JPEGs will only let you change some settings that affect the quantization and encoding using the JPEGImageWriteParam class (http://docs.oracle.com/javase/6/docs/api/javax/imageio/ImageWriteParam.html).
Getting your hand-crafted DCT coefficients into a JPEG file could potentially involve writing an entire JPEG library. If you don't want to do all that work, then you could modify the source of an existing library so that it uses your DCT coefficients.
Before the DCT . . .
While JPEG has no knowledge of colors, it is normal for JPEG file formats to use the YCbCr color space. If you are thinking about writing a JPEG file, you would need to do this conversion first.
After the Quantization . . .
The coefficients are run length encoded. That's a step you'd have to add. That's the most complex part of JPEG encoding.
I want to dive in the low level of how a png file is represented on memory in java, so that i can iterate over its pixels, change them, create a modified png file using existing one, etc.
Where do i begin?
You could begin by reading it into a BufferedImage with ImageIO.read(file) .
The getRGB(...) methods can help you to obtain information about the individual pixels, and the corresponding setRGB(...) methods help you to change them.
The representation of an image in memory in Java, is essentially unrelated to the format of the file: be it PNG, JPEG, GIF or whatever, those are standards for encoding an image as a (language independent) stream of bytes. But when you are manipulating the pixels of an image in memory, you have already decoded it, and so you've "forgotten" from which format (PNG, JPEG...) it came from.
The most common way of manipulating an image in Java is using the BufferedImage class, included in the java.awt.image.* package. But that's not a requisite. For instance, I've worked on a low level PNG coder/encoder (PNGJ) that does not use BufferedImage, but instead gives you each image line as an int[] array.
When saving a new image with ImageIO generic ImageWriteParam supports explicit setting of compressionQuality parameter from range 0.0f (high compression) to 1.0f (high quality) regardless of image compression algorithm used (eg. png, jpeg, gif).
Is there any way to read compressionQuality from an existing image?
Is that compressionQuality write parameter just a hint to ImageWriter and is not stored anywhere in image's metadata? If that's true how image processing software (e.g. GIMP) manages to provide the following option in 'Save As' dialog?
I managed to read IIOMetadata from ImageInputStream and iterate through its metadataFormatNames to print out image metadata in different XML formats (native and standard javax_imageio_1.0, usually). Although I couldn't find any indication of image's compressionQuality in there.
I don't think that compressionQuality is stored with image meta data, this is processing parameter only.
In the tif format, when you add EXIF meta data it creates an new IFD (tif-direcory) and stores the exif metadata as fields. So when parsing a tif file with a single image and exif data is easy. But you can get multipart tiffs, where a tif can contain more then one image, the question is can each of these images have EXIF data?
Does this create a new IFD for each pictures metadata?
What is is the arrangement of the IFD's then?
The tif specification doesn't go into any detail, I know that when a single image tif file has EXIF data there is an offset field to the EXIF data, so I can jump to that location and do the parsing myself, but the Java Sanselan library gives me easy access to the EXIF IFD and fields, but if it is possible to multiple EXIF IFD's (one for each image) then the library doesn't tell me to which image the data belongs.
If you cannot have more then 1 EXIF IFD in a multipart tif file, then it'll be trivial! In other words:
Do I need to go to the effort of manually parsing the exif data? Because I only need to do this if you can attach EXIF data to each image inside a multipart tif.
Or does anyone know of a good Linux app that allows me to add EXIF data to tif files so I can figure it out for myself?
To answer your questions:
can each of these images have EXIF data? Does this create a new IFD for each pictures metadata? What is is the arrangement of the IFD's then?
Yes, each of these images can have it's own EXIF data. Each image is related to its own IFD and each EXIF data is a SUB-IFD inside the corresponding image IFD.
but the Java Sanselan library gives me easy access to the EXIF IFD and fields, but if it is possible to multiple EXIF IFD's (one for each image) then the library doesn't tell me to which image the data belongs.
I never used Sanselan and it's successor Apache Imaging so I guess there could be two things happening here: first, Sanselan may by default choose the first page for a multipage TIFF if you actually can insert EXIF to a multipage TIFF; or there might be a parameter which you can set somewhere with a method like setWorkingPage(int page) and this is what I am doing with "icafe" Java image library.
The following is a bit more detailed information as to what is happening inside a TIFF image when you need to add EXIF metadata:
For a single page TIFF, there is a "main" IFD which specifies all the information regarding the image contained there. When EXIF data is needed, an specially tag called "EXIF_SUB_IFD" is added to the main IFD. The value for this tag is an offset address with regards to the image stream start. Now if we jump to the address specified by the offset, we will actually find a "sub" IFD with exactly the same structure as the "main" IFD which contains all the EXIF data.
The above mentioned structure is exactly like a directory tree and hence the name IFD. There is however a subtle difference here: the main IFD should contain the actual image data but the EXIF sub-IFD doesn't. In fact, there is also a GPS sub-IFD which is in parallel with the EXIF sub-IFD and with the same structure as well. An interesting thing is the data for the EXIF can be stored anywhere inside the TIFF image stream (as long as it doesn't break other part of the directory and image data).
Now comes to the multipage TIFF. The pages can be related or not. The last 4 bytes of each page IFD points to the offset of another IFD. They are sometimes gathering together to serve as a "single" document which could be from a scanner. That said, each page is itself a "single" page TIFF which could contain it's own EXIF metadata just like a single page TIFF.
You probably want to check out ExifTool. It works pretty well for what I use it on (JPEGs), but I've never used it with TIFF files containing multiple images. Also check ImageMagick, he has a ton of useful tools.