Export high-qaulity figures from `.dim` files

Hi all, I need to create high-quality maps for publication from .dim files. I tried SNAP and QGIS, but facing some issues, any suggestions?

  1. Save session. When save many .dim files as a “project”/“session”, it cannot reopen like projects in GIS software: my image views are lost, same for layer/mask settings, drawn lines, etc. A previous discussion mentioned this but not solved yet?

  2. then I tried to export .dim files to QGIS for mapping. the obstacles then are:

  • .dim files are usually not directly supported by GIS software. I need to export dim to geotiff in most cases, which add extra work.
  • geotiff and dim handles NaN and data types differently, and I face issues sometimes (or maybe I did not set it correctly)
  • even if able to export geotiff files, the unique dim masks (i.e., directly set mask as expression in property) are not carried in exported tiff files, and much work further in GIS to reproduce similar .dim images with correctly masked areas.
  1. What is the solution with dim file mapping?
    I previously I asked a similar question: whether SNAP will develop more functions in mapping? answer seems a “no”. current basic export functions in SNAP are fine for occasional use, but insufficient for high-quality mapping. Then what would a feasible approach to visualize .dim files? I mean to produce high-quality figures, can revisit and modify map details(colours, extent, map elements, etc)

Thank you,

I think this is the perfect use case for this tutorial, at least the first two questions: Export of products from SNAP

You don’t need to export BEAM DIMAP data, you can directly open it in QGIS and create nice maps there.
If you have continuous data, I recommend the bilinear resampling for the display of data in QGIS, which gives the rasters a smoother look
grafik

Thank you for the reply. yes ENVI formats are good to view files temporarily, but open .img files in QGIS directly does not solve the NoData and mask issues as I listed. Many times it is not as effective as standard exchange format like Geotiff, as individual .hdr header files not carry projection/coordinates information of the img file in the DIMAP data folder, causing mis-alignment in QGIS from multiple dim products. Also need extra effort in QGIS to view multiple band composites (e.g., RGB view) with such a method. so convert to GeoTIFF save these trouble, but facing the issues I mentioned above.

they are not really mis-aligned, you just have to assignt the correct projection to the img file in the layer properties

This can also be done in batch mode with the Assign projection tool.

And Band composites can be created as virtual layers (.vrt) without the need to write a redundant dataset as GeoTiff.

I agree that this also brings challenges, but for my daily work, these are less a problem than those when converting to GeoTiff which requires space, processing time and still is prone to metadata and coding errors.

Thank you ABraun for sharing that. I tried to set the projection in QGIS but maybe because I used less popular projection, usually not able to get the coordinates correct. weird.

Thank for the comments on the batch processing and vrt files. SNAP is really nice tool, but I am quite struggle with data mapping afterwards.

can you please check the content of the hdr file?
For example, a img raster projected in UTM coordinates looks like this
Sigma0_HH.hdr (1.1 KB)

It contains both a definition of the coordinate reference system and a list of bounding coordinates.

I use MODIS Aqua L2 products and they does not have per band projection information stored in .hdr, even though the .dim files show correct projection in SNAP. I “reproject” them to the same projection and now .hdr files carry coord info. this sounds a feasible approach to mapping. thank you.

It is worth noting that NASA standard processing uses binning. In the past, “too high” resolution mapped images had Moire patterns of missing values. The current (tag: V2021.2) release of the OCSSW processing software (macOS and linux, but the NASA SeaDAS GUI (based on SNAP 8) supports “remote” processing, including Windows VM’s running linux) now supports high resolution binning and mapping that avoids the Moire problem. The (python) install script has an option to download a “benchmark” bash script that demonstrates the NASA workflow to produce a “1 km” resolution mapped image.