I am working on some batch routines to manage large libraries of jpg files. I have a nice routine that will quickly downsize 4mb+ files down to 40kb+. Using CCR.Exif, I can determine if an image needs to be rotated. My problem is that I can't find any code to rotate the image before I save it. I really need to be able to do this without incurring the overhead of bringing the image to screen.
I'm using the built-in jpeg.pas; I found another library by Gabriel Corneanu at CodeCentral, but it hasn't been updated for DXE2. All I need to do is a 90° rotation.
Any help will be greatly appreciated!
JPGs are compressed and must be rendered before you can work with the image data. Even if it is a non-visible canvas, they still need to be loaded into a component that renders them. Then you can use Windows API calls to rotate the image by directly accessing the canvas. I haven't rotated the image before, but I have manipulated it in other ways by accessing the canvas.
GR32 and EFG are both good sites with several components and algorithms. Here is one example on EFG's site that rotates an image. The code is Delphi 3, but it should still work fine for image manipulation.
EFG Example with Source
TImage32 has a method to rotate the image 90 degrees as well. See TImage32.Bitmap.Rotate90. TImage32 is part of the GR32 library and has been updated for Delphi-XE2.
svn co https://graphics32.svn.sourceforge.net/svnroot/graphics32/trunk graphics32
Also see: GR32 Homepage
If you need to rotate JPEG in steps by 90 degree, then look for lossless transformations.
For example irfanview.com has a special plugin DLL for it, though it does not have public API, but maybe you can ask Irfan Author for it or reverse-engineer it with debugger and cff explorer.
a lot of discussion might by just googled, including discussion how it is implemented.
https://www.google.ru/search?client=opera&q=lossless+jpeg+rotation
Component catalogues have that like
http://www.torry.net/quicksearchd.php?String=jpeg+lossless&Title=No
That will not work with rotation finer than 90 degree steps, but for orthogonal turns keep searchign for lossless jpeg transformations.
The fastest way to rotate a JPEG image would be to write a new / alternate pixel pump for the JPEG decoder that reads and decodes the JPEG pixels left to right (x,y), and writes them to bitmap memory as (y,x) - that is, writing one pixel per scanline at the same offset, instead of the normal mode of writing one pixel per column on the same scanline.
Anything else will be making multiple passes over the bitmap data.
Related
my question may seems not new, but as far as I searched for days I couldn't find my answer.
I'm trying to make a webpage with PIXI.js which uses webGL.
My webpage is mouse movement parallax, I mean all the movements an object can have is few pixels when the user moves his/her mouse pointer.
Now my problem: I have some simple images and i don't know to use svg or png.
My images are like these:
https://1drv.ms/i/s!Aj-BeFYyTnRzhTBSVEXXeJ2c-O7V
https://1drv.ms/i/s!Aj-BeFYyTnRzhTFeTzJLrWaq_VFh
https://1drv.ms/i/s!Aj-BeFYyTnRzhTIa9lAaS9dKX1DL
I want to make my webpage as smooth as possible and I don't know to use png or svg. I searched a lot, some says it depends on the png and svg, in my case my svgs won't be too complex but some says because svg use CPU and the WebGL use GPU using them both, cause lack of performance, and also some says which using svg in PIXI makes no difference than the png because PIXI makes texure from them and there won't be any deference...
I'm new to webGL and Pixi so now with these answers I became confused, by the way, for my case the images size is not mattered, I only wanted as much smoothness as possible.
thanks a lot for your help.
It doesn't make a difference for runtime performance, the SVGs will be rasterized into textures either way. However during initialization where the browser neeeds to rasterize the SVGs to create a texture from them there might be a significant performance penalty depending on how complex your SVGs are.
However since you're developing for the web aforementioned penalty is easily offset by the fact that you're loading the SVGs from a server which introduces way more latency than rasterizing the SVG will, even more so if you consider the size difference between a rasterized PNG and a SVG(assuming you're not planning to create tiny textures from them).
So final verdict, go with SVG, its lossless and small aswell as resizable and editable from within client code. It also saves you from exporting your source assets to PNG everytime you change something.
Intro
I have a web service that returns a json result that contains an image path.
These images are not necessarily square images (e.g. 200px x 250px).
Problem
It seems non-square images are not supported for texture mapping. In order for the texture mapping to work I have to manually download the image, resize it, and use that image for the texture mapping (and it works).
Questions
A) Could there be a way to make three.js/webgl use non-square images for texture mapping?
B) Could there be a way to programmatically load & resize an image and subsequently load it for texture mapping?
Thanks all.
Possible Solution?
I found what could be a viable option. Let me know what you guys think of this.
Basically, I will load the remote image and draw to a Canvas element which is square in size. Then I can get the image from the canvas (.getImageData) and save it to my web server's image folder (if this cant be done then I can just keep the image on the canvas). Finally, load the image for texture mapping.
I know this is pretty vague and simplistic. But hey, simpler the better, right?
Will this work?
DON'T resize it in a non-conformal manner, just take a square section (e.g., if the image is 250 X 220, just chop out a 220 X 220 sub-image). The texture classification algorithm may very well depend upon angles and related features that your skew-by-resize may short-circuit.
Our line of business application uses a Word document as a template, fills in the pertinent information and converts it to PDF, which it returns to the user.
That all works fine except for one thing. We use an image of our company's logo on the lead page and in the footer. In one resolution (e.g. 100%), it looks fine. But at higher resolutions (e.g. 250%), it has several noticeable jaggies; the diagonals have noticeable ragged edges. Tweaking the image, we're able to make it look good at the higher zoom value, but then it looks terrible at lower zoom values.
Currently, we're using a PNG, but we've tried JPG and it doesn't improve the jaggy problem. In fact, it looks worse at higher resolution because of JPG compression. I think a vector image would solve the problem (and we have the logo in vector format), but I haven't found any vector formats that Word supports.
I don't really have any code to show, since we don't do anything with the image in the code: we just take the document and plug in our values, none of which touch the logo (the template already contains the image).
We are using Word 2013 (32-bit) on Windows 8.1 (though some of our developers use Windows 7). We use the .NET PdfDocument class to generate the PDF.
Any ideas on how to get Word to be better at retaining image quality? Or is this a PDF issue?
The suggestion by David van Driessche might still work, provided the right EMF is used. EMF files can contain both raster and vector data. With a raster EMF file, the same problem will present itself as it did with PNG or JPEG. Vector EMF embedded in Word files can scale very nicely, at least when zoomed in display, so it could also work with printing or converting to PDF.
Word supports both raster and vector objects within EMFs, so the secret is to use EMFs that only contain scalable objects like lines, curves and text when quality & scaling are both concerns.
I have posted sample files here to illustrate this for anyone wishing to see the difference.
Amin Dodin
As a part of our project we have to find the dimensions of a given object in a particular image ex- dimensions of a given sunken ship which is underwater. This is totally new to me so my friend told me that in matlab its possible. Kindly help me out
I think you should look into image blobs and Edge detection. That's where I would start
Are you already set on MatLab? If you can use C#, I would look into: AForge.NET Image processing library for C#:
http://www.aforgenet.com/projects/iplab/
I have used AForge before to identify "blobs" in images and perform other image processing operations.
If you have still not finalized on Matlab, then AForge.NET or Magick.NET from ImageMagick can be tried.
To identify the dimensions of the image, we have to think thru the manual process of identifying the same. How are we able to identify ship in water from an image? How is the object different from sorrounding area in the image?
From that, you may try to identify ship as a blob and work on the blob. Sometimes, you may not be able to identify ship as blob, probably due to noise of the sorrounding. Find means to remove that noise or differentiate the object further from sorrounding by errosion or dillation or combination.
I'm porting some CF 2.0 VB.Net apps to a newer version of a handset that has twice the screen resolution. So I have to double the dimensions of everything otherwise it all gets squished up into the top LH corner of the screen.
One screen had a bitmap which was 250K in size, and after I doubled the dimensions naturally it blew out to one MB. This isn't real good on a handheld, so I fired up irfanview and converted it to a .GIF. The .GIF was only 60KB in size, with no discernible change in the quality of the image.
To me, it seems a no-brainer : Convert all Bitmaps to Gif (or JPG) and get the same results for a fraction of the disk space (and probably quicker form loading times).
But does anyone know of a situation where you would use a bitmap in preference to a GIF/JPEG? I cannot find any.
I really can't think of any realistic example where you would prefer an bitmap to a GIF. Since GIF is a lossless format you loose no information when storing images. So after reading the file in your app you will have the same image data as if you have read a bitmap. And like you said: The file will be smaller and thus will probably will be read faster from disk.
JPEG is different because it's a lossy format, meaning you will lose information when storing images in it. You will need to decide if the loss of information is meaningful in your app.
Bitmaps would be preferable if and only if reading files from disk where faster than decompressing the file in memory.
And to be precise you would prefer bitmaps when storing images in main memory, so you can work easily on the data in your code. Which is actually what you most likely already have when you have loaded a file using an image library.
To cut a long story shorts, a BMP is stored as a series of pixels along with their colour. This is useful if you want to do such things as pattern recognition, movement detection and such like.
Bitmaps are typically used for their convenience - you can knock one up in paint without having specialist graphics software.