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