I've been trying to generate some PNGs for my fledgling web site; mainly
so I can change the background colour without the shadows of my graphics
being the wrong shades - I can have graded transparency that I can't have
with GIFs.
I was wondering if anyone had any tips for this; I'm generating titles
with shadows for the tops of my pages. I have one particular problem
with this, and the only solution I've come up with is rather involved.
I'll describe my current situation:
-8<--------trim post if replying----------
I'm using Darren S's Spr2PNG app, which does the job well, and I'm also
using Compo to generate my graphics. This works well enough. I've been
able to generate my alpha channel fine.
I can use Compo's text mask and shadow facilities to generate my text
image. I then save this as a sprite and combine it with my my alpha
channel and make my PNG.
The problem is that the sprite output from Compo is already anti-aliased,
so for example if my background is white there is a single border pixel
of pastel colours around the egde as required - to remove jaggies.
Only problem is, the Alpha channel in the PNG is supposed to do this; it
fades out at the edges of the text. Consequently, the edges of my final
PNG are partly transparent with a hint of the original background
colour.
This isn't a major problem; it's only noticable if the background of the
web page is very different to the original background used (i.e. black
shows up a grey border in this case). It's just a nuisance; sort of
defeats the object of using PNGs.
-8<----------^--------------^-------------
Anyone else had similar problems using graphics with alpha channels?
Any advice?
--
To avoid being sent to a communal spam bin, remove the XXX to e-mail me.
You'll get a quicker response -- Iain Williamson
> The problem is that the sprite output from Compo is already anti-aliased,
> so for example if my background is white there is a single border pixel
> of pastel colours around the egde as required - to remove jaggies.
> Only problem is, the Alpha channel in the PNG is supposed to do this; it
> fades out at the edges of the text. Consequently, the edges of my final
> PNG are partly transparent with a hint of the original background
> colour.
Yup, you have found the fascinating problem with alpha blending - a
precalculated background colour.
It is possible to anti-alias without building-in a background colour, but
its mathematically much more complicated. I have built the ability into the
Vantage renderer, so (one day...) Vantage will be able to produce PNGs with
an alpha mask and no specified background colour.
Trouble is, bad PNG implementations (which is almost all of them :-) may do
no alpha blending at all, turning the alpha mask into a binary one at an
arbitrary threshold. You then end up with text with NO antialiasing at all -
much worse than antialiasing onto the average background colour!
For now (ie until PNG is better supported[1]) just stick to the closest-
background-colour method. Its crude, but so are those implementations!
Simon.
[1] In fact, don't hold your breath. PNG doesn't seem to be gaining any
ground compared to Flash, which has antialiasing (at render time) built
in.
--
------------------------------8<------------------------------
ne...@argonet.co.uk
Have you used the 'Sharpen' filter to give you that sharpen the text
outline?
Regards, Dave C.
--
__ __ __ __ __ ___ ________________________________________________
|__||__)/ __/ \|\ ||_ | / StrongArm Risc Pc (586x100PcCard)in ZFC & MAUG
| || \\__/\__/| \||__ |/ RINGS:- Acorn,SF Review & Classical Music.Also
_________________________/ Satellite,SF,DTP & AV.Email: d...@argonet.co.uk
Homepage (inc.free photos) http://www.argonet.co.uk/users/dac/index.html
[snip]
> The problem is that the sprite output from Compo is already
> anti-aliased...Consequently, the edges of my final PNG are partly
> transparent with a hint of the original background colour.
Hmmm. Yup. :-(
> This isn't a major problem; it's only noticable if the background of the
> web page is very different to the original background used (i.e. black
> shows up a grey border in this case). It's just a nuisance; sort of
> defeats the object of using PNGs.
>
> -8<----------^--------------^-------------
>
> Anyone else had similar problems using graphics with alpha channels?
> Any advice?
If you can, use blue (or blue tinted) backgrounds - the human eye is
much less sensitive to subtle changes in blue than other colours.
The next release of Compo will have _much_ better PNG support including
composited 'emulation' of Compo shadows that should improve what you get
(and how you go about getting it) a lot.
http://www.geocities.com/SiliconValley/7320/pngtst.htm
...has a couple of demos (use Browse, not Fresco to view!).
Rob.
--
Rob Davison.
http://www.geocities.com/SiliconValley/7320
[snip]
> For now (ie until PNG is better supported[1]) just stick to the closest-
> background-colour method. Its crude, but so are those implementations!
>
> Simon.
>
> [1] In fact, don't hold your breath. PNG doesn't seem to be gaining any
> ground
JNG, anyone? ;-)
(alpha channel masked JPEGs)
So is there any chance of Flash being supported in any shape or form by
Acorn browsers or image viewers/editors? I wish ...
--
John
Regards, Dave C. - a Compo fan
> I've been trying to generate some PNGs for my fledgling web site; mainly so
> I can change the background colour without the shadows of my graphics being
> the wrong shades - I can have graded transparency that I can't have with
> GIFs.
The problem is that there are broken PNG implementations out there which do
one of three things:
- treat the alpha channel as a simple mask (Fresco);
- ignore the alpha channel completely, unless the PNG has a bKGD chunk
(background colour), in which case it's rendered on that background
(Navigator, IE);
- render on a black or bKGD rectangle (Arcweb).
> I was wondering if anyone had any tips for this; I'm generating titles with
> shadows for the tops of my pages. I have one particular problem with this
> [...]
> I can use Compo's text mask and shadow facilities to generate my text
> image. I then save this as a sprite and combine it with my my alpha channel
> and make my PNG.
> The problem is that the sprite output from Compo is already anti-aliased,
Can you modify the image to give a few pixels' worth of bleed?
--
| Darren Salt | nr. Ashington, | Acorn | d youmustbejoking,demon,co,uk
| Risc PC, Spec+3, | Northumberland | Club | s zap,uk,eu,org
| A3010, BBC M128 | Toon Army | NE | @ retrospec,co,uk
| BMPSprite. DrawMerge. DrawShape.
Nothing is but what is not.
> Have you used the 'Sharpen' filter to give you that sharpen the text
> outline?
I have tended to stick with GIFs to keep things simple. (Although I plan
to switch to PNGs once they get easier/better... Rob? :-) )
The filters are quite useful for this kind of thing. However, as well as
the above you might like to experiment with the following 'tricks' when
creating GIFs as they can improve the results.
1) Try saving the canvas as a 16M colour sprite. Put yourself in a 256c
scren mode, then convert this to a 256c sprite with ChangeFSI *with
dithering OFF*. Then drop the result back into Compo, and export the
result as a GIF. This prevents the tendency for the canvas background and
image edges to be 'dithered' and have pixels punch through the
transparency or generate unwanted speckles. (Scaling down when using
ChangeFSI can also help.)
2) The shadow *should* tend to tint to the canvas colour. But as an
alternative: Make a copy of the text, make it grey-to-black and
transparent, then put it behind the main copy as a shadow. This will now
pick up some background tint.
I'd use PNGs more, myself, but alas at present only Browse (and
TechWriter) do a decent job of rendering them under RO. Both Fresco and
WXL exhibit limitations/problems that tend to defeat the point. :-(
Slainte,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
MMWaves http://www.st-and.ac.uk/~www_pa/Scots_Guide/MMWave/Index.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html
TechWriter http://www.st-and.demon.co.uk/TechWrite/Tips1.html
Dutton CDs http://www.duttonlabs.demon.co.uk/index.html
> In article <1ed9a83849%rdav...@xtr788438.xtra.co.nz>, Rob Davison
> <rdav...@xtra.co.nz> wrote:
> >
> > The next release of Compo will have _much_ better PNG support including
> Any chance of it being ready for the RISCOS'99 Show at the end of October?
> (in the UK)
>
> Regards, Dave C. - a Compo fan
I won't manage the show, but look forward to the release.
Also a Compo fan
--
...ElaineJ... Visit Jones' Pages at http://www.users.zetnet.co.uk/ejones
.on an Acorn. Corwen, North Wales; Steam Traction, with feature on Fodens;
..StrongArm.. Textures/Backdrops, Spring Graphics
...RISC PC... CMMGB with pics of pre- WW 1 Dawson & Yukon Volunteers.
> In article <493841DE2A%Iai...@rednova.demon.co.uk>, Iain Williamson
> <Iai...@rednova.demon.co.uk> wrote:
> >
> > Hi there!
> >
> > I've been trying to generate some PNGs for my fledgling web site; mainly
> > so I can change the background colour without the shadows of my graphics
> > being the wrong shades - I can have graded transparency that I can't have
> > with GIFs.
> >
> > I was wondering if anyone had any tips for this; I'm generating titles
> > with shadows for the tops of my pages. I have one particular problem
> > with this, and the only solution I've come up with is rather involved.
> > I'll describe my current situation:
> >
> > Anyone else had similar problems using graphics with alpha channels?
> > Any advice?
> >
> Have you tried the different filters in Compo?
>
> Have you used the 'Sharpen' filter to give you that sharpen the text
> outline?
This idea has come up twice in this thread; Darren mentioned using bleed
as well. Different filter used, same effect I think. I'll answer here.
That would work (I have a fully working alpha channel sprite at my
disposal) if it weren't for the shadow. I'm forced to attempt ASCII art
here, I'm afraid.
Here's an example letter P with shadow
####
##//##
#####//
##////
##/
//
If I sharpen the edge of the letter, I sharpen the edge of the shadow as
well. I lose the anti-aliasing on the interface between the letter and
its own shadow. The interface between the letter/shadow and background
will be fine, because the alpha-channel should cope with that.
On the matter of most implementations being poor for displaying PNGs,
I'm doing this for a test page on my site; I'll get all my regular
users to test it out on their systems before I even consider PNGing
the whole site. Because it's a test, that's half the point of being able
to change the background colour with no side effects as well; I'll
be getting them to vote on favourite background/foreground colours.
There's something of a differing of opinion going on, and the only
way to solve it is democratically!
If the next version of Compo could produce PNGs with the canvas colour
of 'None', that would be superb. Ther version I have here doesn't
support PNGs at all.
> Any chance of it being ready for the RISCOS'99 Show at the end of October?
> (in the UK)
Erm, a chance...I hope that Clares will be demonstrating it anyway. ;-)
> Regards, Dave C. - a Compo fan
Thanks!
> JNG, anyone? ;-)
>
> (alpha channel masked JPEGs)
Did you just make that up? ;-)
4 channel JPEGs are a right royal pain to try to access under RISC OS ATM.
Has anyone out there compiled a more recent version of Tom Lane's djpeg (ie
one that doesn't die when given an 'Adobe' rather than 'JFIF' marker)?
If you didn't just make that up (:-P) then I presume there's an even MORE
recent djpeg. Could somebody with a C compiler and the appropriate expertise
do us a favour? Please?
Simon.
--
------------------------------8<------------------------------
ne...@argonet.co.uk
JNG (JPEG Network Graphics) was developed about a year ago by the
PNG/MNG development group as a subformat of MNG (Multiple-image
network graphics) which is the animation format for PNG (Portable
Network Graphics). It manages transparency by storing a PNG-encoded
alpha channel along with a JPEG-encoded image that is stored in
PNG-style chunks.
See ftp://swrinde.nde.swri.edu/pub/mng/documents/
--
Glenn Randers-Pehrson
PNG/MNG Development Group
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
> > JNG, anyone? ;-)
> >
> > (alpha channel masked JPEGs)
> Did you just make that up? ;-)
> 4 channel JPEGs are a right royal pain to try to access under RISC OS
> ATM. Has anyone out there compiled a more recent version of Tom Lane's
> djpeg (ie one that doesn't die when given an 'Adobe' rather than 'JFIF'
> marker)?
I've got 6b here, which I believe is the latest. IIRC Adobe seem to use a
lot of markers - which one do you mean?
I haven't noticed it fall over on anything - send me a sample and I'll try
it.
Andy
--
fr...@argonet.co.uk - http://www.argonet.co.uk/homepages/fruit/
RiscCAD v8 now available.
See my site to subscribe to the RiscCAD mail-list.
> In article <9068a93849%rdav...@xtr788438.xtra.co.nz>, Rob Davison
> <rdav...@xtra.co.nz> wrote:
>
> > JNG, anyone? ;-)
> >
> > (alpha channel masked JPEGs)
>
> Did you just make that up? ;-)
No, its even been mentioned here (by Tom Lane).
You must have been doing something else at the time. ;-)
I gather that there is a serious proposal to add JPEG encoding to the
PNG specification. Been intending to go and look...<does that>
Right, the draft spec. for JNG and MNG (animation) can be found here:
http://www.cdrom.com/pub/mng/mngdocs.html
I like the idea but as you say, until the major browsers support a file
format properly its not really worth using.
Bit of a chicken-and-egg situation really. :-(
> If you didn't just make that up (:-P)
Would I do that to you? ;-)
But I was wrong, its (a proposed extension to) PNG and not JPEG.
[snip]
> That would work (I have a fully working alpha channel sprite at my
> disposal) if it weren't for the shadow.
[snip]
This is exactly the sort of thing I'm working on automating at the
moment.
Incidentally, Compos PNG creation uses Darrens Spr2PNG (thanks Darren!)
but the process of creating PNGs is much easier (than it is with
Compo at the moment) and it handles things like the opacity settings
etc. You can save any object, an area of the canvas or the entire canvas
as a masked alpha channel PNG.
> If the next version of Compo could produce PNGs with the canvas colour
> of 'None', that would be superb.
At the moment it uses the canvas background colour as the PNG 'Bgnd'
argument. I was advised that some implimentations of PNG do odd things
if you don't specify a background colour in the PNG file.
> Ther version I have here doesn't support PNGs at all.
I'm working on that (or at least, I should be...) ;-)
> I've got 6b here, which I believe is the latest.
How do you tell the version number from the djpeg binary? There doesn't seem
to be a version number in the -help text.
> IIRC Adobe seem to use a lot of markers - which one do you mean?
The App14 "Adobe" marker (actually contains those five ascii characters).
This marks the JFIF stream as containing a K channel in addition to the
normal YCC - it is used for CMYK JPEGs. If the file has one of these it does
NOT have an App0 "JFIF" marker - this is what upsets all the JPEG
decompressors I have.
> I haven't noticed it fall over on anything - send me a sample and I'll try
> it.
I would, but the CMYK JPEGs I have access to are all rather large!
> This is exactly the sort of thing I'm working on automating at the
> moment.
>
> Incidentally, Compos PNG creation uses Darrens Spr2PNG (thanks Darren!)
> but the process of creating PNGs is much easier (than it is with
> Compo at the moment) and it handles things like the opacity settings
> etc. You can save any object, an area of the canvas or the entire canvas
> as a masked alpha channel PNG.
I'm itching to get at some of these new features you keep mentioning in
these groups! That looks like a very useful improvement.
> > I've got 6b here, which I believe is the latest.
> How do you tell the version number from the djpeg binary? There doesn't
> seem to be a version number in the -help text.
Generally run the file with a -v flag, as in
djpeg -v
ISTR some versions of CFSI contain IJG files without version numbers,
although from recollection they were old versions.
> > IIRC Adobe seem to use a lot of markers - which one do you mean?
> The App14 "Adobe" marker (actually contains those five ascii
> characters). This marks the JFIF stream as containing a K channel in
> addition to the normal YCC - it is used for CMYK JPEGs. If the file has
> one of these it does NOT have an App0 "JFIF" marker - this is what
> upsets all the JPEG decompressors I have.
Erm... I found something like that earlier, but:-
APP0 contains:
JFIF\000\001\002\001\000\220\000\220\000\000
APP13 contains:
Photoshop 3.0\0008BIM\ and lots more snipped
APP14 contains:
Adobe\000d\200\000\000\000\001
JPEG image is 640w * 480h, 3 color components, 8 bits per sample
The last line would indicate it's not CMYK :-\
There's a note in the IJG libjpeg doc:-
[begin]
CAUTION: it appears that Adobe Photoshop writes inverted data in CMYK JPEG
files: 0 represents 100% ink coverage, rather than 0% ink as you'd expect.
This is arguably a bug in Photoshop, but if you need to work with Photoshop
CMYK files, you will have to deal with it in your application. We cannot
"fix" this in the library by inverting the data during the CMYK<=>YCCK
transform, because that would break other applications, notably
Ghostscript.
Photoshop versions prior to 3.0 write EPS files containing JPEG-encoded
CMYK
data in the same inverted-YCCK representation used in bare JPEG files, but
the surrounding PostScript code performs an inversion using the PS image
operator. I am told that Photoshop 3.0 will write uninverted YCCK in
EPS/JPEG files, and will omit the PS-level inversion. (But the data
polarity used in bare JPEG files will not change in 3.0.) In either case,
the JPEG library must not invert the data itself, or else Ghostscript would
read these EPS files incorrectly.
[end]
> > I haven't noticed it fall over on anything - send me a sample and I'll
> > try it.
> I would, but the CMYK JPEGs I have access to are all rather large!
I could send you the compiled binaries - mind you that's 280k archived
with docs.
Just noticed they're still on my website at
http://www.argonet.co.uk/homepages/fruit/software/ijg.zip
[snip]
> Incidentally, Compos PNG creation uses Darrens Spr2PNG (thanks Darren!)
Incidentally, Spr2Png will cause problems, eg. total lockup, if rendering a
Drawfile for which a font isn't available. I plan to look into this very
soon...
> [...] You can save any object, an area of the canvas or the entire canvas
> as a masked alpha channel PNG.
... provided that there's enough memory for Spr2Png to load it. Now, is it
worth setting the Virtualise bit for Spr2Png's work DA? :-)
> At the moment it uses the canvas background colour as the PNG 'Bgnd'
> argument. I was advised that some implementations of PNG do odd things if
> you don't specify a background colour in the PNG file.
General request for information: how do IE5 and newer versions of Navigator
(>4.05) render PNGs with alpha channels? Specifically, I'm interested in
finding out if these browsers:
* render onto a rectangle of the page background colour;
* render onto the page background (as Browse does); or
* treat the alpha channel as a simple mask (as Fresco does, AFAIK);
I'm *not* interested in finding that they
* render onto a rectangle of the colour specified in the bKGD chunk;
* completely ignore the alpha channel if there's no bKGD chunk.
since this is no different to that documented in the Spr2Png help text.
(The bKGD chunk specifies a preferred background colour, and is an optional
part of the PNG image format.)
Version numbers will help; I can then put these in the help text.
>> The version I have here doesn't support PNGs at all.
> I'm working on that (or at least, I should be...) ;-)
Well, get on with it ;-)
--
| Darren Salt | nr. Ashington, | Acorn | d youmustbejoking,demon,co,uk
| Risc PC, Spec+3, | Northumberland | Club | s zap,uk,eu,org
| A3010, BBC M128 | Toon Army | NE | @ retrospec,co,uk
| This space reserved for future expansion
I am Quark of Borg. Your gold-pressed latinum will be assimilated.
Or anywhere else, since there is no standard for 'em, and precious little
standard for CMYK data of any form...
> Has anyone out there compiled a more recent version of Tom Lane's djpeg (ie
> one that doesn't die when given an 'Adobe' rather than 'JFIF' marker)?
Say what? No version of djpeg has ever refused a file on the basis that
it has an Adobe marker or doesn't have a JFIF marker.
It's true that standard versions of djpeg will refuse CMYK JPEGs, but
that's just because they have no output format that handles CMYK data.
regards, tom lane
organizer, Independent JPEG Group
> Generally run the file with a -v flag, as in
> djpeg -v
Oh yes. Doh!
Seems I was using a version 4 when I had a 6a hanging around.
> > > IIRC Adobe seem to use a lot of markers - which one do you mean?
Having read the appropriate documentation ;-) I can now state the problem
more accurately:
I don't think djpeg copes with CMYK (or >3 components per pixel) of any
description, Adobe (type<>1) or otherwise.
If the Start Of Frame indicates 4 components per pixel, it seems impossible
to get djpeg to output any format.
WHY do we not have an output as sprite option in our build of djpeg? That
would at least allow us to access 4 channel JPEGs be they CMYK or RGBa
> Erm... I found something like that earlier, but:-
> APP0 contains:
> JFIF\000\001\002\001\000\220\000\220\000\000
> APP13 contains:
> Photoshop 3.0\0008BIM\ and lots more snipped
> APP14 contains:
> Adobe\000d\200\000\000\000\001
This indicates it should be an RGB image (the 1 at the end)
> JPEG image is 640w * 480h, 3 color components, 8 bits per sample
The SOF0 agrees that it is 3 components per pixel
> The last line would indicate it's not CMYK :-\
So it would seem, two to nothing!
> There's a note in the IJG libjpeg doc:-
> [snip]
Yup. There's a lovely bit in one of the sources too - somebody (probably Tom
Lane) referring to the guys at Adobe as "bozos" :-)
> I could send you the compiled binaries - mind you that's 280k archived
> with docs.
Thanks! I think the problem may be with our reliance on djpeg - a more
sophisticated implementation is required to access CMYK methinks.
> Nemo <ne...@argonet.co.uk> writes:
> > Has anyone out there compiled a more recent version of Tom Lane's djpeg
> > (ie one that doesn't die when given an 'Adobe' rather than 'JFIF'
> > marker)?
>
> Say what? No version of djpeg has ever refused a file on the basis that
> it has an Adobe marker or doesn't have a JFIF marker.
>
> It's true that standard versions of djpeg will refuse CMYK JPEGs, but
> that's just because they have no output format that handles CMYK data.
Yes, sorry. Having now actually READ your extensive documentation I can see
that the decompressor handles it with ease, and with very little
modification could go up to 10 components per pixel.
Nothing under RISC OS will touch a CMYK JPEG though.
> > 4 channel JPEGs are a right royal pain to try to access under RISC OS
> > ATM.
>
> Or anywhere else, since there is no standard for 'em, and precious little
> standard for CMYK data of any form...
There ARE standards for CMYK - TIFF is the obvious one (conspicuous in its
absence from cjpeg and djpeg) and even the humble (and crude) RISC OS sprite
can be CMYK.
It would be rather useful to support the (pitifully simple) sprite format in
cjpeg and djpeg, especially since we could then get at CMYK data. Had a
quick look at wrppm/c and rdppm/c - this would seem to be almost trivial.
Especially so if the only 'supported' sprite modes were 8bit greyscale,
32bit RGBa and 32bit CMYK.
> regards, tom lane
> organizer, Independent JPEG Group
Thanks Tom!
[snip]
> > > > IIRC Adobe seem to use a lot of markers - which one do you mean?
> Having read the appropriate documentation ;-) I can now state the problem
> more accurately:
> I don't think djpeg copes with CMYK (or >3 components per pixel) of any
> description, Adobe (type<>1) or otherwise.
> If the Start Of Frame indicates 4 components per pixel, it seems
> impossible to get djpeg to output any format.
I guess you've seen Tom's post by now.
> WHY do we not have an output as sprite option in our build of djpeg? That
> would at least allow us to access 4 channel JPEGs be they CMYK or RGBa
AIUI djpeg is an IJG utility to provide conversion to various standard
image formats - maybe if someone wrote the Sprite code it could be
incorporated :-)
Again AIUI, libjpeg does provide support for 4 (or more?) colours - it's
Adobe who got the CMYK bit wrong... the CAUTION note implies that it
should be possible to write an app that reverses this. (Hope I read that
right).
[snip]
> > I could send you the compiled binaries - mind you that's 280k archived
> > with docs.
> Thanks! I think the problem may be with our reliance on djpeg - a more
> sophisticated implementation is required to access CMYK methinks.
I guess you really need to be using libjpeg itself for this sort of thing
- I imagine many of the available JPEG utilities do this.
> Again AIUI, libjpeg does provide support for 4 (or more?) colours - it's
> Adobe who got the CMYK bit wrong... the CAUTION note implies that it
> should be possible to write an app that reverses this. (Hope I read that
> right).
On very old versions of PhotoShop - since (ISTR) 3.x its correct - I think
it is better to ignore the potential reversal, and sort it out afterwards
In article <ant31090...@ether228.acorn.co.uk>, A.Hodgkinson
<URL:mailto:ahod...@pacemicro.com> wrote:
> * Run tiff2png with -g 0.45455 to get correct gamma correction.
> Recommend -interlace too.
This'll be a little inefficient as the PNG won't be quantised, so
you could try the more complicated verson, as demonstrated by the
followng example:
tiff2png -verbose spe90deg,ff0 spe90deg.png
pngtopnm -verbose -rgba spe90deg.png > spe90deg.pnm
pnmtopng -verbose -interlace -background #ffffff -rgba -gamma 0.45455
-text copyright spe90deg.pnm > spe90deg2.png,b60
where 'copyright' is a text file containing a simple copyright
message, if you feel so inclined (best to keep it one line with no
line ending character at the end).
This also gives you the ability to specify the background colour,
which'll make pre-composited rendering in (e.g.) MSIE look a lot
better.
--
TTFN, Andrew (on behalf of myself, not my employer).
"Hold tight, lad, and think of Lancashire Hotpot!" - A Grand Day Out
> In article <493841DE2A%Iai...@rednova.demon.co.uk>, Iain Williamson
> <Iai...@rednova.demon.co.uk> wrote:
>
> > I've been trying to generate some PNGs... [snip intro]
> >
> > The problem is that the sprite output from Compo is already
> > anti-aliased [...]
>
> Yup, you have found the fascinating problem with alpha blending - a
> precalculated background colour.
That's 'cos you're all thinking about it backwards :-)
The transparent PNGs on the Acorn Internet site were done using
Photodesk, because of its ability to "paint" any colour with any
tool. The steps run something like this -
* Create an RGB image and solid-fill it with the colour that you
want your text to have
* Paint the text you want *using the mask*, not a colour (and paint
at the inverse of the final opacity you require; so a 100% *mask*
will translate into 100% *solid* because of the next step, or to
put it another way if you want 20% opacity on the text, paint the
mask with 80% opacity)
* Invert the mask
* Save as a TIFF
* Run tiff2png with -g 0.45455 to get correct gamma correction.
Recommend -interlace too.
--
> In message <na.4da79b49...@argonet.co.uk>
> Dave Cooper <d...@argonet.co.uk> wrote:
>
> > Any chance of it being ready for the RISCOS'99 Show at the end of October
> > (in the UK)
>
> Erm, a chance...I hope that Clares will be demonstrating it anyway. ;-)
I hope we will be demoing it when we go to the ARM club show in Birmingham in
early November. We won't be at Epsom. There's not much of a gap between the
two shows (well , about 150 miles or so if you want to be pedantic ( what's
the betting someone will now post the exact distance to the nearest inch)),
so it would be difficult to do both.
--
David Jackson. Technical Support Manager Clares Micro Supplies Ltd
75a Webbs Lane, Middlewich, Cheshire, UK, CW10 9DS
Tel: 01606 833999 Fax: 01606 836111
Web site http://www.claresmicro.com
> If you have a crap PNG handler (unlike Browse which has a world renowned
> perfect PNG implementation) your painstakingly created alpha mask will get
> treated as a binary one at some threshold, and your antialiasing DISAPPEARS
> - lovely pixelised solid text :-(
IMHO people who don't like this can live with it, get a proper browser, or
tell their browser vendor to implement PNGs properly.
If there are no PNGs on the web then why would MS or Netscape implement
proper PNG support?
Charlie
--
New RISC OS mp3 player: http://www.fish.zetnet.co.uk/
> In article <ant31090...@ether228.acorn.co.uk>, "A.Hodgkinson"
> <ahod...@pacemicro.com> wrote:
>
> > * Create an RGB image and solid-fill it with the colour that you
> > want your text to have
>
> Bingo. Problem. Right here.
>
> If you have a crap PNG handler (unlike Browse which has a world renowned
> perfect PNG implementation) your painstakingly created alpha mask will
> get treated as a binary one at some threshold, and your antialiasing
> DISAPPEARS - lovely pixelised solid text :-(
I think we have to live with pixelated text if we're going to use PNGs
- the alternative is what I've already got; the base image is anti-aliased
to the nominal background colour, and the alpha mask is applied on that.
Then, you get a hint of the background colour over the object.
>
> The same goes for transparencies, only worse (since they become solid or
> disappear completely).
>
> Unfortunately few PNG implementations are as good as Browse's (well done
> KB)
Browse is /very/ nice for PNGs.
I can do (what I think is) Andrew's recommendation on Compo really easily;
it'd defauly mechanism for creating text is to cut a mask out of a block
of colour (or a complex sprite in my case).
It all goes pear shaped when you want to put the shadow on; there's no way
you can still use the plain block of colour; it must include the shadow
as well, with the interface between letter and shadow antialiased, but
the border between shadow and background or letter and background not,
and then my head starts hurting.
Rob Davison has sent me some demo PNGs of Compo doing the whole thing
automagically, and they look very good.
Andrew, do these pngtopnm and pnmtopng conversion tools exist for RISCOS? I
tried looking but couldn't find anything...
Regards,
--
James Carey
London, England
> Andrew, do these pngtopnm and pnmtopng conversion tools exist for
> RISCOS? I tried looking but couldn't find anything...
Dunno if the NetPBM (IIRC) package port is up to date enough to have
them or not. The tools I referred to were Unix based as the command
line style implied. That means ARMLinux or RiscBSD should be able to
compile and run them, or find some friendly Unix host with them on.
There's surely something telnet-able set up for this, a bit like the
Internet Distiller perhaps... If not, somebody [1] might set one up
if pestered enough! Of course, you could always go mad and port them
to the OS directly.
As for links to the tools - see the 'Converters' section of:
http://www.cdrom.com/pub/png/pngcode.html
[1] Not me - you wouldn't be able to get past the firewall.
> In article <ant31090...@ether228.acorn.co.uk>, "A.Hodgkinson"
> <ahod...@pacemicro.com> wrote:
>
> > * Create an RGB image and solid-fill it with the colour that you
> > want your text to have
>
> Bingo. Problem. Right here.
>
> If you have a crap PNG handler (unlike Browse which has a world
> renowned perfect PNG implementation) your painstakingly created
> alpha mask will get treated as a binary one at some threshold, and
> your antialiasing DISAPPEARS - lovely pixelised solid text :-(
Could be worse. And the PNG handler *does* implement some degree of
blending, it'll work. Whereas if you take a simple binary mask with
best-guess anti-aliasing, you never give the renderer a chance to
do a good job. Garbage in, garbage out. Always use the highest
quality source you can.
> Unfortunately few PNG implementations are as good as Browse's (well
> done KB)
Indeed, but Navigator and MSIE are both doing reasonable jobs in
their current implementations and most of the time people are
considering generating PNGs, they're considering it for a web site.
Even ArcWeb's latest incarnation does an OK job. Dunno about
Webster XL or the *latest* Fresco, though the last Fresco I saw
was bizarrely broken when handling transparency (I think it had
a binary cutoff point at some %age of opacity, which is hopeless).
> > * Run tiff2png with -g 0.45455 to get correct gamma correction.
>
> ... if you don't have a calibrated monitor!
At creation time, yes. Assuming this is so, having created the PNG,
this is unequivocally correct, provided your renderer is aware of
system gamma (RISC OS of course has no 'official' system for this,
so most people will not have a calibrated monitor for creation *or*
display, hence assumption of 2.2).
> > ... if you don't have a calibrated monitor!
>
> At creation time, yes. Assuming this is so, having created the PNG,
> this is unequivocally correct, provided your renderer is aware of
> system gamma (RISC OS of course has no 'official' system for this,
Erm, it does now.
There's been a bit of argy bargy about the module /name/ but the SWI is
allocated - &53284 Read Gamma - on exit R0=documented gamma in 16.16 format.
If this call fails due to lack of module, assume 2.2 as normal.
> > Unfortunately few PNG implementations are as good as Browse's (well
> > done KB)
> Indeed, but Navigator and MSIE are both doing reasonable jobs in
> their current implementations and most of the time people are
> considering generating PNGs, they're considering it for a web site.
> Even ArcWeb's latest incarnation does an OK job. Dunno about
> Webster XL or the *latest* Fresco, though the last Fresco I saw
> was bizarrely broken when handling transparency (I think it had
> a binary cutoff point at some %age of opacity, which is hopeless).
Fresco is still lousy for PNGs. Mask still forced to 1-bit, so you get
jagged edges and no grading in transparency.
WXL is fair, but certainly not as good as Browse (or TechWriter). It can
easy get confused and give you a tinted background where the mask should
be transparent. This depends upon the format of the PNG, I think.
These problems are why I still tend to use GIFs and use Compo/ChangeFSI to
anti-alias and grade the edges towards the expected page background colour
before the mask kicks in. The results aren't as good a correctly created
and rendered PNG, but they tend look better on browsers that aren't really
up to PNGs yet. :-/
Hope things improve soon... Then we'll have to go for JNGs, as Rob said.
These should be much more compact for used as 'photos' with graded
transparency...
Slainte,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
MMWaves http://www.st-and.ac.uk/~www_pa/Scots_Guide/MMWave/Index.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html
TechWriter http://www.st-and.demon.co.uk/TechWrite/Tips1.html
Dutton CDs http://www.duttonlabs.demon.co.uk/index.html
Is there any chance someone could stick some examples of this problem
with transparent text, or other transparancy effects, so we can compare
the behaviour of different browsers.
Cheers
---Dave
> I've been trying to generate some PNGs for my fledgling web site; mainly
> so I can change the background colour without the shadows of my graphics
> being the wrong shades - I can have graded transparency that I can't have
> with GIFs.
> I was wondering if anyone had any tips for this; I'm generating titles
> with shadows for the tops of my pages. I have one particular problem
> with this, and the only solution I've come up with is rather involved.
> I'll describe my current situation:
> Anyone else had similar problems using graphics with alpha channels?
> Any advice?
The thread seems to have gone away from your original posting. I am not
sure whether anyone has actually answered it but, in essence, it can be
done with Photodesk (as we all know PhotoDesk can do anything PhotoShop
can, so, if the 'Browse' PNG was done in P'Shop then it can be done on
P'Desk too).
I note you use Compo, a programme I don't know so I am unsure whether
you can do it using said programme.
Two points though:-
1/ Don't use Sprites as the mask does not allow graduations. Use Tiffs.
2/ Fill masks, graduated or otherwise, to get your text rather than
creating the text and then masking around it. This largely avoids
defining the anti-aliasing prior to creating the Alpha channel.
If you can have more than one Alpha channel associated with a single
image in Compo then the job becomes easier with solid or blended shadows
too.
Tiff2PNG will convert the final image.
Only Browse will render the final PNG's properly though. IE 5 has
problems as does Netscape 4, Fresco we know about... who is going to see
your page as you intend it?
--
tony cropper bristol uk
Email: to...@cropp.demon.co.uk
Web: http://www.cropp.demon.co.uk/
> There ARE standards for CMYK - TIFF is the obvious one (conspicuous in its
> absence from cjpeg and djpeg) and even the humble (and crude) RISC OS sprite
> can be CMYK.
Indeed, TIFF I/O for cjpeg/djpeg has been on the to-do list since forever.
It never quite got to the top of the list though.
> It would be rather useful to support the (pitifully simple) sprite format in
> cjpeg and djpeg, especially since we could then get at CMYK data. Had a
> quick look at wrppm/c and rdppm/c - this would seem to be almost trivial.
> Especially so if the only 'supported' sprite modes were 8bit greyscale,
> 32bit RGBa and 32bit CMYK.
I'd be pleased to consider a submission. Not sure if code for a platform-
specific format ought to go into the general IJG release, but in any case
it could be made available as an add-on...
No sooner said than done.
http://www.geocities.com/SiliconValley/7320/pngt2.htm
...is a five minute effort containing four shadowed PNGs.
Best viewed in Browse (naturally).
Users interested in playing might like to grab the source PNGs and the
html and muck around with different background colours (or tiles).
The routine for producing them is very alpha at the moment - but it
already does a reasonable job I think.
> http://www.geocities.com/SiliconValley/7320/pngt2.htm
Oooh, loverly...Fresco 1.72 scrambles the PNGs, type fives and then dies
when given this page.
Yum. ;-)
> In message <ant011740bc86#x...@druck.freeuk.com>
> "David J. Ruck" <ne...@druck.freeuk.com> wrote:
[PNG implementations on Browsers]
>> Is there any chance someone could stick some examples of this problem with
>> transparent text, or other transparancy effects, so we can compare the
>> behaviour of different browsers.
> No sooner said than done.
> http://www.geocities.com/SiliconValley/7320/pngt2.htm ...
> is a five minute effort containing four shadowed PNGs.
And <URL:http://www.youmustbejoking.demon.co.uk/pngtest/> is a slightly more
comprehensive test with 20 PNGs all showing the word "Test" with simple or
alpha channel masks and/or background colours.
Example screenshots from the three browsers which I have here are also
present. (I had to cheat a little with Fresco 1.78F since it crashed while
/automatically/ loading the images.)
> Best viewed in Browse (naturally).
Of course :-)
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk | Acorn
| Risc PC, Spec+3, | Northumberland | s zap,uk,eu,org ** anti-UBE | Club
| A3010, BBC M128 | Toon Army | @ retrospec,co,uk | NE
| JSW. Bug. CTetris. Mindtrap. KPatience. SnakePit.
Sooner or later, the worst possible set of circumstances is bound to occur.
> Spr2Png will cause problems, eg. total lockup, if rendering a Drawfile for
> which a font isn't available. I plan to look into this very soon...
The problem turns out to be an interaction caused by Taskwindow not knowing
about output redirection to a sprite; the solution is to remove Taskwindow's
claim on WrchV while output is redirected then restore it (at the same
position in the WrchV claimants chain) afterwards.
Spr2Png 0.10 has this fix, and will warn you when you try to render a Draw
file which uses any fonts which are not currently available.
--
| Darren Salt | d youmustbejoking,demon,co,uk | Acorn | nr. Ashington,
| Risc PC, Spec+3, | s zap,uk,eu,org ** anti-UBE | Club | Northumberland
| A3010, BBC M128 | @ retrospec,co,uk | NE | Toon Army
| <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6.3 key here)
Some people fall for everything and stand for nothing.