Using geometry to concat huge sizes of images (4000+) bugs out of order.
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
2 Attachments
#570 Using geometry to concat huge sizes of images (4000+) bugs out of order.
closed-invalid
5
2018-07-23
2018-07-16
No
I have 4000+ images in one folder which, if placed in a 64x64 grid, result in a map image.
Attached (unknown.png) is an image of how it looks after using:
gm montage -geometry 256x -tile x64 *.jpg map.jpg
All images are 256x256px in size and the grid is, as I said, 64x64 big.
The other attached image (explorer.png) is a screenshot of the Windows Explorer with the folder I mentioned.
Can't attach the whole image folder though.
On Mon, 16 Jul 2018, Hahah Really wrote:
I am confused by the two images you attached. You say that
"explorer.PNG" is what is shown by a Windows app and "unknown.png" is
produced by GraphicsMagick?
Are you running GraphicsMagick on a Windows system? If so is it a
GraphicsMagick release build or some other build such as Cygwin?
What GraphicsMagick release version is being used?
It would be wise to fully specify the -geometry and -tile geometry
arguments (e.g. 256x256 and 64x64) rather than using a sloppy
specification.
If you are actually using Windows, then your specification becomes
subject to Windows maximum command-line length, which is very small,
and unlikely to support 4000 files. If you put double quotes around
the wildcard expression (e.g. "*.jpg") then GraphicsMagick will be
responsible for producing the file list rather than the Windows
operating system.
If this was done on some other operating system such as Linux, then it
is useful to know that the wildcard expansion done by the operating
system is not necessarily sorted in any particular order. This might
apply to Windows as well.
While it it is intended to document a C++ programming interface, this
documentation for Montage is useful to understand how the montage
parameters work: http://www.graphicsmagick.org/Magick++/Montage.html
Bob
Hey, so yeah, I didn't mention all info I had, sorry.
1. explorer.PNG shows just a bit of my folder where the 4000+ images are. Just to give you an idea how they are called/sorted and how their content looks.
2. I'm on Windows 7 64bit Home Premium, executing the command directly from the command line.
3. unknown.png is a screenshot of what was produced by GraphicsMagick.
4. I have the GM version 1.3.30 2018-06-23 Q8
5. I read 256x is the same as 256x256 so I tested both and both worked in the same way.
6. I noticed in smaller tests that GM tends to use the images in an alphabetical order so I assumed it would do that in a larget scale, too. It even does that, from time to time. As you can see in the result screenshot. There are big chunks which are completely correct but then there are those stripes of random chunks of the actual big image across the result. So it uses the right order of the images for the most part of the image.
P.s. I tested
gm montage -geometry 256x256 -tile 64x64 "*.jpg" "map.jpg"now and it still doesn't work. Exactly the same result.P.p.s. The original images have names like x-y.jpg and my download script changes the coordinates to y-x.jpg (or the other way round, can't remember). So the only thing GraphicsMagick should be able to "do wrong" is flip the image, I hope my math is correct. ^^'
On Wed, 18 Jul 2018, Hahah Really wrote:
Try doing
gm identify "*.jpg"
and see what the order of the files it displays is. Is it similar to
montage, or different?
The large image sometimes painted in the montage sounds like somehow
the resize (due to -geometry) is failing to reduce the image
dimensions.
For the special case of JPEG input files you may see much better
performance if you do
gm montage -size 256x256 -geometry 256x256 -tile 64x64 "*.jpg" "map.jpg"
because this should cause the JPEG library to produce a reduced image
from the start (likely somewhat larger than 256x256) so that much less
resources are consumed. If the thumbnails do not look sharp enough,
then double the request to 512x512 so that there are more starting
pixels to resize from.
Since you are using a 64-bit operating system, did you install the
64-bit version of the software (better) or did you install the 32-bit
version?
Bob
First of all, the images are all 256x256 pixels. Your own version of the command did not change anything. I'm using the 64bit program, yes. But the "identify" command was very helpful!
Gosh, I'm dumb. Changing it to two-digit worked. Thank you!
Reporter has admitted to cockpit error.