To the programmers,

I was very excited about the inclusion of JPEG image maps since I make
architectural models in a program that uses JPG textures.  I have
written a conversion to use this as a 'front end' to POVray by using TGA
clones of my JPG textures.

My question is:   Will the final version accept the file extension JPG
and JPEG?  This would simplify my conversion and greatly reduce my hard
disk space due to multiple copies of the same texture in various
formats.


I love this new interface,  Your efforts are GREATLY appreciated.


Thanks,

Dean

Post a reply to this message

On Tue, 25 Sep 2001 21:10:05 -0600, Dean wrote:
>My question is:   Will the final version accept the file extension JPG
>and JPEG?  This would simplify my conversion and greatly reduce my hard
>disk space due to multiple copies of the same texture in various
>formats.

Are you saying it doesn't?  I didn't think POV cared what the file 
extension was.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Although, regardless of which *file* extension you use, you still say "jpeg"
in the source itself...

jpeg "mypic.jpeg"

or

jpeg "mypic.jpg"

someone correct me if I'm wrong; I certainly haven't been right the majority
of the time so far!

- Slime
[ http://www.teja.nu/slime/ ]
[ http://www.teja.nu/slime/images/ ]

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Tue, 25 Sep 2001 21:10:05 -0600, Dean wrote:
> >My question is:   Will the final version accept the file extension JPG
> >and JPEG?  This would simplify my conversion and greatly reduce my hard
> >disk space due to multiple copies of the same texture in various
> >formats.
>
> Are you saying it doesn't?  I didn't think POV cared what the file
> extension was.
>
> --
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z
a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F
T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission
3-T}}}#end
> Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Ron

You are correct, POV will recognize either extension.  The problem is with the
format of the jpg I am using.
Each file that failed would open in all other viewers I have but not in POVray.
Re-saving the JPG from the graphics program seemed to fix the read error but the
textures had errors 'corrupt JPEG data'   X extraneous bytes before marker 0xdb.

The JPG textures had a section that was off set  by about one unit between tiles.
Not sure yet if this is a bug or a mistake I made converting the texture.  The
converted JPG still reads fine in the other program and renders OK in an Open GL
environment.

I will post a picture in the binaries forum under the same thread heading.

Thanks
Dean

Parker wrote:

> On Tue, 25 Sep 2001 21:10:05 -0600, Dean wrote:
> >My question is:   Will the final version accept the file extension JPG
> >and JPEG?  This would simplify my conversion and greatly reduce my hard
> >disk space due to multiple copies of the same texture in various
> >formats.
>
> Are you saying it doesn't?  I didn't think POV cared what the file
> extension was.
>
> --
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
> Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

3BB### [at] twoalphanet...
> Not sure yet if this is a bug or a mistake I made converting the
>texture.  The converted JPG still reads fine in the other program and
>renders OK in an Open GL > environment.
--

There's a problem reading some JPEGs (and TIFFs) that produces the effects
you describe (and more, as some JPEGs can't be read at all) but AFAIK no
solution has yet been found for it. The only known workaround is to try
another painting software to produce the file.

G.


**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

Dean <dea### [at] twoalphanet> wrote:
: You are correct, POV will recognize either extension.

  It's not that povray recognizes the extension. It's just that povray doesn't
care what the extension is. It can be .jpg, .jpeg, .myfancyimage or whatever
you wish.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Thanks to all,

I made the JPG file work without errors by saving it from a program called
LView Pro for Windows 95.  I set the file settings to be integer accurate and
to load this way.  I think the Adobe Photoshop JPG that it was originally, was
made to load 'fast' and not accurate.  I will experiment with this later today
and report back with more certainty.

Dean


Gilles Tran wrote:


> 3BB### [at] twoalphanet...
> > Not sure yet if this is a bug or a mistake I made converting the
> >texture.  The converted JPG still reads fine in the other program and
> >renders OK in an Open GL > environment.
> --
>
> There's a problem reading some JPEGs (and TIFFs) that produces the effects
> you describe (and more, as some JPEGs can't be read at all) but AFAIK no
> solution has yet been found for it. The only known workaround is to try
> another painting software to produce the file.
>
> G.
>
> **********************
> http://www.oyonale.com
> **********************
> Graphic experiments
> Pov-ray gallery

Post a reply to this message

In article <3BB1D33F.2C19078A@twoalpha.net> , Dean <dea### [at] twoalphanet>  
wrote:

> I think the Adobe Photoshop JPG that it was originally, was
> made to load 'fast' and not accurate.

Yes, it is very possible that the problem is the "load fast", which probably
implies it is the progressive encoding version (i.e. when you download a
picture you first would see a low quality version that gets better as the
download progresses).


    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

>
> There's a problem reading some JPEGs (and TIFFs) that produces the effects
> you describe (and more, as some JPEGs can't be read at all) but AFAIK no
> solution has yet been found for it. The only known workaround is to try
> another painting software to produce the file.

Maybe, before a solution is found, we could establish (trough our various
experiences) a list of software that writes jpeg's suitable for POV-Ray ?

Fabien.

Post a reply to this message

On Wed, 26 Sep 2001 10:17:56 -0400, Thorsten Froehlich wrote:
>In article <3BB1D33F.2C19078A@twoalpha.net> , Dean <dea### [at] twoalphanet>  
>wrote:
>
>> I think the Adobe Photoshop JPG that it was originally, was
>> made to load 'fast' and not accurate.
>
>Yes, it is very possible that the problem is the "load fast", which probably
>implies it is the progressive encoding version (i.e. when you download a
>picture you first would see a low quality version that gets better as the
>download progresses).

Progressive encoding isn't marker type 0xDB, though.  Here's what the JPEG
FAQ has to say about various Photoshop incompatibilities:

  Old decoders that don't handle progressive JPEG will often give rather
  cryptic error messages when fed a progressive JPEG.  If you get a complaint
  like "Unsupported marker type 0xC2", then you definitely have a progressive
  JPEG file and a non-progressive-capable decoder.  (See part 2 of this FAQ
  for information about more up-to-date programs.)  Or you may get a generic
  error message that claims the file is corrupted or isn't JPEG at all.

  Adobe Photoshop and some other prepress-oriented applications will produce
  four-channel CMYK JPEG files when asked to save a JPEG from CMYK image mode.
  Hardly anything that's not prepress-savvy will cope with CMYK JPEGs (or any
  other CMYK format for that matter).  When making JPEGs for Web use, be sure
  to save from RGB or grayscale mode.

  Photoshop also has a habit of stuffing a rather large thumbnail/preview
  image into an application-private segment of JPEG files.  Some other
  applications (notably early releases of Sun's Java library) are known to
  choke on this data.  This is definitely a bug in those other applications,
  but the best available workaround is still to tell Photoshop not to save
  a thumbnail.  If you're putting up an image on the Web, having a thumbnail
  embedded in it is just a waste of download time anyway.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message