I have a byte[] of an image and I need to upload it as an image to picasa.
According to the documentation, an image is uploaded as follows.
MediaFileSource myMedia = new MediaFileSource(new File("lights.jpg"), "image/jpeg");
which means I need to create a File, out of the byte[].
The catch is, I have to do this without using FileOutputStream as it is not supported by Google App Engine (which is the environment I am using)
Is there any way to do this?
You don't have to use MediaFileSource to upload a photo, you can use MediaByteArraySource and pass it to photo.setMediaSource(...).
Related
I've been working on App that allows to open files for which Google Drive cannot generate thumbnails, but the app I'm working on can. I've been following this article: https://developers.google.com/drive/api/v3/file#uploading_thumbnails and have the following code in my app as a result:
File file = drive.files().get(fileId).setFields("id,name,headRevisionId,hasThumbnail,contentHints").execute();
if (file != null && file.getHeadRevisionId().equals(versionId)) {
File.ContentHints.Thumbnail customThumbnail = new File.ContentHints.Thumbnail();
customThumbnail.encodeImage(imageData);
customThumbnail.setMimeType("image/png");
File.ContentHints contentHints = new File.ContentHints();
contentHints.setThumbnail(customThumbnail);
drive.files().update(fileId, new File().setContentHints(contentHints)).execute();
}
Image exists - imageData is byte[] and it has proper data in it. It seems that Google Drive retrieves this data because if I try to open preview of the file I've uploaded thumbnail for (on drive.google.com) - it tries to load it, but constantly shows "Failed, retrying".
If I do "non-safe" base64 encoding - I'm able to open this image URL in browser and any viewer and I've tried to pass this "non-safe" base64 encoded string, but the result is the same.
Is there something wrong with my code or I'm missing something in documentation or it's an issue on Google Drive side?
I have a EBCDIC file from which i extracted images. However, there is some data on the images which is key source in identifying my transactions.
Assume that i have an image as "stackoverflow logo" stored under name "img1.jpg" on my desktop and when i read it using the following code, it works
String inputImage = "C:\\Desktop\\img1.jpg";
File imageFile = new File(inputImage);
BufferedImage image1 = ImageIO.read(imageFile);
System.out.println(image1);
However, when i attempt the same with an image decoded from EBCDIC conversion, it returns null.
The difference i observed is that there is no color associated in the decoded image. Is there any way to read these images and retrieve the text on the image. Following is not the exact image which i am working on, but just to give an idea i am sharing a sample from internet.
Note: The image am working on looks like a Scanned image (Grayscale)
Example:
Also, I observed that if i open the decode file and do a screen capture via snipping tool and store it as jpg file (which already is jpg) and read it, system is reading that file. not sure where is the issue, is it compression or color coding or format.
Thank you everyone.
I used Tess4j to decode the TIFF image. Unfortunately the information i was looking for isn't available in the decoded text. But, done with the POC.
used the following library and added eng.traineddata in the folder where images exist
import net.sourceforge.tess4j.*;
String inputImage = "C:\\Desktop\\img1.tiff";
File imageFile = new File(inputImage);
ITesseract imageRead = new Tesseract();
imageRead.setDataPath("C:\\Desktop\\");
imageRead.setLanguage("eng");
String imageText = imageRead.doOCR(imageFile);
System.out.println(imageText);
I got a strange issue with a GIF image in Java. The image is provided by an XML API as Base64 encoded string. To decode the Base64, I use the commons-codec library in version 1.13.
When I just decode the Base64 string and write the bytes out to a file, the image shows properly in browsers and MS Paint (nothing else to test here).
final String base64Gif = "[Base64 as provided by API]";
final byte[] sigImg = Base64.decodeBase64(base64Gif);
File sigGif = new File("C:/Temp/pod_1Z12345E5991872040.org.gif");
try (FileOutputStream fos = new FileOutputStream()) {
fos.write(sigImg);
fos.flush();
}
The resulting file opened in MS Paint:
But when I now start consuming this file using Java (for example creating a PDF document from HTML using the openhtmltopdf library), it is corrupted and does not show properly.
final String htmlLetterStr = "[HTML as provided by API]";
final Document doc = Jsoup.parse(htmlLetterStr);
try (FileOutputStream fos = new FileOutputStream(new File("C:/Temp/letter_1Z12345E5991872040.pdf"))) {
PdfRendererBuilder builder = new PdfRendererBuilder();
builder.useFastMode();
builder.withW3cDocument(new W3CDom().fromJsoup(doc), "file:///C:/Temp/");
builder.toStream(fos);
builder.useDefaultPageSize(210, 297, BaseRendererBuilder.PageSizeUnits.MM);
builder.run();
fos.flush();
}
When I now open the resulting PDF, the image created above looks like this. It seems that only the first pixel lines are printed, some layer is missing, or something like that.
The same happens, if I read the image again with ImageIO and try to convert it into PNG. The resulting PNG looks exactly the same as the image printed in the PDF document.
How can I get the image to display properly in the PDF document?
Edit:
Link to original GIF Base64 as provided by API: https://pastebin.com/sYJv6j0h
As #haraldK pointed out in the comments, the GIF file provided via the XML API does not conform to the GIF standard and thus cannot be parsed by Java's ImageIO API.
Since there does not seem to exist a pure Java tool to repair the file, the workaround I came up with now is to use ImageMagick via Java's Process API. Calling the convert command with the -coalesce option will parse the broken GIF and create a new one that does conform to the GIF standard.
// Decode broken GIF image and write to disk
final String base64Gif = "[Base64 as provided by API]";
final byte[] sigImg = Base64.decodeBase64(base64Gif);
Path gifPath = Paths.get("C:/Temp/pod_1Z12345E5991872040.tmp.gif");
if (!Files.exists(gifPath)) {
Files.createFile(gifPath);
}
Files.write(gifPath, sigImg, StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING);
// Use the Java Process API to call ImageMagick (on Linux you would use the 'convert' binary)
ProcessBuilder procBuild = new ProcessBuilder();
procBuild.command("C:\\Program Files\\ImageMagick-7.0.9-Q16\\magick.exe", "C:\\Temp\\pod_1Z12345E5991872040.tmp.gif", "-coalesce", "C:\\Temp\\pod_1Z12345E5991872040.gif");
Process proc = procBuild.start();
// Wait for ImageMagick to complete its work
proc.waitFor();
The newly created file can be read by Java's ImageIO API and be used as expected.
This question already has answers here:
How To Convert A Bitmap Image To Uri
(2 answers)
Closed 3 years ago.
I'm using a library that returns a bitmap image if I want to share this image to another application or send it via email? I don't have the Uri of the image then what should I do
It all depends on your environment:
- you can get hand over the complete image (e.g. an attachment in an email)
- if you have an solution which could be accessed from the target, then you can create your own uri. On a local system, you could store the image in a file. Or if you have a web application, you might want to make the image available so that you can provide an url to the image, too)
So it mainly depends on the whole Szenario: where does the image come from, how big is it? What is the target? ....
And sorry, that I do Not write this as a comment - need a reputation of 50 to write comments first ....
convert your bitmap into a file:
String path = Environment.getExternalStorageDirectory();
File file = new File(path + "/image_name.jpg");
OutputStream fOut = new FileOutputStream(file);
pictureBitmap.compress(Bitmap.CompressFormat.JPEG, 85, fOut); // saving the Bitmap to a file compressed as a JPEG with 85% compression rate
fOut.flush(); // Not really required
fOut.close(); // do not forget to close the stream
Get the URI from the file:
Uri yourUri = Uri.fromFile(file);
Addition: for android 7.0+ you need a different way to get URI from file.
Saving file to the default main directory is only an example but maybe not the best practice.
I'm currenty developing for blackberry and just bumped into this problem as i was trying to download an image from a server. The servlet which the device communicates with is working correctly, as I have made a number of tests for it. But it gives me the
413 HTTP error ("Request entity too large").
I figure i will just get the bytes, uhm, portion by portion. How can i accomplish this?
This is the code of the servlet (the doGet() method):
try {
ImageIcon imageIcon = new ImageIcon("c:\\Users\\dcalderon\\prueba.png");
Image image = imageIcon.getImage();
PngEncoder pngEncoder = new PngEncoder(image, true);
output.write(pngEncoder.pngEncode());
} finally {
output.close();
}
Thanks. It's worth mentioning that I am developing both the client-side and the server-side.
I am not aware by server side code. You can look on this Link to get an idea how to upload file using multipart to support Big files uploading
it can also work on blackberry , With some modifications needed.
http://www.developer.nokia.com/Community/Wiki/HTTP_Post_multipart_file_upload_in_Java_ME
I'm not familiar with the PNGEncoder class you're using, but just looking at your servlet code, and the comment you made about the request size (2.2 MB), I'm guessing that part of your problem is that you're uncompressing the image, and then transmitting it across the network.
I don't think you should have any PNGEncoder or ImageIcon code in your servlet. You should just read the "c:\\Users\\dcalderon\\prueba.png" file in with a normal InputStream as bytes, and then write that to the servlet's output. I don't think it matters whether that file is a PNG image, a .mp3 file, or any other content. (although you might need to set the Content Type to image/png).
So, I would try transmitting the image compressed (as a .png just as it's stored on disk). If that still doesn't work, then go with the suggestion to use multipart transmission.