However when I now call this script it tells me:Īm I doing something wrong ? Is there anything you have to consider while trying to runs such script ?īTW: AWESOME feedback ! Never thought to get so many productive answers. I have ImageMagick installed on my machine, put the bat (this script you wrote) and the image file in the same directory. This only happens to some PNG files and I can't figure out what is causing it. I tried to get that command working under windows, however it will do me no good. 1 Using GraphicsMagick to read in a PNG file and write it out under a different name is causing the file size to increase by more than double. Regardless a center crop does let you see the hexagonal tile pattern that is present, and can more easily determine the size, relative offsets, and orientation of those tiles for extraction, rotation and blending.Īnyone like to give the extraction and blending step a go? In this case you want a high entropy sub-image near the center of the original image, rather than the edge as I needed in finding overlaps. Finding such high entropy sub-images was part of my work in another topic "Overlapping Images", and this is highly relevent. A smaller sub-image will generate a larger 'map' image, and (cross fingers) be a bit faster in sub-image searching. One pre-step may be to first determine a high entropy area so that you can extract a smaller sub-image from the original image, and still be sure you file matching tiling points. The bright spot is of course the offset of the 50% centered crop relative to the top left corner, which works out to be the center of the 'quarter image map'. Time: 1 minute 53.4 seconds (not surprising same image sizes) Fred?Ĭode: Select all time convert tiles_closeup_sm.jpg \( +clone -gravity center -crop 50% \) miff:- |Ĭonvert -delete 0 -alpha off tile_search_result_3.png As would any rotation correction, and edge blending It does NOT try to center the main part (high entropy) of the tile in the center of the tile, so that the low entropy areas (background areas) are used along the borders of the tile.Įxtracting the tile appropriatally would be the next step. this time determination only determined the size and relative offsets of the tile pattern. Fred, can you provide an equivalent FFT example? You can get the same result with "composite Difference" using a difference of individual color channels, which is then squared, added and square-root.įor large image compares a FFT convolution would be better. The result is also not just a simple difference of grayscale values, but the length of the color different vector (RMSE), as such it should work well even for images with little grayscale variance. I re-processed the above image to simply turn off alpha channel. WARNING: the image for some reason contains a random transparency! This is a bug, as the gray scale map should not contain any transparency.
But even so, on my 8 core machine completed in - 11.5 seconds! The last just saves the second (map) image. then it is compared at every position over a quarter of the image, and produces a similar map. For fun, let's pretend it repeats at 128 vertically.Ĭode: Select all convert "Castillo 001.gif" \( +clone -crop 50%x+0+0 \) miff:- |Ĭonvert -delete 0 tile_search_result.png Rem So we can crop horizontally at offset 128 for a repeating pattern. Rem What is the grey value at this offset?įor /F "eol=# tokens=3 delims=,() " %%b in (gray.txt) do set grey=%%bĮcho grey !MinGray! at offset !OffsAtMin!Įcho grey %MinGray% at offset %OffsAtMin% Also there seems to be an issue with the alpha channel for PNG files If the image has transparency in it, reducing colors replaces these colors with transparent with imagemagick it does not do this.Code: Select all setlocal enabledelayedexpansionįOR /F "tokens=1,2" %%i IN ('%IM%identify -ping -format "%%w %%h" %SRC%') DO ( The problem is when GraphicsMagick reduces colors it always reduces to at least 255, so you can't set the number of colors to 300 for example. To determine this information I am doing the following gm identify -format "file_size:%b,unique_colors:%k,bit_depth:%q" myImage.pngįor my image this returns file_size:100.7k,unique_colors:13455,bit_depth:8 Obviously for the best image quality/size ratio you cant just reduce the image depth or number of colors without knowing the current depth and number of colors. colors 50 reduces the number of colors in the image to 50, this is the only way to really reduce the size of a image stored in a lossless format like PNG or GIF. depth 8 is probably unnecessary as most PNG files are already depth 8. +dither stops any dithering of the image when the colors are reduced.
I have done this to my PNG and GIF files to reduce their size: gm convert myImage.png +dither -depth 8 -colors 50 myImage.png For me it just made the file size bigger when used on PNG's and GIF's. The quality operator doesn't properly work for any image other than JPEG's. Unfortunately there doesn't seem to be many people out there with a good knowledge of GraphicsMagick.
Looks like you and me are looking for the same answer.
0 kommentar(er)
