Compose.jl icon indicating copy to clipboard operation
Compose.jl copied to clipboard

image/bitmap implementation

Open lobingera opened this issue 8 years ago • 10 comments

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.

lobingera avatar Aug 28 '15 15:08 lobingera

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

snapshot2

lobingera avatar Aug 28 '15 15:08 lobingera

You have a working prototype of this? Is it worth making a PR?

dcjones avatar Aug 28 '15 16:08 dcjones

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 [email protected] 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.

lobingera avatar Aug 28 '15 16:08 lobingera

I wouldn't like to add Images.jl (for conversion) as a dependency.

lobingera avatar Aug 28 '15 16:08 lobingera

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.

dcjones avatar Aug 28 '15 16:08 dcjones

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.

timholy avatar Aug 28 '15 16:08 timholy

@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?

lobingera avatar Aug 28 '15 16:08 lobingera

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.

dcjones avatar Aug 28 '15 16:08 dcjones

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)?

lobingera avatar Aug 28 '15 17:08 lobingera

Yeah, I think that's the right idea.

dcjones avatar Aug 28 '15 17:08 dcjones