[
https://issues.apache.org/jira/browse/IMAGING-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200942#comment-17200942
]
Giuseppe Aruta commented on IMAGING-267:
----------------------------------------
Hi Gary,
this is my comments to your questions. Sorry for the delay.
_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
GIS ([https://ec.europa.eu/environment/archives/seis/case_sextantegis.htm)] and
had no attached crs . I think this image is related to an UTM zone in Spain.
Sextante has bindings for some java GIS software, included OpenJUMP. We use
that image because is freely available and used in the manuals of Sextante
_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 the datas of that image are elevations
_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?_
Jukka has already answered to the question. I can add that in some situation
OpenJUMP uses the method JAI.create("extrema") to calculate statistics: for
png or jpg files, but I think also for tiff file if other methods do not work
_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?_
Even for this question, following Jukka's explanation, I can add that OpenJUMP
builds a bufferedImage to display into the view. A regular RGB image is
displayed according to the original colours, while the image to display of a
monoband raster is rebuild creating a map of colour (in this case a gradual
variation of greys) to cover the entire range of the values. In this way
OpenJUMP build a separate symbology which, in turn, can be modified (different
range of colours, discrete or continuous, etc). A legend that correlate colors
to values/range of values is availble.
The image TIF seems reverted. Possibly that was a decision of the developer of
the Sextante Raster framework in OpenJUMP (called RasterImageLayer framework).
I think that the decision was taken as, some frequent raster processes create
output with very few sample with very high values (scattered in the map or
along lines) and the great magiority of values with very low values. In this
case the visual effects would have been a big black rectangular. Having a
reverted colormap helps to define it better.
> 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.tfw, mdt25a.tif, mdt25a.tif.aux.xml
>
>
> 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)
