To the POV Team:

I have a request to add JPEG as an option for rendered images.  The library
and files can be found at:

http://support.intel.com/support/performancetools/libraries/ijl/index.htm

Post a reply to this message

In article <38ad6b4e@news.povray.org> , "Mike Weber" <mik### [at] pyxiscom>
wrote:

> To the POV Team:
>
> I have a request to add JPEG as an option for rendered images.  The library
> and files can be found at:
>
> http://support.intel.com/support/performancetools/libraries/ijl/index.htm


To quote from the Intel site:

"Intel JPEG Library System Requirements

The Intel JPEG Library runs on Intel Architecture-based personal computers
running Microsoft Windows. The library integrates into an application or
library written in C or C++. The Intel JPEG Library requires the following
hardware and software:

Hardware
Intel Pentium processor-based system (a Pentium, Pentium Pro, Pentium with
MMX technology, Pentium II, or Pentium III processor-based system) 8 MBytes
RAM (32 MBytes RAM recommended)

Software
Microsoft Windows 95/98, Windows NT 4.0 or higher A C++ compiler: Intel
C/C++ Compiler version 2.4 or higher, or Microsoft Visual C++ version 4.0 or
higher"


However, there is a free JPEG library available which is cross platform. The
issue of JPEG output has previously been discussed in this newsgroups and
JPEG output is unsuitable for POV-Ray (just search a few month back to find
a thread on it). JPEG input is another issue.


        Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> The issue of JPEG output has previously been discussed in this
> newsgroups and JPEG output is unsuitable for POV-Ray (just search a
> few month back to find a thread on it). JPEG input is another issue.

A thousand pardons, but I thought it was using JPEG output that was
okay, but that it lacked the quality needed for input.  Am I
remembering things incorrectly?

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

In article <38AD814A.5A3E5BC1@erols.com> , John VanSickle 
<van### [at] erolscom>  wrote:

>> The issue of JPEG output has previously been discussed in this
>> newsgroups and JPEG output is unsuitable for POV-Ray (just search a
>> few month back to find a thread on it). JPEG input is another issue.
>
> A thousand pardons, but I thought it was using JPEG output that was
> okay, but that it lacked the quality needed for input.  Am I
> remembering things incorrectly?

Yes, you do.


     Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

John VanSickle wrote:
> 
> A thousand pardons, but I thought it was using JPEG output that was
> okay, but that it lacked the quality needed for input.  Am I
> remembering things incorrectly?
> 

Output was considered not OK, becaus of unpredictable, lossy compression.
Input is OK, because many image maps are originally in JPEG anyway and
converting them to a non-lossy format won't help any.

Margus

Post a reply to this message

>Output was considered not OK, becaus of unpredictable, lossy compression.
>Input is OK, because many image maps are originally in JPEG anyway and
>converting them to a non-lossy format won't help any.


So when will we get it for input? I have several projects that would happily
work with JPEG. I would save a lot of HD space from having to turn textures
into PNG all the time.

Post a reply to this message

In article <38adca10@news.povray.org> , "TonyB" <ben### [at] panamac-comnet>
wrote:

> So when will we get it for input? I have several projects that would happily
> work with JPEG. I would save a lot of HD space from having to turn textures
> into PNG all the time.

As you know, the POV-Team does not give any exact details about new versions
or their release dates :-)


        Thorsten

Post a reply to this message

On Fri, 18 Feb 2000 10:50:15 -0600, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>JPEG output is unsuitable for POV-Ray (just search a few month back to find
>a thread on it). JPEG input is another issue.

Funny, it comes in pretty handy for IRTC submissions and you will also
find several "unsuitable" jpeg images here on this news server.   :)

My point is that while JPEG images are certainly compromised in
quality, there are certainly good uses for them. It would be nice if
POV-Ray could support them directly, instead of relying on external
software. This should be an option that the *user* gets to decide
whether or not to use. I'm very tired of some programmers deciding
that since *they* don't want to use a potential feature, that no one
else should have the option of using it either. This sort of thinking
only hurts the potential of POV-Ray. 

I assume I'll be flamed for saying that, but I think it needed to be
said.

Believe me, if I could handle the programming myself, I'd write a JPEG
patch personally. In fact, it has already been done by a few different
people, but it was never incorporated into the Official POV, nor did
it find it's way into SuperPatch, or Mega-POV. If anyone wants JPEG
support currently, they can always use IMP-POV. Unfortunately, it is
based on Official POV, and not Mega-POV, which is my favorite.


later,
Glen Berry

Post a reply to this message

Glen Berry wrote:

>If anyone wants JPEG
>support currently, they can always use IMP-POV.

Is JPEG compression (in IMP-POV) a post process? If so could you have both 
an uncompressed and a compressed image as output? Don't know what the gain 
of that would be though.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

> :-)


That little smiley just said a mouthful. :)

Post a reply to this message

It's always good to have an uncompressed version of image for archive/backup
purposes, because if you want to do anything with that image at a later date and
it's en JPG it will just get more and more lossy. But it would be nice to not
have to open up another program to compress it. How about a built-in JPEG
compressor and have it save both versions of the file...
Then again, the best JPEG compressors like found in PhotoShop and Micrografx are
pretty big and fancy for a freeware program...

--
___     ______________________________________________________
 | \     |_                 <dav### [at] faricynet> <ICQ 55354965>
 |_/avid |ontaine               http://www.faricy.net/~davidf/

"Sitting on a cornflake, waiting for the van to come" -Beatles

Post a reply to this message

JPEG as input would be ok. We have GIF as input already, so no big deal.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: My point is that while JPEG images are certainly compromised in
: quality, there are certainly good uses for them. It would be nice if
: POV-Ray could support them directly, instead of relying on external
: software.

  I think that povray is a renderer, not an image processing program.
  The idea is to get the result of the calculations in a lossless popular
format for further manipulation. There are plenty of image processing and
converter programs. IMHO povray doesn't need those features.
  JPEG input is a different story.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:

>   JPEG as input would be ok. We have GIF as input already, so no big deal.

I thibk GIF is no big deal, but it is lossless. JPEG is lossy, and might not
be reconstituted in the same manner all the time.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Jon A. Cruz <jon### [at] geocitiescom> wrote:
: I thibk GIF is no big deal, but it is lossless.

  It depends on how you define "lossless".
  GIF is lossless for a 256-color image. However, if you try to save a
truecolor image in GIF format, it will be lossy (it has to convert the
image to 256 colors).

: JPEG is lossy, and might not
: be reconstituted in the same manner all the time.

  Does it matter? If one pixel is one value (out of 256) more reddish with
povray than with another program, is it a big deal? I think no-one will
notice the difference.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>I think GIF is no big deal, but it is lossless. JPEG is lossy, and might
not
>be reconstituted in the same manner all the time.


How so?

Post a reply to this message

TonyB <ben### [at] panamac-comnet> wrote:
:>JPEG is lossy, and might not
:>be reconstituted in the same manner all the time.

: How so?

  I don't know the specifics of the JPEG compression/decompression, but as
far as I know, the image data is stored as a kind of frequency spectrum.
When decompressing, this spectrum has to be converted back to regular data
(rather complicated math...). Many inaccuracies may occur in this process
(I don't know if floating point numbers has to used for this process, but
specially if they have, then inaccuracies are most likely to occur).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 20 Feb 2000 14:46:35 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:

>(I don't know if floating point numbers has to used for this process, but
>specially if they have, then inaccuracies are most likely to occur).

I have programs that allow selecting floating point or integer
routines for jpeg decompression. The floating point routines are
considered slower, but more accurate by these programs.

for what it's worth...

Glen Berry

Post a reply to this message

Nieminen Juha wrote:

> Jon A. Cruz <jon### [at] geocitiescom> wrote:
> : I thibk GIF is no big deal, but it is lossless.
>
>   It depends on how you define "lossless".
>   GIF is lossless for a 256-color image. However, if you try to save a
> truecolor image in GIF format, it will be lossy (it has to convert the
> image to 256 colors).
>
> : JPEG is lossy, and might not
> : be reconstituted in the same manner all the time.
>
>   Does it matter? If one pixel is one value (out of 256) more reddish with
> povray than with another program, is it a big deal? I think no-one will
> notice the difference.
>

Well, it might matter. Especially if some value goes on different sides of
some cut-off threashold. Also, if the interpretation varies from one version
to the next, or one platform to the next... BOOM!

Imagine tracking down subtle bump-map  bugs or normal-map bugs.

On the other hand, with a GIF image, once it has been created, there is no
ambiguity on it's interpretation, nor on the RGB values that any given pixel
within the image will contain. The same goes for PNG images.


Now, it might be possible to not really cause any problems at all. Then
again, it might. I just have a general aversion to using lossy formats for
any sort of source image. This probably comes from working in the multimedia
field for a few years.


--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

On Sun, 20 Feb 2000 14:39:02 -0800, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:

>Now, it might be possible to not really cause any problems at all. Then
>again, it might. I just have a general aversion to using lossy formats for
>any sort of source image.

So you have never used an image map that was based upon a JPEG file? I
dare say, that most of the people who have used image maps have done
this on occaision. It can turn out perfectly fine. The JPEG artifacts
of a potential source image aren't always a noticeable factor in the
final quality of a rendered image. In fact, I would say that *most* of
the time they aren't a problem at all.

Of course, if you want to buy larger hard drives for everyone to store
their image map collections on...        :)

later,
Glen Berry

Post a reply to this message

Glen Berry wrote:

> So you have never used an image map that was based upon a JPEG file? I
> dare say, that most of the people who have used image maps have done
> this on occaision. It can turn out perfectly fine. The JPEG artifacts
> of a potential source image aren't always a noticeable factor in the
> final quality of a rendered image. In fact, I would say that *most* of
> the time they aren't a problem at all.

I have in fact used image_maps that were originaly based on a jpeg image.

In all cases when I converted them to a suitable format that POV-Ray
would accept I also spent time running the image through processing
filters to enhance the quality of the image. This was done of course
to remove undesirable characteristics of the image produced by the
jpeg compression methods.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38ad6b4e@news.povray.org> , "Mike Weber" <mik### [at] pyxiscom>
wrote:

> I have a request to add JPEG as an option for rendered images.  The library
> and files can be found at:

As this issue comes up again and again, here is the answer to your feature
suggestion.
In April 1999 the POV-Team agreed to the following:

- JPEG image _input_ is implemented in POV-Ray 3.5.
- JPEG image output will _not_ be implemented in POV-Ray.


      Thorsten Froehlich


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> As this issue comes up again and again, here is the answer to your feature
> suggestion.
> In April 1999 the POV-Team agreed to the following:
> 
> - JPEG image _input_ is implemented in POV-Ray 3.5.
> - JPEG image output will _not_ be implemented in POV-Ray.

Thank you for that update, Thorsten.

As most of you are aware the POV-Team is generally not in the habit of
confirming what will or will not be available in the next release of
the program. This is one of those rare times they felt is would help
quiet the endless debates on this topic.

Please respect their decisions where adding new features are concerned.

-- 
Ken Tyler POV-Ray Technical Assistance Group Member

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: The floating point routines are
: considered slower, but more accurate by these programs.

  How old is this text? Floating points were slower in 386 and perhaps in
486, but in the new pentiums they aren't.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Sun, 20 Feb 2000 15:16:19 -0800, Ken <tyl### [at] pacbellnet> wrote:

>I have in fact used image_maps that were originaly based on a jpeg image.
>
>In all cases when I converted them to a suitable format that POV-Ray
>would accept I also spent time running the image through processing
>filters to enhance the quality of the image. This was done of course
>to remove undesirable characteristics of the image produced by the
>jpeg compression methods.

Ken, I don't doubt your word, but by any chance can you send me a
couple of these images and the scene files you tried to use them with?
Most of the JPEG images I've wanted to use for image maps have worked
just fine. I'd love to see first hand what the difference is between
your experiences and mine.

thanks,
Glen Berry

Post a reply to this message

On 21 Feb 2000 06:49:27 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:

>  How old is this text? Floating points were slower in 386 and perhaps in
>486, but in the new pentiums they aren't.

One of the programs I am thinking of was probably created before the
Pentium, or at the very latest, about the time the first Pentiums were
created.

My main point wasn't about speed, but the notion that the floating
point routines were considered more accurate. Don't let the "red
herring" of speed distract you. 

later,
Glen Berry

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: My main point wasn't about speed, but the notion that the floating
: point routines were considered more accurate.

  Then it means that integers were used in fixed point arithmetics (ie.
using integers as decimal numbers). Which would mean that floats are needed
for jpeg decompression.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Glen Berry wrote:

> Ken, I don't doubt your word, but by any chance can you send me a
> couple of these images and the scene files you tried to use them with?
> Most of the JPEG images I've wanted to use for image maps have worked
> just fine. I'd love to see first hand what the difference is between
> your experiences and mine.

See pbi subject "Attn: Glen Berry" for an example of the kinds of jpg
produced problems that I would normaly correct before using in POV-Ray.


-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message