*First off, this TIFF appears to be geophysical data. But there are no
GeoTIFF tags bundled with the image. Judging from the ModelTiepointTag, it
appears that the original image was configured using a projected coordinate
system, maybe a UTM zone. It might help me understand this better if there
were more location information attached to the image. Do you have that
information?*
No. This image comes from image samples used by Victor Oyala to test
Sextante and had no attached crs . I think this image is related to an UTM
zone in Spain.
*Secondly, I note that this TIFF file is not strictly-speaking an image ,
but is actually numerical data stored using the TIFF standard
floating-point raster format. My guess is that it's probably elevations.
The ability to process TIFF files containing floating point data was
introduced in the most recent release of Commons Imaging.*
Yes, Those are elevation data
*I've attached the image I produced (ISSUE_267.JPG). However, to create
it, I had to know before hand what the range of values was. So my
application does a few extra steps that I did not show in the example
above. I was wondering how the software you used handles this issue. Is
it all automatic?*
Yes. In OpenJUMP reads the range either in a aux.xml sidecar file or it
computes using JAI.create("extrema") method
*Also, a second question I had is that the PhotometricInterpretation tag
given with your image is 1, which means "0 is black". In other words, the
palette should range from the darkest shading for the lowest numerical
values to the lightest shading for the highest values. However, in looking
at your image I notice that the lowest value pixels are drawn in the
lightest colors, which seems to contradict the setting in the source TIFF
file. In the image I've attached, the lowest value pixels are draw in the
darkest colors, which is consistent with the specification in the TIFF
image. Is there some setting in the application you used that overwrites
the settings from the TIFF file?*
The buffered Image to display into the view of the monoband is
overwritten in order to define a range of colours used to display it (I
think it is the method stretchImageValuesForDisplay() in RasterImage
class). This method defines the range of colour (Bloack to white) and saves
as RasterImageSymbology map (sorry for bad explanation). Thus we can change
the range of colours, creating a discrete range instead of continuous one,
set a subrange/value of the pixel to a specific colour
Il giorno mar 22 set 2020 alle ore 15:33 <edgar.sol...@web.de> ha scritto:
> hey Gang,
>
> Gary at Apache-Commons-Imaging has some questions regarding a monoband TIF
> i provided. would one of you with a deeper knowledge of rasters (Peppe,
> Jukka, both?) answer him please in the ticket linked below (you need an
> account, so may have to register, but it's painless and fast).
>
> thanks.. ede
>
>
> -------- Forwarded Message --------
> Subject: [jira] [Commented] (IMAGING-267) Colorful rendering of b/w
> Monoband TIF
> Date: Tue, 22 Sep 2020 00:06:00 +0000 (UTC)
> From: Gary Lucas (Jira) <j...@apache.org>
> To: edgar.sol...@web.de
>
>
> [
> https://issues.apache.org/jira/browse/IMAGING-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199709#comment-17199709
> ]
>
> Gary Lucas commented on IMAGING-267:
> ------------------------------------
>
> Thank you for posting the images. They may help to answer some issues I've
> wondered about for awhile. I've inspected their content and I have a few
> questions for you.
>
> First off, this TIFF appears to be geophysical data. But there are no
> GeoTIFF tags bundled with the image. Judging from the ModelTiepointTag, it
> appears that the original image was configured using a projected coordinate
> system, maybe a UTM zone. It might help me understand this better if there
> were more location information attached to the image. Do you have that
> information?
>
> Secondly, I note that this TIFF file is not strictly-speaking an image ,
> but is actually numerical data stored using the TIFF standard
> floating-point raster format. My guess is that it's probably elevations.
> The ability to process TIFF files containing floating point data was
> introduced in the most recent release of Commons Imaging.
>
> One challenge of floating point images is how to map the range of values
> to gray scale. In this case, the following text gives the TIFF Tags
> attached to the image:
>
> Directory 0 Has TIFF Image Data, description: Root
> 256 (0x100: ImageWidth): 601 (1 Long)
> 257 (0x101: ImageLength): 410 (1 Long)
> 258 (0x102: BitsPerSample): 32 (1 Short)
> 259 (0x103: Compression): 1 (1 Short)
> 262 (0x106: PhotometricInterpretation): 1 (Indicates "zero is black")
> 277 (0x115: SamplesPerPixel): 1 (1 Short)
> 278 (0x116: RowsPerStrip): 8 (1 Long)
> 339 (0x153: SampleFormat): 3 (Indicates float-point format)
> 33550 (0x830e: ModelPixelScaleTag): 25.0, 25.0 (2 Double)
> 33922 (0x8482: ModelTiepointTag): 0.0, 0.0, 0.0, 262846.525725,
> 4464275.0, 0.0 (6 Double)
> 42113 (0xa481: GDALNoData): 45, 51, 50, 55, 54, 56, 46, 48 (8 Byte)
>
> Upon inspection, I find that the values in the image range from 514 to
> 2410. Commons Imaging does have an API element called the
> custom-photometric-interpreter that lets an application specify how colors
> (or gray tones) are assigned to elevations. So in this case, I was able to
> render the data by specifying the following lines:
>
> {{ HashMap<String, Object> params = new HashMap<>(); }}
> {{ PhotometricInterpreterFloat pi = }}
> {{ new PhotometricInterpreterFloat(514.0f, 2410.0f);}}
> {{ params.put(TiffConstants.PARAM_KEY_CUSTOM_PHOTOMETRIC_INTERPRETER,
> pi);}}
> {{ BufferedImage bImage = Imaging.getBufferedImage(target, params);}}
> {{ ImageIO.write(bImage, "JPG", output);}}
>
>
>
> I've attached the image I produced (ISSUE_267.JPG). However, to create
> it, I had to know before hand what the range of values was. So my
> application does a few extra steps that I did not show in the example
> above. I was wondering how the software you used handles this issue. Is
> it all automatic?
>
> Also, a second question I had is that the PhotometricInterpretation tag
> given with your image is 1, which means "0 is black". In other words, the
> palette should range from the darkest shading for the lowest numerical
> values to the lightest shading for the highest values. However, in looking
> at your image I notice that the lowest value pixels are drawn in the
> lightest colors, which seems to contradict the setting in the source TIFF
> file. In the image I've attached, the lowest value pixels are draw in the
> darkest colors, which is consistent with the specification in the TIFF
> image. Is there some setting in the application you used that overwrites
> the settings from the TIFF file?
>
> !ISSUE_267.JPG!
>
>
>
> > Colorful rendering of b/w Monoband TIF
> > --------------------------------------
> >
> > Key: IMAGING-267
> > URL: https://issues.apache.org/jira/browse/IMAGING-267
> > Project: Commons Imaging
> > Issue Type: Bug
> > Reporter: edgar soldin
> > Priority: Major
> > Attachments: ISSUE_267.JPG, mdt25a-commons.png,
> mdt25a-sextante.png, mdt25a.tif
> >
> >
> > see attached images.
> > mdt25a.tif - the original tif
> > mdt25a-commons.png - as rendered/read with Commons Imaging
> > mdt25a-sextante.png - as rendered /read properly with ImageIO-Core from
> https://github.com/jai-imageio/jai-imageio-core
> > thanks!.. ede
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>
>
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
