[
https://issues.apache.org/jira/browse/IMAGING-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199981#comment-17199981
]
edgar soldin commented on IMAGING-267:
--------------------------------------
is there a way to answer per mail but retaining the quotes? ticket system seems
to have removed them.
this is what the complete answer looked like
On 22.09.2020 02:06, Gary Lucas (Jira) wrote:
>
> [
> 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?
i attached the accompanying world/stat files. wasn't aware they might be needed
for the rendering
> 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.
indeed it is. but i am totally out of my depths for answering most of the rest
of your questions. i will relay it to others in our project and hopefully they
can contribute to this issue.
> 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?
as far as the reader is concerned yes. you might wanna try those i mentioned in
the first post.
there maybe some special handling in the JAI operations of the render chain
that i am not aware of right now though.
> 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?
sounds reasonable, but needs to be answered by our raster guys.. we will come
back to you. thanks so far! ..ede/OJ
ps. is there a way to wrap apache commons imaging readers into a RenderedOp? or
actually, what is the most memory efficient way to render apache commons
imaging accessed images?
> 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)
