First thing to know is, are there many persons suffering from
this? Right now, from what Thorsten and Ron just wrote, it
seems more of a mis-configured Photoshop than anything else.
If lot of people have such problems, it could be time for a
new entry in the VFAQ (along the lines "there are lots of
ways to write jpeg files, please try all the settings your
application has").

-- 
Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
 Mes propos n'engagent que moi et en aucun cas mes employeurs

Post a reply to this message

In article <3BB### [at] sycomorefr> , Adrien Beau 
<adr### [at] sycomorefr>  wrote:

> First thing to know is, are there many persons suffering from
> this? Right now, from what Thorsten and Ron just wrote, it
> seems more of a mis-configured Photoshop than anything else.
> If lot of people have such problems, it could be time for a
> new entry in the VFAQ (along the lines "there are lots of
> ways to write jpeg files, please try all the settings your
> application has").

No, we actually have reports from other people with different programs that
also cause problem.  The main reason it is so hard to fix is that POV-Ray
actually uses the same JPEG library almost all other free programs use (the
Independent JPEG group's library).  So in theory there should be no problem
at all, but for some odd reason there is.  I have a copy of the JPEG
standard somewhere, and if/when my time permits I do plan to look into it,
but not this week...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

3bb1e7bc$1@news.povray.org...
>
> 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 ?

Microsoft Image Composer : OK
Picture Publisher 8 : not OK
Painter Classic : OK
Gimp for Windows : OK if native, but not-OK files can stay that way even
when resaved.

There may be also some big commercial application not working because every
JPEG map I tested from Poser or DAZ3D is refused by Povray.

G.

--

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

Post a reply to this message

On Wed, 26 Sep 2001 10:56:09 -0400, Thorsten Froehlich wrote:
>In article <3BB### [at] sycomorefr> , Adrien Beau 
><adr### [at] sycomorefr>  wrote:
>
>> First thing to know is, are there many persons suffering from
>> this? Right now, from what Thorsten and Ron just wrote, it
>> seems more of a mis-configured Photoshop than anything else.
>> If lot of people have such problems, it could be time for a
>> new entry in the VFAQ (along the lines "there are lots of
>> ways to write jpeg files, please try all the settings your
>> application has").
>
>No, we actually have reports from other people with different programs that
>also cause problem.  The main reason it is so hard to fix is that POV-Ray
>actually uses the same JPEG library almost all other free programs use (the
>Independent JPEG group's library).  So in theory there should be no problem
>at all, but for some odd reason there is.  I have a copy of the JPEG
>standard somewhere, and if/when my time permits I do plan to look into it,
>but not this week...

It might really be our problem.  An image Gilles provided that refuses to parse
at all under POV works okay with djpeg.  Here's what djpeg says in the debug
output:

Independent JPEG Group's DJPEG, version 6a  7-Feb-96
Copyright (C) 1996, Thomas G. Lane
Start of Image
JFIF APP0 marker, density 72x72  1
Skipping marker 0xed, length 4490
Skipping marker 0xe2, length 3160
Adobe APP14 marker: version 100, flags 0x8000 0x0000, transform 1
Define Quantization Table 0  precision 0
Define Quantization Table 1  precision 0
Start Of Frame 0xc0: width=932, height=933, components=3
    Component 1: 2hx2v q=0
    Component 2: 1hx1v q=1
    Component 3: 1hx1v q=1
Define Restart Interval 59
Define Huffman Table 0x00
Define Huffman Table 0x01
Define Huffman Table 0x10
Define Huffman Table 0x11
Start Of Scan: 3 components
    Component 1: dc=0 ac=0
    Component 2: dc=1 ac=1
    Component 3: dc=1 ac=1
  Ss=0, Se=63, Ah=0, Al=0
End Of Image

-- 
#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

"Gilles Tran" wrote :

> Microsoft Image Composer : OK
> Picture Publisher 8 : not OK
> Painter Classic : OK
> Gimp for Windows : OK if native, but not-OK files can stay that way even
> when resaved.

Let me add :

XnView : OK
Corel Photo Paint 8 : OK
CompuPic Pro : OK
Microsoft Photo Editor (W2K) : OK

(all I had at hand at work, I'll test others at home).

P.S. : I see you are using Painter Classic.  Does it mean you are the
lucky owner of some graphic tablet ?  (I just bought a Wacom Intuos A5
myself).

Fabien.

Post a reply to this message

On 26 Sep 2001 11:12:33 -0400, Ron Parker wrote:
>It might really be our problem.  An image Gilles provided that refuses to parse
>at all under POV works okay with djpeg.  Here's what djpeg says in the debug
>output:

AHA!

It turns out that the skip routine is supposed to skip in the buffer as well
as in the file.  I've just made a change that should fix this once and for
all (next beta, you know the drill...)

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

> It turns out that the skip routine is supposed to skip in the buffer as
well
> as in the file.  I've just made a change that should fix this once and for
> all (next beta, you know the drill...)

Aaah, BIG thanks...
Now, since you're at it, what about this little thingy about TIFF files
being inverted in uv-maps :-) I know it's not top priority bug but still...

G.

--

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

>
> --
> #macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_
z)R(-z _-z)
> R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro
S(_)9-(_1-
> _)*(_1-_)#end#macro Z(_1 _
__)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
> rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate
x*90}

Post a reply to this message

On Thu, 27 Sep 2001 17:54:38 +0200, Gilles Tran wrote:

>> It turns out that the skip routine is supposed to skip in the buffer as
>well
>> as in the file.  I've just made a change that should fix this once and for
>> all (next beta, you know the drill...)
>
>Aaah, BIG thanks...
>Now, since you're at it, what about this little thingy about TIFF files
>being inverted in uv-maps :-) I know it's not top priority bug but still...

Just UV-maps, or everywhere?  It seems that we ignore what the TIFF library
tells us about the orientation of the image.  Whether that's something that'll
be easy to fix is anybody's guess, but it seems like it should affect more
than just UV maps.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

> Just UV-maps, or everywhere?  It seems that we ignore what the TIFF
library
> tells us about the orientation of the image.  Whether that's something
that'll
> be easy to fix is anybody's guess, but it seems like it should affect more
> than just UV maps.
>
Yes, you're right. Regular mapping has to be inverted as well to work
properly. There's more, in fact, as even with the scaling <1,-1,1> is
applied as a workaround, the uv still doesn't look right (it's a mirror
image). Or is it a mesh2 problem ???
I posted a test scene in beta-test.binaries.

G.

--

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

> --
> plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip
x}rotate
> z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red
1rotate 60
> *z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb
z}text{ttf"arial.ttf"
> "RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron
Parker

Post a reply to this message