Image conversion self-answer

radiance-dev
1

I guess the answer is: use some third-party convesion
image program from PIC to TIFF or BMP to PNG.

Goofy Windows confused me: I went through multiple
formats conversion process and it turns out that
Windows pre-intalled image viewer (and also Paint) can
not view grayscale images in their own native BMP
format!

Using Adobe's ImageReady or PhotoShop displayed
grayscale BMP derived from the original PIC just fine.

I'll stop messing with conversion to PNG unless more
knowledgeable people here know that some precious info
gets lost without direct conversion.

Tony

···

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2

AFAIK, there are no hidden secrets in a Radiance pic.

You may know that already, the most important thing getting lost during conversion is of course the HDR character. There is a lot of awkward color math in this step from radiance data (W/m2sr) in three color channels to rgb values, of which e.g ra_t16 or ra_tiff is taking care of.

I for example convert to TGA and then use GIMP (the Linux equivalent of Photoshop) for postprocessing and conversion. I doubt that it pays off writing an extra converter to go directly from pic to png jpeg

-cb

3

Carsten Bauer wrote:

AFAIK, there are no hidden secrets in a Radiance pic.

You may know that already, the most important thing getting lost during
conversion is of course the HDR character. There is a lot of awkward
color math in this step from radiance data (W/m2sr) in three color
channels to rgb values, of which e.g ra_t16 or ra_tiff is taking care of.

The mechanics of conversion are the same for all formats, so
that's not a problem at all. The main reason why there are not
more formats currently supported is that Greg hates third party
library dependencies. The tifflib is currently the only
exception, mainly because that was (and probably still is) the
most common lossless format, which even supports HDR data
nowadays.

The situation of JPEG is shady at the moment, due to some
patent claims. This caused the IEEE to discuss the depreciation
of the JPEG format as an official standard. Nobody seems to
know where that will lead eventually.

I'd be in favour of adding PNG support though, which has been
carefully designed to steer clear of intellectual property claims.
The libPNG offers a variety of losslessly compressed formats in
various bit depths. The library seems robust, and both the
specification and the API are stable. Since early this year, PNG
is also an ISO standard, so we can count on it staying around in
a backwards compatible manner for a long time.

Any folks with too much time on their hands are invited to
contribute...

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

4

For image conversion (cli), I would strongly suggest ImageMagick (www.imagemagick.com). This toolset is available in source and compiled forms (for both windows and linux). It contains some very powerful tools such as: convert, mogrify and composite are a few. In many cases these tools can be used to deal with most image processing issues, then and only then do you need to consider doing things by hand with photoshop or gimp. On a side note, along with Carsten, I am a big fan of Gimp! Although I have never messed with it, gimp can also be driven from the command line for batch type processing.

-Jack

Carsten Bauer wrote:

···

AFAIK, there are no hidden secrets in a Radiance pic.

You may know that already, the most important thing getting lost during conversion is of course the HDR character. There is a lot of awkward color math in this step from radiance data (W/m2sr) in three color channels to rgb values, of which e.g ra_t16 or ra_tiff is taking care of.

I for example convert to TGA and then use GIMP (the Linux equivalent of Photoshop) for postprocessing and conversion. I doubt that it pays off writing an extra converter to go directly from pic to png jpeg

-cb

_______________________________________________
Radiance-dev mailing list
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

5

In addition to gimp, Radiance users may benefit from using
cinepaint (http://cinepaint.sourceforge.net/) for image
manipulation. It operates natively on >24-bit file formats,
though it does not have a Radiance .pic-reader. I use it to make
minor adjustments on 16 bpc TIFFs before reducing my work to
8-bit and sending it to the printer.

There are versions for Mac, Windows, and Linux.

Mark
mstock@umich.edu

···

On Mon, 4 Oct 2004, Jack de Valpine wrote:

For image conversion (cli), I would strongly suggest ImageMagick
(www.imagemagick.com). This toolset is available in source and compiled
forms (for both windows and linux). It contains some very powerful tools
such as: convert, mogrify and composite are a few. In many cases these
tools can be used to deal with most image processing issues, then and
only then do you need to consider doing things by hand with photoshop or
gimp. On a side note, along with Carsten, I am a big fan of Gimp!
Although I have never messed with it, gimp can also be driven from the
command line for batch type processing.

-Jack

Carsten Bauer wrote:

> AFAIK, there are no hidden secrets in a Radiance pic.
>
> You may know that already, the most important thing getting lost
> during conversion is of course the HDR character. There is a lot of
> awkward color math in this step from radiance data (W/m2sr) in three
> color channels to rgb values, of which e.g ra_t16 or ra_tiff is taking
> care of.
>
> I for example convert to TGA and then use GIMP (the Linux equivalent
> of Photoshop) for postprocessing and conversion. I doubt that it pays
> off writing an extra converter to go directly from pic to png jpeg

6

Hi All,

From: Georg Mischler <schorsch@schorsch.com>
Date: October 4, 2004 5:30:55 AM PDT

The mechanics of conversion are the same for all formats, so
that's not a problem at all. The main reason why there are not
more formats currently supported is that Greg hates third party
library dependencies. The tifflib is currently the only
exception, mainly because that was (and probably still is) the
most common lossless format, which even supports HDR data
nowadays.

That is correct. I have experienced a lot of frustration myself, especially with OpenSource software, trying to get all the prerequisites compiled for some package in order to try it out. I have always tried to avoid this situation in Radiance by making it as uniform and self-contained as practical. The TIFF library is the only exception, and though it is well-written and portable, it still causes compilation troubles on some systems (most notably Solaris these days).

The situation of JPEG is shady at the moment, due to some
patent claims. This caused the IEEE to discuss the depreciation
of the JPEG format as an official standard. Nobody seems to
know where that will lead eventually.

Is this regarding the original DCT-based JPEG, or the new wavelet-based JPEG 2000? I hadn't heard of any patent cases related to the original JPEG, but I haven't really been paying attention to the IEEE, either. I never saw much sense in distributing JPEG as part of Radiance because if you can compile Tom Lane's libjpeg, you get cjpeg and djpeg which interface nicely with ra_ppm or (now) ra_bmp. The latter even does quick tone-mapping.

I'd be in favour of adding PNG support though, which has been
carefully designed to steer clear of intellectual property claims.
The libPNG offers a variety of losslessly compressed formats in
various bit depths. The library seems robust, and both the
specification and the API are stable. Since early this year, PNG
is also an ISO standard, so we can count on it staying around in
a backwards compatible manner for a long time.

As long as it doesn't cause hitches on different compilers, I wouldn't be opposed. I generally agree with the philosophy behind PNG, though I don't know why they didn't include a high dynamic-range format amongst their myriad encoding options.

-Greg

7

Greg Ward wrote:

> The situation of JPEG is shady at the moment, due to some
> patent claims. This caused the IEEE to discuss the depreciation
> of the JPEG format as an official standard. Nobody seems to
> know where that will lead eventually.

Is this regarding the original DCT-based JPEG, or the new wavelet-based
JPEG 2000?

This must be the old format. It also appears that the patent
will expire in 2006. Fogent has just sued three dozen large
corporations about it this year, although the applicability of
the patent to the actual JPEG format is still under debate.
Several companies (including Sony) have bought licenses for
tens of millions of dollars so far.

JPEG 2000 is covered by some known patents, but those have been
released for use without fee. How much is this format already in
use? As it seems to be lossless, it looks very promising.

As long as it doesn't cause hitches on different compilers, I wouldn't
be opposed. I generally agree with the philosophy behind PNG, though I
don't know why they didn't include a high dynamic-range format amongst
their myriad encoding options.

Probably because nobody shouted loud enough about it at the time
of design.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

8

Georg Mischler wrote:

Greg Ward wrote:

Is this regarding the original DCT-based JPEG, or the new wavelet-based
JPEG 2000?

JPEG 2000 is covered by some known patents, but those have been
released for use without fee. How much is this format already in
use? As it seems to be lossless, it looks very promising.

AFAIK wavelet compression isn't lossy. Compression involves thresholding and removing coefficients, so there's inevitable loss. However, wavelets adapt well to signal features, largely due to their local support, so the loss may not be as noticeable as with the old JPEG. I would imagine contours are well preserved with this method and don't exhibit the obnoxious ringing artifacts we've all come to hate from standard JPEG with high compression rates.

--Roland

···

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)

9

Roland Schregle wrote:

AFAIK wavelet compression isn't lossy.

Ahem... of course it *IS* lossy... kinda like my communications skills...

···

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)

10

Roland Schregle wrote:

AFAIK wavelet compression isn't lossy.

Ahem... of course it *IS* lossy... kinda like my communications skills...

We knowed what you meaned....

Actually, though, I believe Schorsh is right. There is a "lossless" version of JPEG 2000 that exactly reproduces the 8-bit input values using wavelet compression, though this isn't the mode most folks are expected to use. Likewise, JPEG is "almost lossless" if the quantization tables are set to all zeroes, but due to round-off error, the 8-bit values you get back are sometimes off by one or two counts.

This of course begs the question, what does it mean to record 8-bits/channel "losslessly?" So much information has been lost in deriving those 8 bits, that the exact reproduction afterwards is mostly a joke.

My two bits.
-Greg

11

Greg Ward wrote:

self-contained as practical. The TIFF library is the only exception, and though it is well-written and portable, it still causes compilation troubles on some systems (most notably Solaris these days).

So far, the libtiff stuff never compiled on my Linux box either, but I didn't care about it and thus didn't examine the problem further :slight_smile:

-cb