STR #3476

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Post Text | Post File ]

STR #3476

Application:FLTK Library
Status:5 - New
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Image Support
Summary:nanosvg: rendering artecfacts under certain conditions (rounding?)
Version:1.4-feature
Created By:chris
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 chris
23:08 Jun 13, 2018
linecap.svg
0k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 chris
23:08 Jun 13, 2018
As exposed in the thread "A nice analog clock using nanoSVG" in fltk.general at:

  https://groups.google.com/forum/#!topic/fltkgeneral/OMkCAqk1qY0

nanosvg does not render certain images correctly.

Some debugging led me to the conclusion that the artefacts are introduced at the rasterization stage and are most probably caused by rounding errors due to fixed integer arithmetic.

I attach a simple test svg 'linecap.svg' that shows the effect: the rounded line cap at the bottom of the line is shifted 2 pixels to the left without any obvious reason. The error is very dependant on the angle of the line -> if the coordinates changes only slighty the error often goes away completely.

You can view this file e.g. with the pixmap_browser test program to see the artefact.

As a potential fix, I found changing the define for NSVG__FIXSHIFT
in 'nanosvgrast.h' to 14 (currently 10) makes the artefacts disappear.

To explain, let me simply cite Ian (Mac Arthur)'s response from the above mentioned thread:

---
"Well, it's a fixed-point number system, using integer maths: By
default they are using a shift of 10 bits, so assuming we are using a
32-bit integer (which seems like a safe assumption for now...) then we
have (setting aside the effect of sign bits etc) effectively 22-bits
of "integer" part and 10-bits of "fractional" part. (Or, 21-bits of
usable integer range, plus the sign bit...)

By setting FIXSHIFT larger, you are making for more resolution in the
fractional part, but at the cost of less range in the integral part -
something like 17-bits of integral range (plus the sign.)

Now, 17-bits of integral range might well be enough for a lot of
pictures, so maybe that is OK?"
---

As I read it, this change would still leave more than 130000 (2^17)
pixel range available, IMHO this should be enough for any picture.
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.