W3C home > Mailing lists > Public > www-svg@w3.org > November 2002

Re: Identical rendering? [was Re: SVG 1.2 General feedback]

From: Tobias Reif <tobiasreif@pinkjuice.com>
Date: Thu, 21 Nov 2002 17:12:16 +0100
Message-ID: <3DDD05E0.6030502@pinkjuice.com>
To: www-svg@w3.org

Thomas E Deweese wrote:


>     As I said I agree with the sentiment but there are lots of reasons
> not to change the situation.  I think that doing what you suggest
> represents a significant tradeoff between innovation and
> standardization. 


I don't want an extreme with lots of disadvantages, I just could imagine 
a better compromise; but that's up to you, the implementers, and the 
spec authors to investigate and decide. I just wanted to express that 
this is something that is important for me, and probably others, but I 
don't have the solution.

> I don't think we are in a position to standardize
> the rendering to the extent you are asking for right now, there is no
> clear 'golden standard' for anti-aliased rendering.


I see. But for a lot of the other aspects of SVG, the spec does specify 
the standard to be followed.


>     You also just deleted all of _my_ concerns on this topic, at least
> I took the time to respond to yours...


Sorry. I didn't have top say much about them, but I didn't want to 
offend you, if that's the case.


>     Suggestions?


I'm also looking forward to seeing some, eg from others :)


>     I know you suggested 'no curve smoothing'.  How do you test that
> as a conformance criteria? Like in this case I actually don't think
> Adobe is curve smoothing, I think you are just seeing differences in
> how the two implementations do anti-aliasing.


I see. I never really suspected any specific reason, as I'm no 
implementation expert.

> Even if Adobe is doing
> curve smoothing or Java2D is dropping points due to zoom level, how do
> you 'prove' this to say one is conformant and the other
> non-conformant?


This is a problem to be solved IMHO. Wouldn't it be relatively simple to 
automatically compare pixel for pixel against a reference PNG?

The test suite includes tests that don't get "proven", but compared, 
which is what I did with my screen shots.


>     The only thing you are left with is visual difference


... which is the case for all static test cases.

> - which is
> what you want (I think). Then you get into the question of; What is a
> visual difference?  Who's vision?  Under what viewing conditions?
> 8bit (hand held) 16bit (many laptops) 24 bit (most desktop) 30 bit
> (high end medical)?  LCD, CRT, OLED, Plasma? What Phosphor set? What
> about printing (4inks, 6inks..)?


Again: the different shots were made on the same platform and box. At 
least in these situations I would like to get more cosistent rendering, 
and be able to request it from implementers, via the spec.


>     All of these can play a very important role in something being
> 'visually different'.


Sure; but if I have one SVG on one box, and two conformant viewers, then 
there should be greater similiarity.


>     Also what implementation get's to specify the golden standard for
> comparison of 'no visual difference'?


None; the spec specifies what's conformant, as with any other aspect of SVG.


Tobi

-- 
http://www.pinkjuice.com/
Received on Thursday, 21 November 2002 11:12:15 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:23 GMT