then I can clearly see those individual pixels.
Clearly see individual pixels? Nope. What you're looking at are usually thousands of pixels, that in an accepted fiction represent a single pixel. If you zoom in to where a black square that supposedly represents one data pixel is one inch (2.54 cm) in size on your screen, you're looking at over nine thousand pixels, 9216 to be exact if your monitor uses typical 96 dots per inch pixel grid density. Unless you're looking at the data in native resolution, where each pixel of data is exactly one pixel on screen you're looking at some sort of fiction. If you zoomout so each pixel on screen corresponds to more than one pixel in the data, you're going to be looking at a fiction, likely some interpolation that involves clipping and averaging. If you zoom in so each pixel on screen corresponds to less than the size of a single pixel, you'll also be looking at a fiction, the only question being what kind of fiction/interpolation it is. What kind of fiction is "best" depends on what the purpose is for the visualization and what zoom level is being used. Release 8 used the same fiction when zooming in that Arc and Q use: it painted blocks of onscreen pixels to represent regions of pixel values, using, for example, slightly over 9000 pixels to paint a single pixel when zoomed in so it fills 1 inch of the screen. If you think about it, that, of course, is a lie, because that's not what raster data is in the real world. There isn't a razor sharp geographic boundary every 30 meters on planet Earth that gives different colors when you step over that boundary in the world of Landsat imagery. If you want to have a better visualization that looks more like the real world does when using 30 meter pixels, it's better to have an interpolation. The black and white sample image doesn't show that, but a real world, full color remote sensing image would. That's why 9 goes to the extra effort of doing an interpolation, because that gives a more realistic visualization of the raster data that most people in GIS work with: remote sensed images like drone, aerial, and satellite photos. That also captures the real world effect in other types of raster data without presenting fake impressions of razor sharp accuracy. If you want to zoom far in and edit individual pixels as if you are doing vector editing, sure, there a different way of representing pixels using no interpolation could be better. That's also technically easier than interpolating, so it is the way lazy programmers do it whether that's what is the ultimate objective for the presentation or not. But seriously, how many people edit remote sensing images pixel by pixel? Do you think it's as many as 1/10th of 1%? I've done some of that when trying to remove artifacts like unwanted reflectance highlights in satellite photos, and it is extremely difficult to do with any tool, at least if you want the result to look natural. If you're trying for a deep fake (which is what edited images are, just with benign intent) it's even harder because you don't get a natural interpolation of colors relative to adjacent pixels as is typical for most remote sensed images. But still, if you want to edit individual pixels, as I have on rare occasion, it would be nice to have the classic block style available. I've even requested that, as a low priority item. So why does 9 go to the effort of presenting interpolated pixels? Because at most zoom levels that provides a more natural appearance to the scene than fake, razor sharp edges, and a more natural appearance to the scene is what over 99+% of users seem to want. I'ts also more natural to use interpolation at zoom levels where clearly that's better for a more natural appearance, and then to continue doing that interpolation as zooms go far, far into the image, that being more natural than at some zoom level suddenly to stop interpolation and instead switch to sharp bordered blocks, which would be confusing for most users. Therefore, interpolated views are the default. As for providing Release 8 style presentation when zoomed far in, that's always been in the plans as a possible option, but given that out of many thousands of requests in the years that 9 has been out, not a single person besides me has ever requested it, well, nobody has ever bothered to implement it. That's a good thing I suppose because people would rightfully be annoyed if frequent requests by many people had a lower priority than a single request one person had submitted, and that request being accompanied by a note it was a low priority. As for what type of interpolation is used when interpolation is used, that's a related but different topic. There, also, the default choice varies depending on what the purpose of the interpolation is and the workflow that is being used. For example: I am going through a process of LiDAR QA at the moment and frequently miss some subtle manifestations of incorrect swath alignment and intra swath distance in the DEM.
LiDAR data is vector data, not raster data. If you are looking at a DEM the above isn't doing QA directly on the LiDAR data, it is examining a raster created from the LiDAR data, so that brings in the interpolation process used to create the raster and then based on the raster making inferences about the original vector LiDAR data. Using different interpolation methods to create the DEM (9 offers many) provides a wide variety of options to create a raster that may be better at showing what you're looking for. But if you want to visually detect anomalies in the original, vector LiDAR data, like incorrect swath alignment, etc., I'd suggest looking directly at the vector data with well-chosen vector symbology. Another possibility (just a wild guess - haven't actually tried it), if you must look at the interpolated raster somebody else created and not the original vector data, is to use various filter transforms, like the edge detection ones, to see if they can highlight such anomalies.
|