No Product Reader for band - Sentinal-1 Data Reading

I am trying to load Sentinel-1 data in SNAP. I am reading directly zip file. When I load data in SNAP. I got Unexpected Expectation: “No Product Reader for bank - null”. Here is the detail massage. Can anyone guide me where’s the problem?

Note: I have installed ESA SNAP on ubuntu platform.

java.lang.IllegalStateException: Input not set!
at it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReader.prepareRead(TIFFImageReader.java:1609)
at it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReader.readAsRenderedImage(TIFFImageReader.java:1667)
at org.esa.s1tbx.commons.io.ImageIOFile.getData(ImageIOFile.java:292)
at org.esa.s1tbx.commons.io.ImageIOFile.readImageIORasterBand(ImageIOFile.java:244)
at org.esa.s1tbx.io.sentinel1.Sentinel1ProductReader.readBandRasterDataImpl(Sentinel1ProductReader.java:162)
at org.esa.snap.core.dataio.AbstractProductReader.readBandRasterData(AbstractProductReader.java:277)
at org.esa.snap.core.image.BandOpImage.computeProductData(BandOpImage.java:68)
at org.esa.snap.core.image.RasterDataNodeOpImage.computeRect(RasterDataNodeOpImage.java:127)
[catch] at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
at javax.media.jai.OpImage.getTile(Unknown Source)
at com.bc.ceres.glevel.MultiLevelImage.getTile(MultiLevelImage.java:54)
at com.sun.media.jai.util.SunTileScheduler.compute(Unknown Source)
at com.sun.media.jai.util.TileJob.compute(Unknown Source)
at com.sun.media.jai.util.WorkerThread.run(Unknown Source)

Does this happen for all Sentinel-1 zip files or only one specific one?
Can you please check if the file was downloaded completely by unpacking it? It will give an error if the download was corrupt.
Can you please also share the product ID?

1 Like

I have 32 images, it happened for all images. Now I unzip images and tried again and it worked, there’s no error. Seems the problem was coming from zip format

Actually, loading zip files should work as well, did you maybe rename them?

On the other hand, extracted data is often loaded and processed more quickly.

No I didn’t rename any file. Still when I load zip file I am getting this exception.

java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:230)
at java.util.zip.ZipFile.(ZipFile.java:160)
at java.util.zip.ZipFile.(ZipFile.java:174)
at org.esa.snap.dem.dataio.EarthGravitationalModel96.(EarthGravitationalModel96.java:104)
at org.esa.snap.dem.dataio.EarthGravitationalModel96.create(EarthGravitationalModel96.java:85)
at org.esa.snap.dem.dataio.EarthGravitationalModel96.instance(EarthGravitationalModel96.java:77)
at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.computeTileStack(RangeDopplerGeocodingOp.java:954)
Caused: org.esa.snap.core.gpf.OperatorException: error in opening zip file
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.computeTileStack(RangeDopplerGeocodingOp.java:1067)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:122)
[catch] at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:86)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
at javax.media.jai.OpImage.getTile(Unknown Source)
at javax.media.jai.PlanarImage.getData(Unknown Source)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
at org.esa.snap.raster.gpf.LinearTodBOp.computeTile(LinearTodBOp.java:116)
Caused: org.esa.snap.core.gpf.OperatorException: error in opening zip file
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
at org.esa.snap.raster.gpf.LinearTodBOp.computeTile(LinearTodBOp.java:176)
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:82)
at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
at javax.media.jai.OpImage.getTile(Unknown Source)
at javax.media.jai.PlanarImage.getData(Unknown Source)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
[catch] at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:86)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
at javax.media.jai.OpImage.getTile(Unknown Source)
at com.sun.media.jai.util.RequestJob.compute(Unknown Source)
at com.sun.media.jai.util.WorkerThread.run(Unknown Source)

What was the source of the zip files?

The linux zip utility has a --test option to check the zip archive without extracting. I routinely run this on downloads. I expect SNAP is using Java code, so more like the jar utility:

%  <snap_install_dir>/jre/bin/jar       
Usage: jar {ctxui}[vfmn0PMe] [jar-file] [manifest-file] [entry-point] [-C dir] files ...
Options:
-c  create new archive
-t  list table of contents for archive
-x  extract named (or all) files from archive
-u  update existing archive
-v  generate verbose output on standard output
-f  specify archive file name
-m  include manifest information from specified manifest file
-n  perform Pack200 normalization after creating a new archive
-e  specify application entry point for stand-alone application 
    bundled into an executable jar file
-0  store only; use no ZIP compression
-P  preserve leading '/' (absolute path) and ".." (parent directory) components from file names
-M  do not create a manifest file for the entries
-i  generate index information for the specified jar files
-C  change to the specified directory and include the following file
If any file is a directory then it is processed recursively.
The manifest file name, the archive file name and the entry point name are
specified in the same order as the 'm', 'f' and 'e' flags.

Example 1: to archive two class files into an archive called classes.jar: 
   jar cvf classes.jar Foo.class Bar.class 
Example 2: use an existing manifest file 'mymanifest' and archive all the
       files in the foo/ directory into 'classes.jar': 
   jar cvfm classes.jar mymanifest -C foo/ .

Try <snap_install_dir>/jre/bin/jar tvf <zip_file>.

Surprizingly I don’t have jre folder in my snap directory.

lumir@lumir-VirtualBox:/snap$ ls
bin core18 gnome-3-34-1804 gnome-calculator gnome-characters gnome-logs gnome-system-monitor gtk-common-themes README snapd

Once I unzip my data, I encounter this error. Is there any clue where’s the problem?

Screenshot from 2021-03-26 09-38-40

that your UBUNTU-SNAP folder, you need to find the ESA-SNAP toolbox folder…