Subscribe to this thread
Home - General / All posts - Irreguar Image crop
Ian
268 post(s)
#05-May-16 14:14

Can you crop an image to any shape? I see the example of south america but it doesn't quite applied to what I'm doing. I have an aerial image that i want to crop to a property boundary file. I can select the area of interest but it will only crop it to the smallest rectangle that contains the whole selection. I want to crop it to the actual boundary. I'm sure there's a simple answer, can someone point me in the right direction please?

Dimitri


7,413 post(s)
#05-May-16 15:48

http://www.georeference.org/doc/displaying_data_in_a_gradient_map.htm has an example...

mdsumner


4,260 post(s)
#05-May-16 16:17

Not really, you can "delete" pixels in Manifold by making them invisible - and you can identify and re-classify pixels by using overlay methods, but you can also create a new raster (extent plus grain) from an old one by removing a rectangular margin of pixel (or adding them). I reckon some of the terminology gods regret making "make invisible" synonymous with "delete", but there you have it.


https://github.com/mdsumner

Dimitri


7,413 post(s)
#05-May-16 16:51

Good point.

Can you crop an image to any shape?

The answer really depends on what "crop" means in the question. Two possibilities:

1. Can I trim an image so that the only pixels which exist form any shape I want, including a non-rectangular shape? The answer to that is no, because an image can only be a rectangle. Images are made up of pixels arranged from left to right in a series of equal rows. That's not a Manifold limitation but is the nature of all raster images.

2. Can I trim an image to a rectangular shape that is no larger than the enclosing rectangle of pixels that are visible in the image, and also ensure that any pixels which fall outside of the irregular, non-rectangular boundary of interest are transparent (invisible) so that it appears what is visible exists only within the irregular boundary of interest? The answer to that is yes. See the previous link for an example of how.

mdsumner


4,260 post(s)
#05-May-16 17:07

That's not a Manifold limitation but is the nature of all raster images.

It's really not, it really is a "Manifold limitation", any raster image can lend itself to the 'texture mapping' provided by any surface. It's pretty much what 'manifold' means.


https://github.com/mdsumner

Dimitri


7,413 post(s)
#06-May-16 09:51

any raster image can lend itself to the 'texture mapping' provided by any surface.

Ummm... lending itself to texture mapping doesn't change that a raster image is *always* rectangular. Manifold did not invent any of the raster image formats in which raster images are always rectangular. Those formats and the rectangular nature of raster images long pre-dated Manifold.

I think what happens when people talk about "non-rectangular" raster images is that they are discussing some special operation within a package that gives the appearance of a non-rectangular blob of pixels, without realizing that the image indeed is still a raster and the nature of rasters is a series of equal rows.

This might not at all be what you meant, but in case it is a good example might be how people lasso irregular regions of pixels in PhotoShop in one layer of a multi-layer work in progress, copy or cut that region and then paste what appears to be an irregular blob of pixels within a different layer. They move that irregular blob of pixels about and say, "see, no rectangular image here!"

But what is really happening is that they are, indeed, working with a rectangular array of pixels but just inside the editor PhotoShop marks some of the pixels as "not there." You can see what is really going on when you take that "irregular blob of pixels" you copied and create a new image for it in PhotoShop and then paste the blob. You'll see that PhotoShop *always* creates a rectangular new image the size of the bounding box of the irregular blob and then when you paste the irregular blob you end up pasting a mix of visible and transparent pixels.

Save that new image to a format that supports transparency in pixels and you get a rectangular image in a file that has the pixels outside the irregular blob of visible pixels marked as transparent. Save it to a format that does not support transparent pixels and you get a rectangular image in a file that has the pixels outside the irregular blob painted in the background color or some other default.

That raster images are always rectangular is neither a Manifold invention nor is it a Manifold limitation. It is just the nature of raster images. Different editors deal with that fundamental nature of raster images in different ways. Manifold just happens to be more explicit about it than many. It doesn't pretend the pixels "aren't there," which is hogwash in a rectangular raster, it says that they are simply not visible.

If any of the above is incorrect I would be very grateful to learn how it is incorrect. For example, I'd be very interested in hearing of a raster image format that does not use rectangular images. I can imagine designing such a format that consisted of variable length rows of pixels with each one starting at some offset, perhaps encoded even with start and stop markers so that the irregular blob encoded could have islands and holes in it, but when you think about that a bit more you're just coming up with a different way of encoding/compressing a rectangular array of pixels in that the offsets would start from some common vertical axis.

mdsumner


4,260 post(s)
#06-May-16 13:20

Er, yeah - sorry. I was thinking about the topic in a very narrow way. I will point out though, not to be impertinent, just to show there's many ways to think about this, that you can interact with and select a very non-rectangular-seeming data set when you've got a raster in a map being reprojected on the fly. What I want (outside of current Manifold) is to interact with that curvilinear representation in more varied and more flexible ways.


https://github.com/mdsumner

Ian
268 post(s)
#05-May-16 20:27

Thanks for both of your help. So apart from blanking out/covering the area outside of the boundary using an overlay I can't actually trim the image file itself? Is there any other way of achieving what I'm after? I think the answer is probably no

mdsumner


4,260 post(s)
#05-May-16 23:01

You can crop the rectangular margin with Transform Crop, it won't be applied to the file until you export and replace the original file. There is no sensible meaning to cropping to an irregular outline for a raster, as Dimitri says - Manifold is just toggling the display of "deleted" pixels.


https://github.com/mdsumner

tjhb
10,094 post(s)
#05-May-16 23:21

Is it worth spelling this out a bit more? We old hands assume things.

1. Create a map using the image. Add the drawing containing property area(s) to the map.

2. Activate the drawing layer, and select the property area you want to use to delimit the image.

3. Activate the image layer, and choose Image > Transfer Selection. Modify: <image>. Using: <drawing>.

4. On the transform bar: [Selection in <image>] Crop. Apply.

Now the image is cropped to the bounding box of the property area, always a regular rectangle.

If you also want to make the pixels outside the property area invisible:

5. Still with the image layer active, Edit > Select Inverse (or Ctrl-I), then...

6. Edit > Delete (or Del).

The deleted pixels are still there, but an internal flag is set to make them transparent.

As always in Manifold, there are other ways to achieve the same thing (including programmatic means).

A variation on 5 and 6 would be to create a vector mask (if A is the property area, and B is its bounding box, then mask area C is B minus A), colour it, say, black or white, and lay it above the image. This would mask the outside pixels rather than making them transparent.

[Added.] There are also ways to achieve partial transparency, if you like the look of that, or partial or complete desaturation, or darkening or lightening, of the surrounding pixels. Just ask.

Ian
268 post(s)
#06-May-16 00:52

Excellent, that worked, thanks. I had to make an image of my original imagery as the original was a compressed Tiff so i have lost a little resolution. I did try exporting it and reimporting it without the compression so i could keep the original resolution but when I tried to reimport the image manifold said it couldn't open the file - tried a couple of times.

tjhb
10,094 post(s)
#06-May-16 01:08

That sounds strange--Manifold does support compressed TIFF files (using LZW, ZIP or JPEG).

However, Manifold 8 does not support the BigTIFF format, so source file size is limited is 2GB.

Where were you exporting the image from? What was the file size (compressed and uncompressed)? Do you know the compression format used?

Ian
268 post(s)
#06-May-16 01:33

The imagery was taken using a drone and supplied to me as an ECW (1.5GB). I imported this into manifold then exported it as an IMB uncompressed tiff. It was quite a large file - around 15GB I think. I tried importing it back into manifold but it couldn't open the file. I don't know what compression format was used, though pyramids were mentioned I think - not sure what that is though

tjhb
10,094 post(s)
#06-May-16 01:56

So the import from ECW was successful? (Not link from ECW, that's different.) At that point you should have had an image inside Manifold, stored in Manifold's own format. Why did you need to export it to TIFF then (try to) reimport it?

(You initially said the original was a compressed TIFF but it seems it was an ECW.)

Ian
268 post(s)
#06-May-16 02:31

Yes it was. I thought it was a compressed tiff but I just checked and it was an ECW. I couldn't edit the ECW and I thought that was because you can't edit compressed images?

tjhb
10,094 post(s)
#06-May-16 02:54

You're right, you can't edit a compressed image, and I was leaving out an important step.

If you import an ECW, you get a compressed Manifold image, exactly as you say.

In order to edit it, you would first have to decompress it. You can do this inside Manifold. It will take some time (and RAM) but might be worth it to preserve full resolution.

If you want to do that, import the image again, then open it, and use Image > Convert to..., choosing either RGB colour or RGBa colour as the target.

You can do more with an RGBa image than with RGB. It gives you the means to set partial transparency, for example. But it uses 1/3 more memory. You could go to RGB first, then convert to RGBa after cropping--more efficient.

(Up to you whether you save as a new component. You might want to keep an uncropped version of the image, compressed. I'm not certain which option will be faster. If you have heaps of RAM and a fast TEMP drive, I'd expect saving as a new component to be faster. Otherwise, slower.)

You can edit the decompressed result, a normal Manifold image.

dmbrubac


1,620 post(s)
#10-May-16 14:23

Here is yet another method to get what you want, albeit even more tailored to your exact problem than Tim's list of steps.

I use a drone to capture imagery, generate TIFF tiles with Pix4D and use Manifold to re-assemble them and generate an ECW (Are you in Ontario? Did you get yours from me?)

Assuming your source did something similar, you should be able to go back to the author and request an ECW or other format file clipped to your specifications. Since the image starts out as a number of tiles, step 1 would be to not even include the tiles you don't want. If they won't do it for you, you should at least be able to get the original TIFF tiles so you can do the clip yourself and skip the ECW in the middle.

Since ECW is lossy above compression ratios above 2:1 or 3:1, this method will at least retain the best image quality. Your ECW could be compressed at 10:1 or 20:1


Don't expect, suggest!

Dimitri


7,413 post(s)
#06-May-16 10:41

Is it worth spelling this out a bit more? We old hands assume things.

You have the patience of a saint.

I'll go a bit off-topic here to discuss how documentation can go in different ways and what that currently implies for where future Manifold doc might go...

I agree it helps to spell things out in more detail. But that's what detailed, copiously illustrated user manuals are for. For example, the topic first recommended in this thread at http://www.georeference.org/doc/displaying_data_in_a_gradient_map.htm spells out the equivalent, with illustrations, of the step by step procedure you so generously provided. A shame such pretty pictures may pass unseen... :-)

I agree there is a legitimately different approach in styles. It is a debate going on right now for the Radian Studio documentation where a fairly strong and persuasive contingent states nobody ever reads anything but 1,2,3 lists of steps so the manual should contain nothing but lists of such steps. They have a point in that as indeed such lists of steps are highly effective to guide work when a specific task must be accomplished under time pressure. I call this group the List Wizard contingent.

Another group agrees specific lists of steps are useful for those tasks which can be imagined up front, but those necessarily are a very small portion of the infinite number of possibilities when a bit of more general learning allows the basics to be combined and recombined. They also point out that specific lists of steps cannot incorporate the little things taken for granted that general learning provides. (A good example in this thread is discussion that to edit an image one must have an uncompressed image with the actual pixels, not a summary view through a portal that gives a visual impression at some scale of a compressed ECW. That's one of the details that a general knowledge of images and editing provides but which along with all other possible nuances cannot be included into a 1,2,3 list without making the list as long as the general book).

This latter group wants the documentation to focus more on general explication of capabilities so the user can recombine them as desired. I call this group the Software Tools contingent in homage to the brilliant, seminal book of that name by Brian Kernighan and P.J. Plauger, where they presented a philosophy of modular tools that could be combined like pearls on a string to accomplish any task.

Radian I think will try to satisfy both camps, by first including a 1,2,3 list of steps whenever possible and only after that is done to go off to more conversational, general explication. If the desire to keep documentation compact prevents fuller explication the 1,2,3 lists will play the main role, the reality being that people much prefer to use social media to learn why a default list doesn't work in non-default cases than to dig through an authoritative but very long manual. :-)

Ian
268 post(s)
#06-May-16 11:55

That topic you first referred to didn't have much to do with what I was trying to do - not that I could tell anyway. My first stop when I have a problem is the user manual sometimes this is successful other times I spend a whole lot of time and get no where. The way tjhb explained it made the whole thing pretty easy. Maybe he/she should be paid to update the user manual so its a bit more user friendly

rockland
97 post(s)
#06-May-16 16:02

Ian, there are definitely some gurus and wonderful contributors on this site. Most on here are very helpful when someone asks a question. Usually folks on here hope a person that posts a question have done their due diligence in very active search for solutions. However, having been a Manifold user for over 10 years I have at times been stumped by an issue and can't seem to find a solution and have reached out for help. Usually the response is positive and timely. I also understand to "RTFM"...yet, lol, the manual printed out is over 4000 pages. I still have a pile of printouts on various topics on Manifold that is about 8 inches high that I need to eat (reread) or throw, some of those printouts are manual topics, some are the postings from this forum. I applaud you reaching out for help and I also encourage you to RTFM. I originally found the manual to read in a counter-intuitive format. Yet, in time, I learned to appreciate the good work done with the manual; I would even venture to say the Manifold help manual to be the best, and most complete manual for software I have used in my 27 years of using software. More to your point about images, I found the example of using a drawing to clip an image containing the shape of Afghanistan very useful. I don't like the fact that if I export out an ecw and import that image of Afghanistan that I end up with a very unsightly amount of black around the country. Yet, most of the time, when I import ecw's I don't need the image for "presentation" and I ignore the black "invisible pixels" and use it for whatever purpose I need it for. There is a work around on this but I won't space here on that. There is supposedly also a way to turn those black invisible pixel areas white. I haven't pursued that solution in that I find other ways to use an ecw [I only use ecws for large images, OR, if I have a lot of small images that make my .map huge]. It would be nice if we could export out a cropped image of Afghanistan [or any other image that is not rectangle] and be able to import back in as an ecw and not have the black to begin with. Also, in the manual, there is a lot of words used on how everything should be in metric and lat-lon. Yet, here in the USA, it is wishful thinking to think the land business and all the surveys be converted and measurements made into metric. It is going to remain in feet and miles no matter how superior metric is to the English measurement. Now I have gone on way to long. I hope my ramblings are of reassurance and helpful. You are welcome to contact me if you have any thoughts or questions and maybe we can commiserate together on issues of M8. What I would love to see in upcoming Manifold versions is an incorporation of many of the great ideas and solutions posed on this forum over the last 8 years since the release of M8. I trust that some will be incorporated. All of us that use M8 look forward to that and for the increased capabilities to handle images that a new version may offer. Keep up the good questions! Eventually you will be offering suggestions to others on how to do things. And in closing and a shout out too, tjhb is one of the most helpful and outstanding contributors, among many others.

Dimitri


7,413 post(s)
#07-May-16 12:17

didn't have much to do with what I was trying to do - not that I could tell anyway.

If that happens again with a response to a question you post please speak up. That will help everyone (if someone inadvertently steered you wrong they can learn from that) and it is a small courtesy to whoever tried to help you.

It is also practical: if you don't think a recommendation has much to do with your question, well, double-check that. If someone suggests a resource, take a close look and ask again if you don't see what they mean.

For example, "Thanks for the link but I don't see what surfaces have to do with my task with images." A reply might have been, "The same commands apply to surfaces and images because they are both rasters see [link]. The example shows step by step how to do what you want. Just use your image where the example uses a surface. "

The way tjhb explained it made the whole thing pretty easy. Maybe he/she should be paid to update the user manual so its a bit more user friendly

I agree with that. My post was intended to discuss two different styles of documenting complex software, with both styles having pluses and minuses, and to convey Manifold had come down on the side of 1,2,3 style.

Your comment above illustrates how the 1,2,3 text wizard approach really can make things easy, especially when you have one of the smartest guys around, and a gifted writer as well, write for you acustom wizard specifically tailored to your needs. It will never get easier than that.

But the 1,2,3 method only works well when it is a close match to what people want to do and to their skill levels. Otherwise it is confusing for some people, even if the 1,2,3 steps are as well-written as Tim's.

An example: Tim writes "1. Create a map using the image. Add the drawing containing property area(s) to the map." Some people who are not as diligent as you won't know how to "create a map using the image" because, unlike you, they don't have any idea how a map and an image are different. They'll be mad at the user-unfriendliness of this step, really angry after poking away at menu buttons trying to do step 1. They'll write to Manifold asking "How do I create a Google Map from my image? I don't see any place on the Google site to upload an image." or "I printed the image to make a map but now how do I use that paper in step 2?" Or they'll write, "What areas? My map has lines." And that's just step 1. :-)

You may think I'm kidding but that's really what happens. For that reason, as useful as 1,2,3 text wizards can be as guides and in examples they have serious limits. At some point it becomes easier to write a general purpose introduction that teaches people how to use the stuff in a general way and then allow them to use their knowledge to confidently string together whatever it is they want to do in whatever custom way fits the bill for a particular person and situation, as Tim did for you.

I fully agree that approach requires more up-front investment in time. With some packages unless you invest days or weeks of intensive study at first you don't get the background knowledge you'll need even if later on you are willing to spend hours diving into various topics in the manual as need be.

I am not in any way slamming you for your views. As I noted there is a particularly strong Text Wizard contingent within Manifold that knows the above pluses and minuses perfectly well and based on the balance strongly advocates the 123 approach to be done first with general knowledge explication done second, if possible. I support that approach as well, albeit not as strongly as some.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.