Thank you for the reply Yeti.
I see that Gwyddion supports .hdr reading but no .hdr writing. Is it
difficult to write an .hdr exporter? hdr is supported by ITK. ITK also
supports the creation of such images. So you might not even have to study
the specs. DICCOM and NRRD formats are also very popular in medical
community for data representation, since the pixel values can be literally
anything (doubles, vectors, you name it). In fact, the output of CT and MRI
scanners is DICOM series. Of course, the best choice is ITK's native image
format MHA.
Meanwhile, I might need to write my own "dummy" MHA exporter just to get the
job done, since I have a timetable to follow. Which brings me to the next
question: Is it better to start from the raw data (usually in excell format)
and export to an ITK format, or start from the STP image? Precision-wise.
And my last (newbie-ish question) is as follows: I am searching for the
specs of the STP format, but completely unsuccessfully... Does anybody know
where to get it from?
Best Regards,
Panagiotis Foteinos
On Wed, May 11, 2011 at 3:19 AM, David Necas (Yeti) <[email protected]>wrote:
> On Tue, May 10, 2011 at 06:03:26PM -0400, Panagiotis Foteinos wrote:
> > Before I use the nan module, however, I need to be sure that I understand
> > the export modules to png/jpg. Please, let me know if I should address
> this
> > email to the mailing list.
>
> It would be definitely better to send it to the list but anyway...
>
> > The online documentation states that the export of stp images to png or
> jpg
> > is lossy. In the multidisciplinary project I am involved, however, we
> cannot
> > use very lossy data. Precision matters. Also, we cannot work directly on
> stp
> > images. The reason is that we have to process these images using the
> popular
> > *Insight Segmentation and Registration Toolkit (ITK)*; sadly, ITK does
> not
> > support stp images yet. Nevertheless, we can use Gwyddion if the export
> from
> > stp to png/jpg is not "very" lossy.
>
> JPEG is the absolutely worst possible choice for data because the format
> has only 8bit depth (at least standard JPEG), it is inherently lossy and
> leads to DCT artefacts in the image.
>
> PNG or TIFF can be better but if precision matters image formats should
> not be used for data at all. Aside from HDR formats such as OpenEXR
> they have seriously limited dynamic range. And usually they do not have
> any standard means to specify the relation to physical values. So in
> Gwyddion, they are used for presentation, not data representation.
>
> I can implement support for some of the other ITK-supported formats if
> it is better for data (and if documentation and sample files are
> available).
>
> > 1) I have a height stp image which has also negative float values for
> some
> > pixel values. When I convert it to png I get only positive floats. Did
> any
> > normalization happen? If so, what is the formula? I should at least know
> > where the value '0' of a pixel in the initial stp image maps in the
> > resulting png image.
>
> Yes, the image is normalised. In image export, the minimum data value is
> mapped to 0 and the maximum data value to the maximum possible value
> (usually 255 or 65535; more precisely it is 256-ε and 65536-ε and then
> rounding down is used) to minimise loss of information due to value
> discretisation.
>
> > 2) Apart from intensity mismatch, I also observed spacing incosistencies.
> > For example, Gwyddion reports that the pixel spacing of an stp image is
> > (0.04μmx0.04μm). When I convert it to a png file and then import that png
> > file back to Gwyddion, the spacing is different: it is now
> (0.05μmx0.05μm).
>
> The exported image is just presentation. It bears no information about
> physical scales. The import dialog *asks* for physical scales so you
> get whatever you enter there.
>
> > Are the above inconsistencies expected? Is this due to the fact that the
> png
> > export is lossy or because there is a bug?
>
> Yes, this behaviour is expected and it is not considered to be
> inconsistent because images formats are poor data formats.
>
> Gwyddion 2.25 will save 16bit PNG and PGM with extra information that
> permits direct loading back to Gwyddion without having to specify
> physical scales manually. In case of PNG, the extra information should
> be understandable also to other software, don't know about ITK. But
> still I do not recommend using image formats for data.
>
> Regards,
>
> Yeti
>
>
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gwyddion-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gwyddion-users
