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