how to crop without changing type

[imguser]

Hi.

I feel a bit insecure to bother you with this little problem, but it bugs me enough to register here, so I hope someone can help or enlighten me:

I want to crop a region from a bigger PNG-image without changing anything else. My tries on the bash command line are:

Code: Select all

convert -background white -type TrueColorMatte -crop 880x600+200+190! big-pic_orig.png part-of-it.png
convert -type TrueColorMatte -matte -background white -strip -crop 880x600+200+190! big-pic_orig.png part-of-it.png

Somehow I do not preserve the Type, Alpha Channel, Background Color and Border Color
Anyone who can help with this?

Here are the details, specifically compare Type, Background Color, Border Color and the Alpha Channel.
I added the "no alpha channel" to make things clearer (I hope)


If I look at the original with identify -verbose big-pic_orig.png I get among other things:

Code: Select all

Format: PNG (Portable Network Graphics)
Geometry: 1132x812
Class: DirectClass
Type: TrueColorMatte
Alpha: (  0,  0,  0,255)        #000000FF
Rendering-intent: Undefined
Interlace: None
Background Color: white
Border Color: #DFDFDF00
Matte Color: grey74

A look at my first try to create part-of-it.png reveals this:

Code: Select all

  Format: PNG (Portable Network Graphics)
  Geometry: 880x600
  Class: DirectClass
  Type: TrueColor
No Alpha Channel
  Rendering-intent: Undefined
  Interlace: None
  Background Color: white
  Border Color: #DFDFDF
  Matte Color: grey74

A look at my second try to create part-of-it.png reveals this:

Code: Select all

  Format: PNG (Portable Network Graphics)
  Geometry: 880x600
  Class: DirectClass
  Type: TrueColor
    Alpha:
      Min: 255 (1)
      Max: 255 (1)
      Mean: 255 (1)
      Standard deviation: 0 (0)
  Rendering-intent: Undefined
  Interlace: None
  Background Color: #00000000
  Border Color: #DFDFDF00
  Matte Color: grey74

Thanks.

P.S.: I can provide more details, of course.

[fmw42]

PNG is undergoing quite a bit of change and has had bugs being fixed, but sometimes they still creep in. Upgrade to the latest or wait until the next release. See other PNG bug reports and also the changelog http://www.imagemagick.org/script/changelog.php

Also when cropping you should put +repage after it so that you remove the virtual canvas offset. See http://www.imagemagick.org/Usage/crop/#crop


Also put your input image right after convert. See http://www.imagemagick.org/Usage/basics/#cmdline

[anthony]

I noticed myself (due to a change in IM Example results) that PNG file writing is not obeying any -type suggestion.

In my case I requested TrueColor image, but got a Palatte image instead! (I had not reported this, but fixed it bu specifically requesting a png24: format You could request a png32: output format to ensure you get a TrueColorMatte.
But really the PNG coder should be following the 'type' if it has been set.

However as Fred (fwm42) has pointed out, the PNG coder is in flux, at this time.

[imguser]

Thank you both for your answers.

It gives me some sort of comfort that it is more of a bug and less of a user failure. The downside is, there is no way to solve it quickly.

Easy things first:
I tried +repage and -repage 880x600+0+0 and found no difference. I guess the exclamation mark appended to the offset of the geometry for crop just works fine. However, I left the repage setting in, that is I always tried both versions in my later attempts.

other things second:
I reorderd the sequence of my command to be more in line with http://www.imagemagick.org/Usage/basics/#cmdline
Finally I tried to specify the output format via png32:

It did not help at all, but here are some notes, maybe it helps.
Should I open a bug report on this? Maybe just post this in the 'bugs' forum?

-------------------------------------------
With ImageMagick version 6, the operators will always be applied in the command line order as given by the user.

Operation Settings which control how later operators function. They set the colors, and fonts that may be used by an operator, control placement of images and text, the lookup of color from source images, control the method of processing by some of the more complex operators, etc., etc., etc..

-dither -gravity -fill -background -bordercolor -stroke -font -pointsize -strokewidth -box -affine -virtual
-pixel -interpolate

Here is the list of image settings:
-adjoin -affine -alpha -antialias -authenticate -background -bias -black-point-compensation -blue-primary -bordercolor -caption -channel -comment -compress -debug -define -delay -density -depth -direction -display -dispose -dither -encoding -endian -extract -family -fill -filter -font -format -fuzz -geometry -gravity -green-
primary -interlace -intent -interpolate -label -limit -linewidth -log -loop -mask -mattecolor -monitor -orient -page -pointsize -preview -quality -quiet -red-primary -region -render -repage -sampling-factor -scene -seed -size -stretch -stroke -strokewidth -style -texture -tile -transparent-color -treedepth -type -undercolor
-units -verbose -virtual-pixel -weight

Simple Image Processing Operators will modify all images that have already been read into memory. Each image is modified
separately to every other image. Because all image operators are performed immediately when seen on the command line, they must be given after the images for which they are to operate have been read into memory. They include operations such as...

-negate -rotate -crop -flip -flop -wave -resize -repage -set -shadow -scale -sample -swirl -draw +matte -distort -morpohology
And lots lots more...

Explicit Image Format

Images can be stored in a myriad of image formats including the better known JPEG, PNG, TIFF and others. ImageMagick must know the desired format of the image before it is written. ImageMagick leverages the filename extension to determine the format. For example, image.jpg tells ImageMagick to write the image in the JPEG format. In some cases the filename does not identify the image format. In these cases, the image is written in the format it was originally read unless an explicit image format is specified. For example, suppose we want to write our image to a filename of image in the raw red, green, and blue intensity format:

$magick> convert image.jpg rgb:image

Code: Select all

convert -type TrueColorMatte -background white big-pic_orig.png -crop 880x600+200+190\! -repage 880x600+0+0 -matte -strip png32:part-of-it.png
convert -type TrueColorMatte -background white big-pic_orig.png -crop 880x600+200+190\! +repage -matte -strip png32:part-of-it.png

I also tried other sequences of the command, it did not change.

[fmw42]

Are you trying to change white to transparent or does your image already have transparency? Otherwise, why the truecolormatte and -matte?

try
convert big-pic_orig.png -channel rgba -matte -crop 880x600+200+190\! +repage -strip -type TrueColorMatte png32:part-of-it.png


OK it still does not work. I tried


convert logo: -transparent white logot.png
convert logot.png -crop 300x300+200+200 +repage -type truecolormatte PNG32:logot_sub.png
identify -verbose logot_sub.png
Image: logot_sub.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 300x280+0+0
Resolution: 72x72
Print size: 4.16667x3.88889
Units: Undefined
Type: PaletteMatte
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit


But I think this is a known issue to be fixed in IM 6.6.8.4?

[fmw42]

The above still fails in 6.6.8.4. I will submit bug report.

[anthony]

I tried +repage and -repage 880x600+0+0 and found no difference. I guess the exclamation mark appended to the offset of the geometry for crop just works fine. However, I left the repage setting in, that is I always tried both versions in my later attempts.

You can always use -identify or write to info: and see what the virtual canvas page settings are.

However the '!' flag on crop basically means 'viewport'. That is it resets the virtual canvas to match the area you requested for the crop. That is the area requests is the new virtual canvas. So unless the crop region falls of the top or left edges, you will have a +0+0 offset. The crop size will also be the virtual canvas size, which may be larger than the actual image size if the crop region extends beyond the right or bottom edges.

Note that is different to +repage, which basically removes all virtual canvas and size settings causing it to become the actual image cropped. No top/left offset, and size will match actual image size regardless of what that is.

It seems strange that png32 did not give you a truecolormatte. That is an explict format and should have been respected.
The only other thing I can think of is if the alpha channel is not actually enabled, say using -alpha set

[imguser]

Again, thank you both.

I tried convert big-pic_orig.png -channel rgba -matte -crop 880x600+200+190\! +repage -strip -type TrueColorMatte png32:part-of-it.png, but neither did it work for you nor for me.

Thank you for submitting a bug report, this saves me the time to find out how to do this correctly.

To clarify some things:
truecolormatte and -matte and -background white are in because my first and simple try (convert big-pic_orig.png -crop 880x600+200+190\! part-of-it.png) did not work.
So the plan was to manually set the things that are changed. I hoped that would ovewrite the changes that occur.
The original image already has transparency.

About the resize-viewport issue: Thank you for your in-depth explanation. For me, since I am cropping "in the middle", things worked out to be the same.
In this regard, I always got what I wanted in my attempts, which is

Code: Select all

Page geometry: 880x600+0+0

I left out the geometry in my first post since it did not draw my attention.


Just in case that someone needs this information, here is the full output of identify:

Code: Select all

identify -verbose big-pic_orig.png
  Format: PNG (Portable Network Graphics)
  Geometry: 1132x812
  Class: DirectClass
  Type: TrueColorMatte
  Endianess: Undefined
  Colorspace: RGB
  Channel depth:
    Red: 8-bits
    Green: 8-bits
    Blue: 8-bits
    Alpha: 1-bits
  Channel statistics:
    Red:
      Min: 0 (0)
      Max: 255 (1)
      Mean: 69.2691 (0.271644)
      Standard deviation: 85.4855 (0.335237)
    Green:
      Min: 0 (0)
      Max: 255 (1)
      Mean: 76.9787 (0.301877)
      Standard deviation: 82.2612 (0.322593)
    Blue:
      Min: 0 (0)
      Max: 255 (1)
      Mean: 77.8649 (0.305353)
      Standard deviation: 86.2184 (0.338112)
    Alpha:
      Min: 255 (1)
      Max: 0 (0)
      Mean: 254.999 (0.999995)
      Standard deviation: 0.594734 (0.00233229)
  Alpha: (  0,  0,  0,255)        #000000FF
  Colors: 11234
  Rendering-intent: Undefined
  Resolution: 72x72
  Units: Undefined
  Filesize: 824kb
  Interlace: None
  Background Color: white
  Border Color: #DFDFDF00
  Matte Color: grey74
  Page geometry: 1132x812+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Zip
  Orientation: Undefined
  Signature: f8ace4ea1a855ffd1ae731fa01fc2e807152e39215034ea1c9d1df40007c8e23
  Tainted: False

[fmw42]

see report and responses from Glennrp and my response at viewtopic.php?f=3&t=18275

[imguser]

Thank you Fred.

Now, this information does shed some light on it.

First let's do as suggested:

Code: Select all

identify -verbose png32:part-of-it.png
Format: PNG32 (32-bit RGBA PNG, semitransparency OK)

before it was just this

• Format: PNG (Portable Network Graphics)

No other changes in the output of identify, notably still

• Type: TrueColor
  Endianess: Undefined
  Colorspace: RGB

Now lets verfiy this whole thing. This should be a somewhat complex way to duplicate/copy my original image

Code: Select all

convert -type TrueColorMatte -background white big-pic_orig.png -crop 1132x812+0+0\! +repage -matte -strip partof-it.png

And indeed, now identify -verbose part-of-it.png gives this (partial list):

• Format: PNG (Portable Network Graphics)
  Geometry: 1132x812
  Class: DirectClass
  Type: TrueColorMatte
  Endianess: Undefined
  Colorspace: RGB
  Alpha: ( 0, 0, 0,255) #000000FF
  Colors: 11234
  Rendering-intent: Undefined
  Resolution: 72x72
  Units: Undefined
  Filesize: 814kb
  Interlace: None
  Background Color: #00000000
  Border Color: #DFDFDF00
  Matte Color: grey74
  Page geometry: 1132x812+0+0

Everything is as before, notably Format, Type, border Color.
What did change though, is filesize from Filesize: 824kb to Filesize: 814kb. This happens even if I leave "-strip" away.
Also Background Color ist still not displayed as "white" as before but as "#00000000". This happens even if I leave "-background white" away. This change was noted by me in my earlier attempts, too.

Any idea how the change to Filesize and Background Color happens?

I add a post to the "possible bug" topic, which is probably more of a "unexpected behavior type".

[fmw42]

I would have to see your image, if you can post a link to it. -background white does NOT set the background color by itself. You have transparency and if you want to put white where the transparency is then you need to add -flatten and then you don't need PNG32, but PNG24

convert big-pic_orig.png -crop 1132x812+0+0\! +repage -strip -type TrueColor -background white -flatten PNG24:partof-it.png

If I misunderstand what you are trying to do then please clarify and post a link to your image or some example of the issue.

IM reports a background color #00000000 which in this case is transparent black, because you have a transparent image with that color transparency.

I don't understand your issue with filesize. After processing and creating a new png image, IM will not optimize it very well and you could end up with a larger or smaller filesize. 824 kb vs 814 kb is nothing to worry about and if the output is 814, then you have gained a little compression.

Again if I misunderstand your issue, please clarify.

[imguser]

I am sorry that I can not simply provide the image. I would have to use imageshack or something similar. If this would be ok (image does not get modified by doing so) we could give it a try. Maybe we can still sort this out without doing so.

What I am trying to do in the first place is: Get a part of a picture without changing anything else.

My issue with the filesize is sort of a non-issue, since I am of course glad about saving some space. I wondered how this comes. For this, your explanation is enough for me and announces to me that an increase in filesize is also nothing to worry about (which would have caused me to wonder again).

The background thing is: For the original image file identify reports this

• Background Color: white
  Border Color: #DFDFDF00
  Matte Color: grey74

For the created image file identify reports this:

• Background Color: #00000000
  Border Color: #DFDFDF00
  Matte Color: grey74

That is why I added "-background white" to my command to manually correct it.

[fmw42]

the difference is that after you set -type truecolormatte and PNG32 you get an image with transparency from IM and it reports colors as having transparency i.e. the extra 00 in the hexcolors.

I must admit I have never understood these 3 parameters, since most of the time the don't seems to mean much regarding the image.

As for -background color, it is not an operator but a setting. It won't do anything without a corresponding operator to apply it, such as -fill or -flatten.

These are the best explanations that I can give. For more details one would have to hear further from Anthony or Magick.