Open lobingera opened 9 years ago
prototype:
function do_imag2_png()
output = Compose.PNG("temp.png",400px,300px);
m = rand(Uint32,4,8);
r = Compose.image(m,0.0,0.0,1.0,0.5)
c = compose(compose(context(), r))
draw(output,c);
c
end
You have a working prototype of this? Is it worth making a PR?
Well, it does the job. Maybe we have to discuss the interface and if it makes sense to split into bitmap AND image. For your SVG implementation, something like bitmap makes sense. bitmap will take a literal string to a PNG/JPEG/SVG string and puts it into a svg. For cairo-based backends, image transforms a (simple) Uint32 - so a RGB without alpha and puts it into the context.
For cases of bitmap into cairo-backends a converter from literal string into Uint32 is needed. For cases of image into SVG a converter of Uint32 into - maybe simple - png is needed.
On Fri, Aug 28, 2015 at 6:06 PM, Daniel C. Jones notifications@github.com wrote:
You have a working prototype of this? Is it worth making a PR?
— Reply to this email directly or view it on GitHub https://github.com/dcjones/Compose.jl/issues/140#issuecomment-135817387.
I wouldn't like to add Images.jl (for conversion) as a dependency.
Ok, I see. We could use cairo to convert the raw pixel data in image into png for use in SVG to avoid the Images.jl dependency.
If we keep both image
and bitmap
, for raw pixel data and encoded image data respectively, we may want to swap the names. It seems a little misleading otherwise.
Much as I like Images.jl :smile:, I understand the reasons to avoid dependency (esp. all those ambiguity warnings...).
On a little-endian machine, reinterpret(BGRA{U8}, buffer, size)
(where buffer::Array{UInt32}
) will give you something more manipulable in the julia world. It does imply there is meaningful transparency; we might want to define a BGR4
type in ColorTypes.jl.
@dcjones We could use cairo to convert the raw pixel data in image into png for use in SVG Are you sure cairo supports this?
Are you sure cairo supports this?
I think there are two ways to do this if cairo is installed: (1) Set up a cairo surface with the bitmap data, draw it, and call Cairo.write_to_png
, (2) Call into libpng directly. Cairo links against libpng, so if cairo is installed it should be safe to assume libpng is as well.
OK, i take a look. But i understand: bitmap shall be a Uint32 rendering to anything. image shall be a literal image string rendering to anything (accepting mime/png AND mime/jpeg AND mime/svg for SVG, mime/png for cairo backends only)?
Yeah, I think that's the right idea.
To add something like a bitmap or image to a compose context the implementation of a image primitive is needed. There is a bitmap available, but only correctly implemented for the SVG backend. For cairo type backends (PDF, PNG, etc.) bitmap is missing.