I'm creating a 64x64 pixels VolitileImage, drawing some images and shapes on it (using drawImage, fillRect etc.), then I want to draw this image stretched up to 640x640 pixels. I expect to see the 64x64 matrix of 10x10 screen pixels squares. That's what I see on non-retina display. But when I try this on a retina-display I actually see 128x128 matrix of 5x5 squares.
Here's what I'm talking about:
Is there a way of "turning off" this behavior? Because what I need is to display 64x64 image stretched 10 times.
UPD:
Adding an compileable example: https://gist.github.com/miriti/651cb4b768cc5a076341
Each balack and white point is 1 pixel in a 64x64 image. Notice the difference between regular display and retina:
Related
I am drawing a coordinate system with weight, height =10000*10000 on a frame. It too big, my graph can't fully display. I try to draw on scroll but it's lag. I want to display my graph on a frame 10000*10000, fit with my screen computer to print screen. What should I do?
You have to scale you graph. You know, Earth is very big but it fits map that can be shown on a screen of your smart phone :)
This means that if for example you want to show rectangle of 10000*10000 on screen that has (for example) 1000 pixels you have to scale your picture 10 times.
Option 1: Set the size of the JFrame on which you are displaying the graph to the desired size.
setSize(WIDTH, HEIGHT);
where WIDTH and HEIGHT are in pixels.
OR
Option 2: Scale the drawing. That is, simply divide each dimension in the drawing by 2 to make it half the size.
I need to crop images for a "Photoprint" app of mine. To create appropriate image for printing paper, image will be scaled up, scaled down and cropped by dragging to specific field of image in a frame. Only short edge or long edge of the image could have empty space, two edges shouldn't have empty spaces at the same time. Any of height or width should fit the crop frame. By the way, crop frame should stay the same size. For example; for a 5x7" printing paper, frame will have 504x306px size.
Could you help me, image crop algorithm?
My question involves the drawImage method in Java Graphics2D (this is for a desktop app, not Android).
My BufferedImage that I'd like to draw contains high resolution binary data, most pixels are black but I have some sparse green pixels (the green pixels represent data points from an incoming raw data stream). The bitmap is quite large, larger than my typical panel size. I made it large so I could zoom in and out. The problem is when I zoom out I lose some of my green pixels .. as an example if my image is 1000 pixels and by panel is 250 pixels, I'd lose 1 out of 4 pixels in each direction (X and Y). If I use nearest neighbor interpolation when I scale the pixels can just disappear to black. If I use something like bilinear interpolation my green pixel will get recolored to somewhere between black and green.
I understand all this behavior, but my question is that is there any way to get the behavior I want, which is to make sure if any pixels is non-black I want it to be drawn at it's full intensity. Perhaps something like a "max-hold" interpolation.
I realize I could probably do what I want by drawing shape primitive over a black background, and maybe this is what I'll have to do. But there is a reason I'm using bitmaps (has to do with the fact that I'm showing the data in a falling spectrogram-type display - and it does have a mode where all the pixels could be colored and not just black and green).
Thanks,
You could look at the implementation of drawImage and override it to get your desired behaviour, however probably the core of the scaling uses hardware acceleration, so re implementing it in Java would be really slow.
You could look into JOGL, but my impression is that, if your pixels are really sparse, just drawing the green pixels on a black background (or over an image) would be both easy to code and very fast.
You could even have an heuristic switching between painting the dots to scaling the image if the number of dots starts being too high.
I am attempting to use texture coordinates from a pre-generated PNG file on a 3d world of quads loaded into Java with LWJGL's slick-util extension.
The texture file is 192x96pixels, and properly formatted. It's composed of 6x3 32x32 tiles.
The 3d quads are 1.5f wide and long. They are spaced apart properly.
I am having issues getting the right texture coordinates. When I put 0.0f to 0.333333f as the y coordinates, I get slightly more than the top tile's height displayed. However, if I put 0.0f-0.25f, I get exactly 1/3rd, which is my tile's height. I have yet to find a magic number for the X coordinates, but maybe someone could explain to me why 1/4 of 96 is 24 according to textures coordinates, or what I'm doing wrong? I'm suspecting it could be a clash between my quad size and textures.
The tops of the cubes are using the texture coordinates (0.0, 0.0f), (0.0, 0.333333f), (0.166666f, 0.333333f), (0.166666f, 0.0f), which is applied moving anticlockwise from the top left to the top right. Again, the main texture file is 32x32 tiles arranged to make 192x96(96 is the height).
Notice I placed a white line at the top of one of the tiles to see its border, and black line at it's bottom, then a white line for the top of the next one below it. The texture 'bleeds' too far down. The other textures have their own even stranger coordinates, as you can see.
Arranging texture coordinates with the assumption the top of the image is 1.0 rather than the bottom produces odd squares with a rectangular hole in the center where quads should be.
I am using TEX_ENV GL_MODULATE.
Texture sizes are usually a power of 2. I suspect something resized your 192x96 texture as a 256x128 or 256x256 texture. This doesn't really explain the values you found however... But, I think, if you resize your texture to 256x256(increase the size, don't scale!) and calculate your texture coordinates based on that, your problem will go away.
I don't know about java but with my image atlases in objective C and openGL ES you need to make the textures smaller than what you are referring to when selecting them from the atlas.
Have you left a sufficient gap between the texture images to prevent 'bleeding?
I'm trying to write a graphical effect where a circle moves around an image smudging the image as it goes (like the way the smudge tool in Gimp or Photoshop would work). The basic algorithm I'm using is:
the circle moves from position A to position B on the bitmap
copy a circle of pixels from position A into a temporary bitmap
draw this circle of pixels from the temporary bitmap to position B using alpha of about 50%.
This works fine and looks like what I would expect, where the image will look like it's getting smudged if the circle moves 1 pixel at a time over the image.
I now want to add some texture to the smudge effect. I have a bitmap that contains a picture of a paint blob. The algorithm from the above is modified to the following so the smudge takes the shape of this paint blob:
as before
replace the temporary bitmap pixels with the paint blob texture then copy the circle of pixels from position A into the temporary bitmap but only keep the pixels that match up against paint blob pixels (i.e. use Porter-Duff "source in destination" mode when drawing the circle into the temporary bitmap).
as before
This almost works and it looks like it's fine initially but gradually the smudging makes the colors in my image darker! If the circle passes over the same area several times, the colors eventually change to black. Any ideas what I could be doing wrong?
I've implemented the above in Android. I happened upon this post about bitmaps in Android (like my paint blob texture) being loaded with "premultiplied alpha", where the author says it caused his images to become darker because of it:
http://www.kittehface.com/2010/06/androidbitmap-and-premultiplied-alpha.html
I suspect I'm suffering from a similar problem but I don't understand what's going on well enough and don't know how to fix it. Does anyone have hints at what might be going on?
Well from first glance the reason the image is getting darker is because #3 in the first three steps. You overlaying a pixel over an existing pixel at 50%. You might want to consider using the mean of the original pixel value and the new pixel value. You might want to research some blurring algorithms.