Legacy ImageMagick Discussions Archive

Use https://github.com/ImageMagick/ImageMagick/discussions instead.
https://imagemagick.com/discourse-server/

Equally sized crop problem

https://imagemagick.com/discourse-server/viewtopic.php?t=18322

Page 1 of 2

Equally sized crop problem

Posted: 2011-03-18T11:30:01-07:00
by cogito
Hi,
I'm trying to use convert -crop to create equally sized tiles (for some sort of mapping software). The problem is that with some images I can't get 10x6@ tiles, for some images I can't even do 9x6@. When I run some math and do the same crop with variables (width and height) it's working fine.
Any clue?

thanks,
Slawek

Re: Equally sized crop problem

Posted: 2011-03-18T13:12:59-07:00
by fmw42
do those images already have a virtual canvas? if so right after reading the image add +repage, then -crop etc.

can you post a link to one of the images that fails?

Re: Equally sized crop problem

Posted: 2011-07-22T01:55:48-07:00
by michele.franzin
got the same problem (prepend +repage doesn't work). here's the output

Code: Select all

michele@prisca:~/dev/dxf2map$ convert -verbose +repage -crop 10x2@ lod_0/layer.png png32:lod_0/layer_%d.png
lod_0/layer.png PNG 10944x4174 10944x4174+0+0 8-bit DirectClass 1.261MB 1.330u 0:01.329
lod_0/layer.png=>lod_0/layer_0.png[0] PNG 10944x4174=>1094x2087 10944x4174+0+0 8-bit TrueColorMatte DirectClass 12.3KB 0.570u 0:00.380
lod_0/layer.png=>lod_0/layer_1.png[1] PNG 10944x4174=>1095x2087 10944x4174+1094+0 8-bit TrueColorMatte DirectClass 36.9KB 0.810u 0:00.630
lod_0/layer.png=>lod_0/layer_2.png[2] PNG 10944x4174=>1094x2087 10944x4174+2189+0 8-bit TrueColorMatte DirectClass 49.2KB 1.040u 0:00.869
lod_0/layer.png=>lod_0/layer_3.png[3] PNG 10944x4174=>1095x2087 10944x4174+3283+0 8-bit TrueColorMatte DirectClass 73.7KB 1.260u 0:01.099
lod_0/layer.png=>lod_0/layer_4.png[4] PNG 10944x4174=>1094x2087 10944x4174+4378+0 8-bit TrueColorMatte DirectClass 111KB 1.490u 0:01.340
lod_0/layer.png=>lod_0/layer_5.png[5] PNG 10944x4174=>1094x2087 10944x4174+5472+0 8-bit TrueColorMatte DirectClass 61.4KB 1.730u 0:01.570
lod_0/layer.png=>lod_0/layer_6.png[6] PNG 10944x4174=>1095x2087 10944x4174+6566+0 8-bit TrueColorMatte DirectClass 45.1KB 1.960u 0:01.809
lod_0/layer.png=>lod_0/layer_7.png[7] PNG 10944x4174=>1094x2087 10944x4174+7661+0 8-bit TrueColorMatte DirectClass 152KB 2.190u 0:02.060
lod_0/layer.png=>lod_0/layer_8.png[8] PNG 10944x4174=>1095x2087 10944x4174+8755+0 8-bit TrueColorMatte DirectClass 1a35KB 2.440u 0:02.320
lod_0/layer.png=>lod_0/layer_9.png[9] PNG 10944x4174=>1094x2087 10944x4174+9850+0 8-bit TrueColorMatte DirectClass 123KB 2.700u 0:02.589
second row missing!! same result with 11x2@ *but* below 9x?@ and with 12x?@ and upper works fine

Code: Select all

michele@prisca:~/dev/dxf2map$ convert -verbose +repage -crop 12x2@ lod_0/layer.png png32:lod_0/layer_%d.png
lod_0/layer.png PNG 10944x4174 10944x4174+0+0 8-bit DirectClass 1.261MB 1.320u 0:01.319
lod_0/layer.png=>lod_0/layer_0.png[0] PNG 10944x4174=>912x2087 10944x4174+0+0 8-bit TrueColorMatte DirectClass 8.19KB 0.750u 0:00.450
lod_0/layer.png=>lod_0/layer_1.png[1] PNG 10944x4174=>912x2087 10944x4174+912+0 8-bit TrueColorMatte DirectClass 24.6KB 0.950u 0:00.649
lod_0/layer.png=>lod_0/layer_2.png[2] PNG 10944x4174=>912x2087 10944x4174+1824+0 8-bit TrueColorMatte DirectClass 41KB 1.140u 0:00.859
lod_0/layer.png=>lod_0/layer_3.png[3] PNG 10944x4174=>912x2087 10944x4174+2736+0 8-bit TrueColorMatte DirectClass 41KB 1.330u 0:01.060
lod_0/layer.png=>lod_0/layer_4.png[4] PNG 10944x4174=>912x2087 10944x4174+3648+0 8-bit TrueColorMatte DirectClass 86KB 1.530u 0:01.259
lod_0/layer.png=>lod_0/layer_5.png[5] PNG 10944x4174=>912x2087 10944x4174+4560+0 8-bit TrueColorMatte DirectClass 81.9KB 1.730u 0:01.460
lod_0/layer.png=>lod_0/layer_6.png[6] PNG 10944x4174=>912x2087 10944x4174+5472+0 8-bit TrueColorMatte DirectClass 49.2KB 1.930u 0:01.670
lod_0/layer.png=>lod_0/layer_7.png[7] PNG 10944x4174=>912x2087 10944x4174+6384+0 8-bit TrueColorMatte DirectClass 41KB 2.130u 0:01.879
lod_0/layer.png=>lod_0/layer_8.png[8] PNG 10944x4174=>912x2087 10944x4174+7296+0 8-bit TrueColorMatte DirectClass 41KB 2.320u 0:02.079
lod_0/layer.png=>lod_0/layer_9.png[9] PNG 10944x4174=>912x2087 10944x4174+8208+0 8-bit TrueColorMatte DirectClass 201KB 2.550u 0:02.320
lod_0/layer.png=>lod_0/layer_10.png[10] PNG 10944x4174=>912x2087 10944x4174+9120+0 8-bit TrueColorMatte DirectClass 94.2KB 2.750u 0:02.529
lod_0/layer.png=>lod_0/layer_11.png[11] PNG 10944x4174=>912x2087 10944x4174+10032+0 8-bit TrueColorMatte DirectClass 77.8KB 2.950u 0:02.740
lod_0/layer.png=>lod_0/layer_12.png[12] PNG 10944x4174=>912x2087 10944x4174+0+2087 8-bit TrueColorMatte DirectClass 8.19KB 3.100u 0:02.899
lod_0/layer.png=>lod_0/layer_13.png[13] PNG 10944x4174=>912x2087 10944x4174+912+2087 8-bit TrueColorMatte DirectClass 12.3KB 3.300u 0:03.109
lod_0/layer.png=>lod_0/layer_14.png[14] PNG 10944x4174=>912x2087 10944x4174+1824+2087 8-bit TrueColorMatte DirectClass 16.4KB 3.480u 0:03.299
lod_0/layer.png=>lod_0/layer_15.png[15] PNG 10944x4174=>912x2087 10944x4174+2736+2087 8-bit TrueColorMatte DirectClass 16.4KB 3.670u 0:03.500
lod_0/layer.png=>lod_0/layer_16.png[16] PNG 10944x4174=>912x2087 10944x4174+3648+2087 8-bit TrueColorMatte DirectClass 24.6KB 3.860u 0:03.700
lod_0/layer.png=>lod_0/layer_17.png[17] PNG 10944x4174=>912x2087 10944x4174+4560+2087 8-bit TrueColorMatte DirectClass 28.7KB 4.050u 0:03.889
lod_0/layer.png=>lod_0/layer_18.png[18] PNG 10944x4174=>912x2087 10944x4174+5472+2087 8-bit TrueColorMatte DirectClass 16.4KB 4.230u 0:04.079
lod_0/layer.png=>lod_0/layer_19.png[19] PNG 10944x4174=>912x2087 10944x4174+6384+2087 8-bit TrueColorMatte DirectClass 16.4KB 4.430u 0:04.289
lod_0/layer.png=>lod_0/layer_20.png[20] PNG 10944x4174=>912x2087 10944x4174+7296+2087 8-bit TrueColorMatte DirectClass 16.4KB 4.620u 0:04.490
lod_0/layer.png=>lod_0/layer_21.png[21] PNG 10944x4174=>912x2087 10944x4174+8208+2087 8-bit TrueColorMatte DirectClass 73.7KB 4.830u 0:04.710
lod_0/layer.png=>lod_0/layer_22.png[22] PNG 10944x4174=>912x2087 10944x4174+9120+2087 8-bit TrueColorMatte DirectClass 111KB 5.050u 0:04.929
lod_0/layer.png=>lod_0/layer_23.png[23] PNG 10944x4174=>912x2087 10944x4174+10032+2087 8-bit TrueColorMatte DirectClass 176KB 5.280u 0:05.170

Re: Equally sized crop problem

Posted: 2011-07-22T09:18:39-07:00
by fmw42
Proper IM syntax is to put the input before (most) options (except those that have to do with reading). So you need to do

convert image <options> output


In your case, it appears you want to crop the image into multiple sections, so the +repage is optional if you don't want to put the pieces back together.

convert image -crop WxH@ result_%d.png

should work. however, the equal size option was added after IM v6.6.1. You don't mention what version of IM you are using?

If the above does not work, post a link to one of your images.


Actually I am getting error messages on IM 6.7.1.0 Q16 Mac OSX Tiger

convert rose: -crop '20x20@' rose_%d.png
convert: geometry does not contain image `ROSE' @ warning/transform.c/CropImage/622.

Re: Equally sized crop problem

Posted: 2011-07-22T11:13:34-07:00
by fmw42
see bug report reply at viewtopic.php?f=3&t=19140

Re: Equally sized crop problem

Posted: 2011-09-15T05:40:56-07:00
by michele.franzin
I'm using version

Code: Select all

harakei:tmp$ convert --help
Version: ImageMagick 6.7.2-0 2011-08-28 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP
under OSX lion 10.7 but problem still exists:

Code: Select all

harakei:tmp$ convert logo: -verbose +repage -crop '11x2@' tiles_%d.png
logo:=>tiles_%d.png[0] GIF 640x480=>58x240 640x480+0+0 8-bit PseudoClass 256c 0.020u 0:00.009
logo:=>tiles_%d.png[1] GIF 640x480=>58x240 640x480+58+0 8-bit PseudoClass 256c 0.020u 0:00.019
logo:=>tiles_%d.png[2] GIF 640x480=>59x240 640x480+116+0 8-bit PseudoClass 256c 0.020u 0:00.019
logo:=>tiles_%d.png[3] GIF 640x480=>58x240 640x480+175+0 8-bit PseudoClass 256c 0.030u 0:00.019
logo:=>tiles_%d.png[4] GIF 640x480=>58x240 640x480+233+0 8-bit PseudoClass 256c 0.030u 0:00.019
logo:=>tiles_%d.png[5] GIF 640x480=>58x240 640x480+291+0 8-bit PseudoClass 256c 0.030u 0:00.029
logo:=>tiles_%d.png[6] GIF 640x480=>58x240 640x480+349+0 8-bit PseudoClass 256c 0.030u 0:00.029
logo:=>tiles_%d.png[7] GIF 640x480=>58x240 640x480+407+0 8-bit PseudoClass 256c 0.030u 0:00.039
logo:=>tiles_%d.png[8] GIF 640x480=>59x240 640x480+465+0 8-bit PseudoClass 256c 0.030u 0:00.029
logo:=>tiles_%d.png[9] GIF 640x480=>58x240 640x480+524+0 8-bit PseudoClass 256c 0.030u 0:00.029
logo:=>tiles_%d.png[10] GIF 640x480=>58x240 640x480+582+0 8-bit PseudoClass 256c 0.030u 0:00.029
harakei:tmp$
Am I wrong or the command -crop '11x2@' should generate 22 images? ...this happens only with 11x width :-(

Re: Equally sized crop problem

Posted: 2011-09-15T09:59:47-07:00
by fmw42
I am getting the same result and also with

convert logo: -crop 11x2@ +repage logo_%d.png

only 11 images and not 22. Seems like a bug to me.

IM 6.7.2.6 Q16 Mac OSX Tiger

Re: Equally sized crop problem

Posted: 2011-09-15T18:06:58-07:00
by anthony
fmw42 wrote:I am getting the same result and also with

convert logo: -crop 11x2@ +repage logo_%d.png

only 11 images and not 22. Seems like a bug to me.

IM 6.7.2.6 Q16 Mac OSX Tiger
In fact the last number seems to be currently ignored! It was not doing that when I finished creating the operator Must be a recent bug.

Also only seems to do it when the first number is 11! 10 works as expected, as does 12!
actually it also fails if the first number is 22, or even 111!
Works fine is the first number is 110, 122, 212, but then fails if the first number is 222, 221, 121 or 211!
Something is very screwy!

The weird thing is, is that teh image sizes being produces IS correct, just the number of images being produced is wrong!

Re: Equally sized crop problem

Posted: 2011-09-15T18:39:01-07:00
by magick
We can reproduce the problem and have a patch. Look for it in ImageMagick 6.7.2-7 Beta by sometime tomorrow. Thanks.

Re: Equally sized crop problem

Posted: 2011-12-01T03:53:25-07:00
by michele.franzin
Now problem seems to be the tile sizes; I'm trying to crop an images who's dimension are a multiple of cropping columns.
In the example below I want 20 tiles (5x4) from a 1250x1105 image. This should end up in 20 equally width-sized tiles (250px).

Code: Select all

$> conver -version
Version: ImageMagick 6.7.3-9 2011-11-29 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP

$> convert -verbose svg/layer.png -crop 5x4@ +repage +adjoin png32:svg/layer_%d.png
svg/layer.png PNG 1250x1105 1250x1105+0+0 8-bit DirectClass 143KB 0.040u 0:00.059
svg/layer.png=>svg/layer_0.png[0] PNG 1250x1105=>250x277 8-bit DirectClass 0.030u 0:00.030
svg/layer.png=>svg/layer_1.png[1] PNG 1250x1105=>251x277 8-bit DirectClass 0.030u 0:00.030
svg/layer.png=>svg/layer_2.png[2] PNG 1250x1105=>250x277 8-bit DirectClass 0.040u 0:00.039
svg/layer.png=>svg/layer_3.png[3] PNG 1250x1105=>251x277 8-bit DirectClass 8.19KB 0.040u 0:00.060
svg/layer.png=>svg/layer_4.png[4] PNG 1250x1105=>248x277 8-bit DirectClass 12.3KB 0.060u 0:00.070Version
svg/layer.png=>svg/layer_5.png[5] PNG 1250x1105=>250x277 8-bit DirectClass 0.070u 0:00.070
svg/layer.png=>svg/layer_6.png[6] PNG 1250x1105=>251x277 8-bit DirectClass 4.1KB 0.080u 0:00.079
svg/layer.png=>svg/layer_7.png[7] PNG 1250x1105=>250x277 8-bit DirectClass 0.090u 0:00.089
svg/layer.png=>svg/layer_8.png[8] PNG 1250x1105=>251x277 8-bit DirectClass 4.1KB 0.100u 0:00.099
svg/layer.png=>svg/layer_9.png[9] PNG 1250x1105=>248x277 8-bit DirectClass 8.19KB 0.110u 0:00.120
svg/layer.png=>svg/layer_10.png[10] PNG 1250x1105=>250x276 8-bit DirectClass 4.1KB 0.120u 0:00.120
svg/layer.png=>svg/layer_11.png[11] PNG 1250x1105=>251x276 8-bit DirectClass 8.19KB 0.130u 0:00.140
svg/layer.png=>svg/layer_12.png[12] PNG 1250x1105=>250x276 8-bit DirectClass 4.1KB 0.140u 0:00.149
svg/layer.png=>svg/layer_13.png[13] PNG 1250x1105=>251x276 8-bit DirectClass 8.19KB 0.150u 0:00.160
svg/layer.png=>svg/layer_14.png[14] PNG 1250x1105=>248x276 8-bit DirectClass 12.3KB 0.160u 0:00.169
svg/layer.png=>svg/layer_15.png[15] PNG 1250x1105=>250x275 8-bit DirectClass 4.1KB 0.170u 0:00.179
svg/layer.png=>svg/layer_16.png[16] PNG 1250x1105=>251x275 8-bit DirectClass 4.1KB 0.180u 0:00.189
svg/layer.png=>svg/layer_17.png[17] PNG 1250x1105=>250x275 8-bit DirectClass 12.3KB 0.200u 0:00.210
svg/layer.png=>svg/layer_18.png[18] PNG 1250x1105=>251x275 8-bit DirectClass 8.19KB 0.210u 0:00.219
svg/layer.png=>svg/layer_19.png[19] PNG 1250x1105=>248x275 8-bit DirectClass 8.19KB 0.220u 0:00.230
width sizes vari from 248 to 251 :-( but same conversion done with ImageMagick 6.6.0 works fine

Code: Select all

$> convert -version
Version: ImageMagick 6.6.0-4 2011-06-15 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP

$> convert -verbose svg/layer.png -crop 5x4@ +repage +adjoin png32:svg/layer_%d.png
svg/layer.png PNG 1250x1105 1250x1105+0+0 8-bit DirectClass 143KB 0.040u 0:00.089
svg/layer.png=>svg/layer_0.png[0] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 0.080u 0:00.140
svg/layer.png=>svg/layer_1.png[1] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 0.080u 0:00.149
svg/layer.png=>svg/layer_2.png[2] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 0.080u 0:00.140
svg/layer.png=>svg/layer_3.png[3] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 8.19KB 0.090u 0:00.160
svg/layer.png=>svg/layer_4.png[4] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 12.3KB 0.100u 0:00.170
svg/layer.png=>svg/layer_5.png[5] PNG 1250x1105=>250x277 8-bit TrueColorMatte DirectClass 0.100u 0:00.160
svg/layer.png=>svg/layer_6.png[6] PNG 1250x1105=>250x277 8-bit TrueColorMatte DirectClass 4.1KB 0.110u 0:00.160
svg/layer.png=>svg/layer_7.png[7] PNG 1250x1105=>250x277 8-bit TrueColorMatte DirectClass 0.120u 0:00.169
svg/layer.png=>svg/layer_8.png[8] PNG 1250x1105=>250x277 8-bit TrueColorMatte DirectClass 4.1KB 0.120u 0:00.179
svg/layer.png=>svg/layer_9.png[9] PNG 1250x1105=>250x277 8-bit TrueColorMatte DirectClass 8.19KB 0.130u 0:00.189
svg/layer.png=>svg/layer_10.png[10] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 4.1KB 0.130u 0:00.190
svg/layer.png=>svg/layer_11.png[11] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 8.19KB 0.130u 0:00.199
svg/layer.png=>svg/layer_12.png[12] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 4.1KB 0.140u 0:00.199
svg/layer.png=>svg/layer_13.png[13] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 8.19KB 0.150u 0:00.209
svg/layer.png=>svg/layer_14.png[14] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 12.3KB 0.160u 0:00.219
svg/layer.png=>svg/layer_15.png[15] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 4.1KB 0.160u 0:00.220
svg/layer.png=>svg/layer_16.png[16] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 4.1KB 0.170u 0:00.230
svg/layer.png=>svg/layer_17.png[17] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 12.3KB 0.190u 0:00.240
svg/layer.png=>svg/layer_18.png[18] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 8.19KB 0.180u 0:00.239
svg/layer.png=>svg/layer_19.png[19] PNG 1250x1105=>250x276 8-bit TrueColorMatte DirectClass 8.19KB 0.190u 0:00.219
Seems a bug to me.

Re: Equally sized crop problem

Posted: 2011-12-01T08:10:59-07:00
by michele.franzin
I've made a patch (to the current stable version 6.7.3-9) to avoid this problem.

Code: Select all

--- /tmp/ImageMagick-6.7.3-9/magick/transform.c	2011-09-16 03:38:06.000000000 +0200
+++ magick/transform.c	2011-12-01 15:52:52.832017852 +0100
@@ -793,8 +793,17 @@ MagickExport Image *CropImageToTiles(con
           width+=(geometry.x < 0 ? -1 : 1)*geometry.x;
           height+=(geometry.y < 0 ? -1 : 1)*geometry.y;
         }
-      delta.x=(double) (width+(geometry.width >> 1))/geometry.width;
-      delta.y=(double) (height+(geometry.height >> 1))/geometry.height;
+
+      if (width % geometry.width != 0)
+        delta.x=(double) (width+(geometry.width >> 1))/geometry.width;
+      else
+        delta.x=(double) width/geometry.width;
+ 
+      if (height % geometry.height != 0)
+        delta.y=(double) (height+(geometry.height >> 1))/geometry.height;
+      else
+        delta.y=(double) height/geometry.height;
+
       for (offset.y=0; offset.y < (double) height; )
       {
         if ((flags & AspectValue) == 0)

Re: Equally sized crop problem

Posted: 2011-12-01T22:31:43-07:00
by anthony
The equal sized handling was working perfectly when I creating this function.

However you will need to be VERY VERY careful that
  • it still handles overlaps and spacing arguments correctly
  • it still centers 'odd' sized images.
  • it handles both types of edge conditions (as specified by the '!', or Aspect flag)
Now as for the reason why it is not working. I would have to examine the math. But it should be working without the added patch.
If it is not working, then something is NOT right, and it will need more than a patch for a specific condition!

In other words, do not apply this patch!


What should be happening is that it calculates a offset.x,y and delta.x,y, that represents the left edge of the tile overlaps (which are geometry.x,y wide). In you example geometry.x,y is zero, so it should be simply the tile edge as a floating point value. The nearest integer to this edge should be the real edge for the crop. For equally spaced images that floating poitn value should work out to actual integers, as such you should get EXACT equal sized tiles.

Now the fact that you are NOT getting exact equal sized tiles, means that something is going wrong! So rather than putting in a 'special condition' you should be debugging to find out the deeper problem. By first understanding what the algorithm is doing.

Re: Equally sized crop problem

Posted: 2011-12-01T23:07:13-07:00
by anthony
Looking at the formula.. It looks like the problem is with the calculate of delta.x,y These should be exactly 250 as you say. But they aren't. This shows up when the size of the tiles become larger.

The line you are patching

Code: Select all

    delta.x=(double) (width+(geometry.width >> 1))/geometry.width;
    delta.y=(double) (height+(geometry.height >> 1))/geometry.height;
is the cause of the fault.
My original formula has simply

Code: Select all

   delta.x=(double) width/geometry.width;
   delta.y=(double) height/geometry.height;
(width and height already having been adjusted to account for overlaps)

I did not make that change. I have replaced the incorrect lines with...

Code: Select all

   delta.x=((double) width)/((double)geometry.width);
   delta.y=((double) height)/((double)geometry.height);
Now I get correct tile sizes and offsets, with a single odd-size vertically (second row of tiles) as height is not correctly divisible.

Re: Equally sized crop problem

Posted: 2011-12-01T23:25:09-07:00
by anthony
The original problem is also now fixed too!

The question then becomes what caused the change in the algorithm in the first place!

Re: Equally sized crop problem

Posted: 2011-12-02T04:27:51-07:00
by michele.franzin
I'm agree with you my patch is more workaround than a solution, and among all other aspects... it's definitely not elegant ;-)
but it works smoothly in both cases. Many thanks for your effort... There's a planned release version to have this fix in production?
All times are UTC-07:00
Page 1 of 2

Powered by phpBB® Forum Software © phpBB Limited