I have multiple rectangles and they all share the same spot color. Is there a way to merge / group them into one vector object so the generated pdf has smaller size?
If you are creating the document from scratch, then the answer is trivial: yes!
It's sufficient to draw all the paths of the rectangles that share the same spot color and then use the operator that fills, stroke or fills & strokes the paths.
If you are talking about optimizing an existing PDF document, you're in for some heavy programming. You would need to parse every content stream looking for rectangle operators (assuming that the rectangles aren't drawn using move-to and line-to operators), check where these shapes are filled and/or stroked, and then rearrange all these operators. This would require a lot of thought. I would know where to begin, but I can't predict where it would end. Maybe it would turn out that it makes more sense to define a single rectangle as a Form XObject and reuse that single external object, maybe not. It's hard to predict.
Moreover: you are talking about operators in a stream. These streams are compressed anyway, so you may be doing a lot of work to gain only a very small decrease in size.
I would say: what you are asking for may be possible, but it is unclear why you would do this, because it would result in only a limited decrease in file size.
If size is an issue, there may be other places where you are "wasting bytes" that could result in a more desirable result. I am very curious to hear why you think the rectangles using spot colors are the culprit. You are reusing the spot color instance, aren't you? If you are creating a new spot color instance for every rectangle you draw, you have found the real culprit and you can avoid having to group the rectangles.
Related
I'm trying to display images in a grid layout that is 4 units wide by an arbitrary number of units high.
Each image in the grid may be 1x1, 1x2, 2x1 or 2x2 units. I'm also using jQuery masonry to try and eliminate some gaps in the layout.
The size an image is displayed at (1x1, 2x2, etc.) is a "preferred" size based on its dimensions.
I'm thinking that the easiest way to eliminate gaps in the layout would be to display certain images in the layout at sizes other than their preferred size. How can I do this algorithmically, maintaining the largest number of photos that are displayed at their preferred size, while overriding for those that are determined to be necessary for a gapless layout.
A visual example; I want to turn this:
into something like what they have on this website: http://500px.com/
Just a start: I think this is an instance of bin packing which is NP-complete in the general case (see this pdf). Might be helpful to start searching for things in those terms... this is not a complete answer by any means.
The simplest thing you can do is group pairs of 1x2s together, pairs of 2x1s together, and quadruples of 1x1s together. Laying out lots of 2x2s is then easy, and only the odd-images out will need to be resized. This (or something like it) is almost certainly what 500px.com does.
I suspect this solution doesn't really jive with your "laid out left-to-right, top-to-bottom" restriction. But I'm not sure what that restriction means, exactly. Perhaps if you could make it clear what that means we could help you better.
I want to compare two vector images (say SVG) and see how close they are.
Basically, I want to test the correctness of a tracing algorithm which converts raster images to vector format.
The way I am thinking to test this algorithm is:
-Take some vector images.
-Rasterize the vector image to png.
-Feed the above png to tracing algorithm.
-Compare the output of tracing program (which is SVG) with the original one.
While I know there are some metrices for raster images like RMSE (in imagemagick), I am not familiar if there are some standard metrices for vector formats.
I can think of some simple ones like number of arcs, lines, curves etc. But these can not detect the deviation in geometry and colors. Could someone suggest a good standard metric or some other approach to this problem.
I am not aware of standard metrics for this, but I do have a pointer that I hope will be helpful.
The Batik project uses a set of tools to test that its rendering of SVG documents does not diverge excessively from a set of reference images. My understanding is that it essentially rasterises the SVG and performs a pixel-based diff of the two images to see how they differ. It ought to be smart enough to overlook unavoidable differences that may stem for instance from subtle differences in antialiasing.
You can read more about it (especially the SVGRenderingAccuracyTest section) at: http://jpfop.sourceforge.net/jaxml-batik/html-docs/test.html.
That, of course, means that you'll be doing raster comparisons and not vector comparisons. Vector comparisons in your case will be fiendishly difficult because entirely different curves may produce extremely similar rendering — something which I assume is fine. What's more, the input may have a shape that is hidden behind another, making it impossible for the output to possibly guess what it is. The output will therefore end up showing as entirely wrong even though it may produce a pixel-perfect equivalent rendering.
If however you do wish to perform vector comparisons (perhaps your data is constrained in a manner that makes this more viable) the simplest may be to first normalise both SVGs (convert all shapes to paths, eliminate all metadata, apply inheritance of all properties and normalise their values, normalise path data to always use the same form, etc.) and use this for two purposes: first, to look at the diffs in the normalised tree structure. That should already give you some useful information. Second, if you feel brave, measure the surface of the difference between individual curves. I would think twice about embarking on the latter though, because it is likely to give you lots of false negatives.
General: I'm hoping that the use-case I'm about to describe is a simple case of an optical flow problem and since I don't have much knowledge on the subject, I was wondering if anyone has any suggestions on how I can approach solving my problem.
Research I've already done: I have began reading the High Accuracy Optical Flow Estimation Based on a Theory for Warping paper and am planning on looking over the Particle Video paper. I have found a MATLAB High Accuracy Optical Flow implementation of optical flow. However, the papers (and the code) seem to describe concepts that are very involved and may require a lot of time for me to dig in and understand. I am hoping that the solution to my problem may be more simple.
Problem: I have a sequence of images. The images depict a material breakage process, where the material and background are black and the cracks are white. I am interested in traversing the sequence of images in reverse in an attempt to map all of the cracks that have formed in the breakage process to the first black image. You can think of the material as a large puzzle and I am trying to put the pieces back together in the reverse order that they broke.
In each image, there can be some cracks that are just emerging and/or some cracks that have been fully formed (and thus created a fragment). Throughout the breakage process, some fragments may separate and break further. The fragments can also move farther away from one another (the change is slight between subsequent frames).
Desired Output: All of the cracks/lines in the sequence mapped to the first image in the sequence.
Additional Notes: Images are available in grayscale format (i.e. original) as well as in binary format, where the cracks have been outlined in white and the background is completely black. See below for some image examples.
The top row shows the original images and the bottom row shows the binary images. As you can see, the crack that goes down the middle grows wider and wider as the image sequence progresses. Thus, the bottom crack moves together with the lower fragment. When traversing the sequence in reverse, I hope to algorithmically realize that the middle crack comes together as one (and map it correctly to the first image), and also map the bottom crack correctly, keeping its correct correspondence (size and position) with the bottom fragment.
A sequence typically contains about 30~40 images, so I've just shown the beginning subset. Also, although these images don't show it, it is possible that a particular image only contains the beginning of the crack (i.e. its initial appearance) and in subsequent images it gets longer and longer and may join with other cracks.
Language: Although not necessary, I would like to implement the solution using MATLAB (just because most of the other code that relates to the project has been done in MATLAB). However, if OpenCV may be easier, I am flexible in my language/library usage.
Any ideas are greatly appreciated.
Traverse forward rather than reverse, and don't use optical flow. Use the fracture lines to segment the black parts, track the centroid of each black segment over time. Whenever a new fracture line appears that cuts across a black segment, split the segment into two and continue tracking each segment separately.
From this you should be able to construct a tree structure representing the segmentation of the black parts over time. The fracture lines can be added as metadata to this tree, perhaps assigning fracture lines to the segment node in which they first appeared.
I would advise you to follow your initial idea of backtracking the cracks. Yo kind of know how the cracks look like so you can track all the points that belong to the crack. You just track all the white points with an optical flow tracker, start with Lukas-Kanade tracker and see where you get. The high-accuracy optical flow method is a global one and more general, I'll track all the pixels in the image trying to keep some smoothness everywhere. The LK is a local method that will just use a small window around each point to do the tracking. The problem is that appart from the cracks all the pixels are plain black so nothing to track there, you'll just waist time trying to track something that you can't track and you don't need to track.
If lines are very straight you might end up with what's called the aperture problem and you'll get inaccurate results. You can also try some shape fitting/deformation based on snakes.
I agree to damian. Most optical flow methods like the HAOF rely on the first-order taylor approximation of the intensity constancy constrian equation I(x,t)=I(x+v,t+dt). That mean the solution depends on image derivatives where the gradient determine the motion vector magnitude and angle i.e. you need a certain amount of texture. However the very low texture of your non-binarised images could be enough. You could try histogram equalization to increase the contrast of your input data but it is important to apply the same transformation for both input images. e.g. as follows:
cv::Mat equalizeMat(grayInp1.rows, grayInp1.cols * 2 , CV_8UC1);
grayInp1.copyTo(equalizeMat(cv::Rect(0,0,grayInp1.cols,grayInp1.rows)));
grayInp2.copyTo(equalizeMat(cv::Rect(grayInp1.cols,0,grayInp2.cols,grayInp2.rows)));
cv::equalizeHist(equalizeMat,equalizeMat);
equalizeMat(cv::Rect(0,0,grayInp1.cols,grayInp1.rows)).copyTo(grayInp1);
equalizeMat(cv::Rect(grayInp1.cols,0,grayInp2.cols,grayInp2.rows)).copyTo(grayInp2);
// estimate optical flow
I'm trying to generate a scrolling starfield for a game with C++ and SDL. I'm using a simple, naive algorithm that just creates a lot of white pixels on black backround. However, this "starfield" looks too unnatural - probably because of the random number generator's poor quality (I use the rand() function).
Are there any special algorithms for generating starfields that look more or less realistic?
Thanks.
There's always this classic. Highlights:
[...] imagine the stars to be points in 3D space, all of them moving towards the viewer, along the Z-axis. At each time step, the 3D coordinates of the stars will be projected onto the screen, and displayed.
For a smoother effect, we can make the stars black when they first appear (so you don't notice them) then get brighter as they get closer.
There are two ways the sense of vastness can be modeled. The first is simply to model a huge area of space, which is impractical to say the least. The second is to make the stars move with a range of velocities.
I found this useful tutorial a while ago on creating a 'realistic' star field. It's not C++, but it should be easily adaptable once you get the idea.
You could use Lloyd's algorithm to relax the random points and make them semi-random. I read this idea in a map generator but it probably can be used do create an eventually distributed star field too.
You probably don't want it to be truly random. You will end up with blobs of pixels in some places when you really want individual pixels scattered around. Your best bet would probably be to code a smaller section and then just repeat it over and over to get the full starfield look.
I have nothing useful to do and was playing with jigsaw puzzle like this:
alt text http://manual.gimp.org/nl/images/filters/examples/render-taj-jigsaw.jpg
and I was wondering if it'd be possible to make a program that assists me in putting it together.
Imagine that I have a small puzzle, like 4x3 pieces, but the little tabs and blanks are non-uniform - different pieces have these tabs in different height, of different shape, of different size. What I'd do is to take pictures of all of these pieces, let a program analyze them and store their attributes somewhere. Then, when I pick up a piece, I could ask the program to tell me which pieces should be its 'neighbours' - or if I have to fill in a blank, it'd tell me how does the wanted puzzle piece(s) look.
Unfortunately I've never did anything with image processing and pattern recognition, so I'd like to ask you for some pointers - how do I recognize a jigsaw piece (basically a square with tabs and holes) in a picture?
Then I'd probably need to rotate it so it's in the right position, scale to some proportion and then measure tab/blank on each side, and also each side's slope, if present.
I know that it would be too time consuming to scan/photograph 1000 pieces of puzzle and use it, this would be just a pet project where I'd learn something new.
Data acquisition
(This is known as Chroma Key, Blue Screen or Background Color method)
Find a well-lit room, with the least lighting variation across the room.
Find a color (hue) that is rarely used in the entire puzzle / picture.
Get a color paper that has that exactly same color.
Place as many puzzle pieces on the color paper as it'll fit.
You can categorize the puzzles into batches and use it as a computer hint later on.
Make sure the pieces do not overlap or touch each other.
Do not worry about orientation yet.
Take picture and download to computer.
Color calibration may be needed because the Chroma Key background may have upset the built-in color balance of the digital camera.
Acquisition data processing
Get some computer vision software
OpenCV, MATLAB, C++, Java, Python Imaging Library, etc.
Perform connected-component on the chroma key color on the image.
Ask for the contours of the holes of the connected component, which are the puzzle pieces.
Fix errors in the detected list.
Choose the indexing vocabulary (cf. Ira Baxter's post) and measure the pieces.
If the pieces are rectangular, find the corners first.
If the pieces are silghtly-off quadrilateral, the side lengths (measured corner to corner) is also a valuable signature.
Search for "Shape Context" on SO or Google or here.
Finally, get the color histogram of the piece, so that you can query pieces by color later.
To make them searchable, put them in a database, so that you can query pieces with any combinations of indexing vocabulary.
A step back to the problem itself. The problem of building a puzzle can be easy (P) or hard (NP), depending of whether the pieces fit only one neighbour, or many. If there is only one fit for each edge, then you just find, for each piece/side its neighbour and you're done (O(#pieces*#sides)). If some pieces allow multiple fits into different neighbours, then, in order to complete the whole puzzle, you may need backtracking (because you made a wrong choice and you get stuck).
However, the first problem to solve is how to represent pieces. If you want to represent arbitrary shapes, then you can probably use transparency or masks to represent which areas of a tile are actually part of the piece. If you use square shapes then the problem may be easier. In the latter case, you can consider the last row of pixels on each side of the square and match it with the most similar row of pixels that you find across all other pieces.
You can use the second approach to actually help you solve a real puzzle, despite the fact that you use square tiles. Real puzzles are normally built upon a NxM grid of pieces. When scanning the image from the box, you split it into the same NxM grid of square tiles, and get the system to solve that. The problem is then to visually map the actual squiggly piece that you hold in your hand with a tile inside the system (when they are small and uniformly coloured). But you get the same problem if you represent arbitrary shapes internally.