I originally wanted to know which image formats are supported by Swing, platform-independently. Swing is my preferred toolkit, and I am trying to research the decision of which image format to use in my hobby work. Once I know which formats are inherently supported, I will decide whether it is simpler to work with one of them or if it is simpler to find and work with appropriately-licensed third-party library. However, I've hit a snag and I want help to sort out where I went wrong.
I've done some digging through the javax.imageio API and I have unsuccessfully attempted to determine what formats are supported on my PC, by doing the following:
package iiortester;
import javax.imageio.spi.IIORegistry;
import javax.imageio.spi.ImageReaderSpi;
public class IIORTester {
public static void main(String[] args) {
IIORegistry iioRegistry = IIORegistry.getDefaultInstance();
ImageReaderSpi imageReaderSpi =
iioRegistry.getServiceProviderByClass(ImageReaderSpi.class);
System.out.println(imageReaderSpi); // output is null
}
}
The default IIORegistry instance did report the category ImageReaderSpi when I made a call to ServiceRegistry.getCategories(), but when I attempt to acquire the image reader service provider interface in the code above, I receive a null reference. This is likely a hint that I'm not going about this the right way, and my plan to query ImageReaderWriterSpi.getFormatNames() has been foiled. However, even if it was successful in reporting supported image formats, that would not tell me whether those formats are supported inherently in any JVM or whether they're supported because I am running a Windows 7 JVM.
Am I looking in the wrong place? Probably. Where should I have been looking? I don't know. Does the JVM even have built-in ImageIO service providers, or is this only for third-party library registration? Where in the Swing API can software look up supported image formats?
GIF, JPEG and PNG should be supported in all JREs.
As a more specific answer to what any particular JRE supports, see the MediaTypes source code which provides lots of info.
To see the supported image formats:
To see which files can be read: ImageIO.getReaderFormatNames();
To see which files can be written: ImageIO.getWriterFormatNames();
JOptionPane.showMessageDialog(null,"Java Image Formats:\r\nread:\t"+Arrays.toString(ImageIO.getReaderFormatNames())+"\r\nwrite:\t"+Arrays.toString(ImageIO.getWriterFormatNames()));
Image Types which are registered in Java will show up in the list.
Related
I am trying to use Wikitude Native API to write an Android App. I see the Sample code and build imageTracker. I want to make a customView with other .obj from internet on the recognized image. Can any one give some idea or sample code to me please.
What I understand now is that, I should change the strokedRectangle to my objectLoader, and put it into glRenderer.setRenderablesForKey. The objectLoader should extends Renderable. However, what should I do next?
public void onImageRecognized(ImageTracker tracker, final ImageTarget target) {
Log.v(TAG, "Recognized target " + target.getName());
StrokedRectangle strokedRectangle = new StrokedRectangle(StrokedRectangle.Type.STANDARD);
glRenderer.setRenderablesForKey(target.getName() + target.getUniqueId(), strokedRectangle, null);
}
The Wikitude Native SDK itself is oblivious to the concept of augmentation rendering. All the related code (StrokedRectangle, Renderable, Renderer, etc.) is part of the example application layer only, meaning you can get rid of all of it and implement the rendering as you see fit. These classes merely serve as a demonstration of how one could implement the rendering.
Ultimately, all you need to do is receive a view matrix and the field of view from the Wikitude SDK and use them as your rendering input. You will need to create a projection matrix from the latter, which the sample code demonstrates as well.
If you should require additional assistance with the implementation, I'd be happy to have an extended discussion in the Wikitude forums. Stackoverflow does not seem to me to be the appropriate place for such support matters.
Is there any method which performs similar tasks to the GetDriveType() method of Microsoft Visual C++. I've already gone through the FileSystemView class of Java Swing. But the method available there are limited and does not fulfill my requirement.
So please tell me someone if Java defines any such method for Windows platform or Platform Independent.
You can use File.listRoots() method. It will list all the drives in your system.
And to get detail information about that drive you can use the following code.
List roots = Arrays.asList(File.listRoots());
for(File f:roots)
{
String s = FileSystemView.getFileSystemview().getSystemTypeDescription(f);
}
This code shows the actual information of drives and other PnP devices. Use this link to know more. And according to your question you must be want to know the hardware details of connected drives to PC. Use JNI if you want to do all code in java.
Are you using JDK7?
If so, there is FileStore which returns the type as a String.
However, looking at the source code itself (FileStore.java) there is a warning that the return value might be implementation specific.
My system has USB DAC capable to play formats 24/96 and 24/192, however when I try to play them using Java I am getting line unavailable exception. Accordingly Java sound documentation, Java doesn't bring any limitations for sample and bits rates, and the limitations are coming for underline sound system. So I traced down where the exception coming from and it looks like native function
private static native void nGetFormats(int mixerIndex, int deviceID,
boolean isSource, Vector formats);
doesn't fill formats with corresponding line info above 16/48.
I looked in sources here.
However to prove that the function really doesn't return format I need or it just returns slight different, I have to see actual formats list. But I can't figure out how reach it. Method of DirectDL is private:
private AudioFormat[] getHardwareFormats() {
return hardwareFormats;
}
So my question has two parts:
How can I still get list of supported formats Java gets from hardware? In this case I could just write own DirectAudioDevice.
Is there any other alternative to standard Java sound to manage higher sample rates from Java? For example, Tritonus, but it seems really old and not supported.
I did my testing on Window, so plan to repeat it on Linux using different than Oracle JRE. However I need to find portable solution anyway.
I found some solution so I can listen to 24/96Khz and 24/192Khz recording using Java in FLAC, APE, and Wavpack formats.
After some debugging in Java sound I found that for some reason Java runtime limits bits depth to 16bits, however accepts high sample rates as 96Khz and 192KHz. So I borrowed down sampling solution from MediaChest. I also got JustFLAC which provides 24/192 support for FLAC files. Supporting 24/192 directly through hardware seems not possible without updating Java runtime native libraries that I plan to do soon.
Edit: the latest update is: I looked in native Java runtime and found the following:
static INT32 bitsArray[] = { 8, 16};
....
#define BITS_COUNT sizeof(bitsArray)/sizeof(INT32)
....
for (rateIndex = 0; rateIndex < SAMPLERATE_COUNT; rateIndex++) {
for (channelIndex = 0; channelIndex < CHANNELS_COUNT; channelIndex++) {
for (bitIndex = 0; bitIndex < BITS_COUNT; bitIndex++) {
DAUDIO_AddAudioFormat(creator, bitsArray[bitIndex],
So as you can see 8, and 16 bits are hardcoded and used in supported formats matrix generation. A fix seems to be easy just by adding two more constants, however it leads in creation own copy of Java runtime and it isn't acceptable. So it looks like I need to initiate some community process to make my recommendations accepted by and then included in next Java runtime updates.
Edit: One more update. Linux sound native implementation seems better. It has only limitation 24bits sample size. So if underline sound system (ALSA) allows the sample depth, then Java can play 24 bits/ 192,000 format. I tested it on Raspberry Pi using latest Raspbian and JDK 8 EA. Unfortunately even latest Arch and Pidora do not have the ALSA improvement.
For reading and writing the value in the private field, you can use reflection. The Java Tutorial and a question in StackOverflow.
About your second question, I've found a library called jd3lib that seems recent.
Files are categorized by file-extension. So my question is, how to identify the file type even the file extension has been changed.
For example, i have a video file with name myVideo.mp4, i have changed it to myVideo.txt. So if i double-click it, the preferred text editor will open the file, and won't open the exact content. But, if i play myVideo.txt in a video player, the video will be played without any problem.
I was just thinking of developing an application to determine the type of file without checking the file-extension and suggesting the software for opening the file. I would like to develop the application in Java.
One of the best libraries to do this is Apache Tika. It doesn't only read the file's header, it's also capable of performing content analysis to detect the file type. Using Tika is very simple, here's an example of detecting a file's type:
import java.net.URL;
import org.apache.tika.Tika; //Including Tika
public class TestTika {
public static void main(String[] args) {
Tika tika = new Tika();
String fileType = tika.detect(new URL("http://example.com/someFile.jpg"));
System.out.println(fileType);
}
}
Structure, magic numbers, metadata, strings and regular expressions, heuristics and statistical analysis... the tool will only be as good as the database of rules behind it.
Try DROID (Digital Record Object IDentification tool) for identifying file types; Java, Net BSD-licensed. It is a free project of the National Archives UK, unrelated to Android. Source is available on Github and Sourceforge. The DROID documentation is good, there's also a getting started guide from the Digital Preservation Coalition.
See also Darwinsys file and libmagic.
There's a tool called TrID that does what you are after - it current supports 5033 different file types - and can be trained to add new types. On *nix systems, there's also the file command, which does something similar.
well, its like having a database of file-format you want to read without looking for extension in your app. Exactly as Linux does. So whenever you open a file, you need to check file-format database which type it belongs to. Though Not sure how will it work for different file types, but most of files have fixed header format, be it zip, pdf, mpg, avi, png, etc.. so this approach should work
You could try MimeUtil2, but it's quite old and though not up2date. The best way is still the file extension.
But the solution from Adam is not as bad as you think. You could build your platform independent solution using a wrapper around command line calls. I think you will get much better results using this method.
The following code snippet retrieves information about the file type
final File file = new File("file.txt");
System.out.println("File type is: " + new MimetypesFileTypeMap().getContentType(file));
Hopefully, it may help you
I want to try to create a learning chess application as a school project. My first plan was to simply pit this AI against itself, but to really show if it has been succesful it needs to be able to show how well it progresses. In order to do this, i want it to play rated games on sites such as chess.com. However, they do not (yet) have a public API, i believe.
Therefore, i wanted to make a program in java that recognizes colors and images. It keeps an internal 2-dimensional array of all the positions, and recognizes the pieces on the board. I think i have found a way to do this in a window using something like the Java Robot Class.
What i would like it to do, however, is to open this webpage in an internal window and keep doing this in the background. Is there a way to recognize colors within the own window, without needing to be in the foreground?
Edit: I'm planning on using this browser component i just found. I noticed that it is possible to create a full-page snapshot of the page and save it as a BufferedImage(?). Would this make it easier to do this?
Edit 2: I just read that 'Outside assistance from other people, computers/chess engines, or endgame tablebases is entirely prohibited'. I suppose letting a computer do all the playing does certainly include in that. So i might try using another site, so answers that are specific for chess.com won't cut it!
I don't know it it helps but may be you can have a look at the Sikuli project.
http://sikuli.org/
Sikuli is a program (and an API) to handle the interactions with the User Interface. For instance, you can write a script to click on an image or a button in certain conditions.
Especially interesting for you, there is a Java integration: http://sikuli.org/docx/faq/030-java-dev.html
Here is an extract of the website to give you an idea of the code you can write.
EDIT: in this code it is important to notice that you are defining new Patterns with the images. Sikuli will be able to find matching patterns.
import org.sikuli.script.*;
public class TestSikuli {
public static void main(String[] args) {
Screen s = new Screen();
try{
s.click("imgs/spotlight.png", 0);
s.wait("imgs/spotlight-input.png");
s.type(null, "hello world\n", 0);
}
catch(FindFailed e){
e.printStackTrace();
}
}
}
You should consider playing on a chess server where an API is avaible and chess engines are allowed. There is The Internet Chess Club (ICC) where you must pay to have a human account and then you can get a free computer account for your engine. There is also the Free Internet Chess Server (FICS) where you and your engine can get free accounts.
The ICC is usually prefered because the level of players is higher there with lots of international masters and chess masters playing there.
The best way to Interface with theses sites is to implement the xboard protocol. This will allow your engines to play through the Winboard or XBoard interface (among others) and theses interface can be used to connect on FICS or ICC and automatically play there.
I hope this help, even if it does not directly answer the question.
I'm not sure what your input is but you have two options:
You can work an a PNG image. Load the image into a BufferedImage (docs) object and examine it there. You can use a screen shot tool to create those.
It seems chess.com uses HTML with JavaScript. You can download the HTML using HttpComponents and examine it to see where the pieces are. This has the additional benefit that you don't have to guess which piece goes where since the HTML contains the source information.