[vwnc] Cairo on Bitonal Images?
Locked
[vwnc] Cairo on Bitonal Images?
 
|
We are trying to
avoid the step of converting our bitonal images to/from 32-bit for Cairo
drawing, but something appears to be different in VisualWorks bits
arrangment compared to what Cairo is expecting for A1-format images as seen in
the attached comparison images. The colors also seem to be reversed. If anyone
has any suggestions for how this could be corrected (or even a working
implementation of #becomeCairoCompatible for Depth1Image) that would be greatly
appreciated.
(Image extent: 100 @ 100 depth: 1 palette:
MappedPalette
whiteBlack)
useFixedSpaceBits; newCairoContextWhile: [:cr | cr source: ColorValue black; moveTo: 10 @ 10; lineTo: 90 @ 90; stroke. cr surface writeToPng: 'cairo.png']
|
-Boris _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
vw.png (1K)
Re: [vwnc] Cairo on Bitonal Images?
|
|
Some progress to report - Joerg was sharp enough
to notice that it was simply drawing on the bits in reverse order and, sure
enough, reversing bytes post-processing appears to produce the correct image,
any suggestions for a more elegant solution? :)
(Image extent: 100 @ 100 depth: 1 palette:
MappedPalette
whiteBlack)
useFixedSpaceBits; newCairoContextWhile: [:cr | cr source: ColorValue black; moveTo: 10 @ 10; lineTo: 90 @ 90; stroke]; reverseBytes SmallInteger>>reversed
| map | map := #(16r00 16r80 16r40 16rc0 16r20 16ra0 16r60 16re0 16r10 16r90 16r50 16rd0 16r30 16rb0 16r70 16rf0 16r08 16r88 16r48 16rc8 16r28 16ra8 16r68 16re8 16r18 16r98 16r58 16rd8 16r38 16rb8 16r78 16rf8 16r04 16r84 16r44 16rc4 16r24 16ra4 16r64 16re4 16r14 16r94 16r54 16rd4 16r34 16rb4 16r74 16rf4 16r0c 16r8c 16r4c 16rcc 16r2c 16rac 16r6c 16rec 16r1c 16r9c 16r5c 16rdc 16r3c 16rbc 16r7c 16rfc 16r02 16r82 16r42 16rc2 16r22 16ra2 16r62 16re2 16r12 16r92 16r52 16rd2 16r32 16rb2 16r72 16rf2 16r0a 16r8a 16r4a 16rca 16r2a 16raa 16r6a 16rea 16r1a 16r9a 16r5a 16rda 16r3a 16rba 16r7a 16rfa 16r06 16r86 16r46 16rc6 16r26 16ra6 16r66 16re6 16r16 16r96 16r56 16rd6 16r36 16rb6 16r76 16rf6 16r0e 16r8e 16r4e 16rce 16r2e 16rae 16r6e 16ree 16r1e 16r9e 16r5e 16rde 16r3e 16rbe 16r7e 16rfe 16r01 16r81 16r41 16rc1 16r21 16ra1 16r61 16re1 16r11 16r91 16r51 16rd1 16r31 16rb1 16r71 16rf1 16r09 16r89 16r49 16rc9 16r29 16ra9 16r69 16re9 16r19 16r99 16r59 16rd9 16r39 16rb9 16r79 16rf9 16r05 16r85 16r45 16rc5 16r25 16ra5 16r65 16re5 16r15 16r95 16r55 16rd5 16r35 16rb5 16r75 16rf5 16r0d 16r8d 16r4d 16rcd 16r2d 16rad 16r6d 16red 16r1d 16r9d 16r5d 16rdd 16r3d 16rbd 16r7d 16rfd 16r03 16r83 16r43 16rc3 16r23 16ra3 16r63 16re3 16r13 16r93 16r53 16rd3 16r33 16rb3 16r73 16rf3 16r0b 16r8b 16r4b 16rcb 16r2b 16rab 16r6b 16reb 16r1b 16r9b 16r5b 16rdb 16r3b 16rbb 16r7b 16rfb 16r07 16r87 16r47 16rc7 16r27 16ra7 16r67 16re7 16r17 16r97 16r57 16rd7 16r37 16rb7 16r77 16rf7 16r0f 16r8f 16r4f 16rcf 16r2f 16raf 16r6f 16ref 16r1f 16r9f 16r5f 16rdf 16r3f 16rbf 16r7f 16rff). ^map at: self + 1. ByteArray>>reverseBytes
self doWithIndex: [:ea :i | self at: i put: ea reversed]. Depth1Image>>reverseBytes self bitsInstVar reverseBytes. From: [hidden email] [mailto:[hidden email]] On Behalf Of Boris Popov Sent: Tuesday, May 19, 2009 11:39 AM To: VWNC Subject: [vwnc] Cairo on Bitonal Images? We are trying to
avoid the step of converting our bitonal images to/from 32-bit for Cairo
drawing, but something appears to be different in VisualWorks bits
arrangment compared to what Cairo is expecting for A1-format images as seen in
the attached comparison images. The colors also seem to be reversed. If anyone
has any suggestions for how this could be corrected (or even a working
implementation of #becomeCairoCompatible for Depth1Image) that would be greatly
appreciated.
(Image extent: 100 @ 100 depth: 1 palette:
MappedPalette
whiteBlack)
useFixedSpaceBits; newCairoContextWhile: [:cr | cr source: ColorValue black; moveTo: 10 @ 10; lineTo: 90 @ 90; stroke. cr surface writeToPng: 'cairo.png']
|
-Boris _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
From the PNGs I think the problem is akin to endianness, but within
a single byte: as we go down, the dot moves right on Cairo and left on VW. Given
there are about 10 segments for an 80@80 line, it looks like we have a cycle
every 8 bits, i.e. the order of bits within a byte is reversed. This fits with
the description of CAIRO_FORMAT_A1 below. Try replacing each byte with its bit mirror. You’ll only
need to do this on platforms whose endianness doesn’t match VW’s. This
shows the idea – compare im with im2. Obviously the last line could be
much faster, e.g. with a lookup table. p := Pixmap extent: 100 @ 100. gc := p graphicsContext. gc paint: ColorValue black; displayLineFrom: 10 @ 10 to: 90 @ 90. im := p asImage. im2 := im convertToPalette: MappedPalette whiteBlack. bits := im2 bitsInstVar. bits keysAndValuesDo: [:ix :v | bits
at: ix put: ('2r', (bits at: ix) paddedBinaryPrintString reverse) asNumber]. The other problem is the palette. Either use blackWhite, or more
likely switch to a CoveragePalette (since this is alpha). HTH, Steve From:
[hidden email] [mailto:[hidden email]] On Behalf Of Boris
Popov We
are trying to avoid the step of converting our bitonal images to/from 32-bit
for Cairo drawing, but something appears to be different in VisualWorks
bits arrangment compared to what Cairo is expecting for A1-format images as
seen in the attached comparison images. The colors also seem to be reversed. If
anyone has any suggestions for how this could be corrected (or even a working
implementation of #becomeCairoCompatible for Depth1Image) that would be greatly
appreciated. (Image
extent: 100 @ 100 depth: 1 palette: MappedPalette whiteBlack)
-Boris _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
The Cairo code
to reverse a byte translates to the following Smalltalk: ((b * 16r0802 bitAnd: 16r22110) bitOr: (b * 16r8020 bitAnd: 16r88440))
* 16r10101 >> 16 bitAnd: 16rff I’m amazed to find this is only 3 times faster than my
hack with Trippy’s print string: ('2r', b paddedBinaryPrintString reverse) asNumber The lookup table is predictably about 100 times faster. Steve From:
[hidden email] [mailto:[hidden email]] On Behalf Of Boris
Popov Some progress to report - Joerg was sharp enough to notice
that it was simply drawing on the bits in reverse order and, sure enough,
reversing bytes post-processing appears to produce the correct image, any
suggestions for a more elegant solution? :) (Image extent: 100 @ 100 depth: 1 palette: MappedPalette whiteBlack) SmallInteger>>reversed ByteArray>>reverseBytes Depth1Image>>reverseBytes From: [hidden email]
[mailto:[hidden email]] On Behalf Of Boris Popov We
are trying to avoid the step of converting our bitonal images to/from 32-bit
for Cairo drawing, but something appears to be different in VisualWorks
bits arrangment compared to what Cairo is expecting for A1-format images as
seen in the attached comparison images. The colors also seem to be reversed. If
anyone has any suggestions for how this could be corrected (or even a working
implementation of #becomeCairoCompatible for Depth1Image) that would be greatly
appreciated. (Image
extent: 100 @ 100 depth: 1 palette: MappedPalette whiteBlack)
-Boris _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
Yea, we ended up with a lookup table as per my previous
message. Also, we had to reverse bytes before feeding the image to
Cairo and reverse them back once it's done its thing. Is there a test
suite somewhere for CairoGraphics? I might take a stab at integrating our hack
later on, but I wouldn't want to do that w/o some notion of formal tests to
prove that it works :)
-Boris From: [hidden email] [mailto:[hidden email]] On Behalf Of Steven Kelly Sent: Tuesday, May 19, 2009 2:22 PM To: VWNC Subject: Re: [vwnc] Cairo on Bitonal Images? The
Cairo code
to reverse a byte translates to the following Smalltalk: ((b
* 16r0802 bitAnd: 16r22110) bitOr: (b * 16r8020 bitAnd: 16r88440)) * 16r10101
>> 16 bitAnd: 16rff I’m
amazed to find this is only 3 times faster than my hack with Trippy’s print
string: ('2r',
b paddedBinaryPrintString reverse) asNumber The
lookup table is predictably about 100 times faster. Steve From:
[hidden email] [mailto:[hidden email]] On Behalf Of
Boris Popov Some
progress to report - Joerg was sharp enough to notice that it was simply
drawing on the bits in reverse order and, sure enough, reversing bytes
post-processing appears to produce the correct image, any suggestions for a more
elegant solution? :) (Image
extent: 100 @ 100 depth: 1 palette: MappedPalette
whiteBlack) SmallInteger>>reversed ByteArray>>reverseBytes Depth1Image>>reverseBytes From:
[hidden email] [mailto:[hidden email]] On Behalf Of
Boris Popov We are trying to
avoid the step of converting our bitonal images to/from 32-bit for Cairo
drawing, but something appears to be different in VisualWorks bits
arrangment compared to what Cairo is expecting for A1-format images as seen in
the attached comparison images. The colors also seem to be reversed. If anyone
has any suggestions for how this could be corrected (or even a working
implementation of #becomeCairoCompatible for Depth1Image) that would be greatly
appreciated. (Image extent: 100 @
100 depth: 1 palette: MappedPalette
whiteBlack)
-Boris _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
On May 19, 2009, at 2:33 PM, Boris Popov wrote: > Yea, we ended up with a lookup table as per my previous message. > Also, we had to reverse bytes before feeding the image to Cairo and > reverse them back once it's done its thing. Is there a test suite > somewhere for CairoGraphics? I might take a stab at integrating our > hack later on, but I wouldn't want to do that w/o some notion of > formal tests to prove that it works :) > > -Boris To date... we've been following the Benevolent Dictator with Trusted Lieutenants model for Cairo publishing/maintenance. You publish on a branch, I'll see what I can't do to review/integrate it onto the trunk. Please. :) Some times, I tell people to go ahead and publish to the trunk, when we've quasi-paired the code. I've not put together a test suite. In the beginning, because so much of it had to do with native graphics (instead of Smalltalk retained memory), so there was less state to test. Any reason you don't do this on a Mask? Conversion costs maybe? And the fact that that too requires changes/work to make it work. :) -- Travis Griggs Objologist "Only one thing is impossible for God: to find any sense in any copyright law on the planet." - Mark Twain _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
Travis,
Oh, sure, I wouldn't touch the main line with kinds of code that resulted from our little adventure :) We aren't dealing with masks here, but rather with black-and-white documents that are ultimately stored in tiff bytes. For certain scenarios we need to endorse information onto these images and, thus, being able to just call bitonal becomeCairoCompatible; newCairoContextWhile: [:cr | ... ] would be quite handy, because even with our hacks in place we still need to do a bit of trial-and-error to determine when to reverse bytes and when to invert palettes to arrive at a desired result ;) -Boris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs Sent: Tuesday, May 19, 2009 3:33 PM To: VWNC Subject: Re: [vwnc] Cairo on Bitonal Images? On May 19, 2009, at 2:33 PM, Boris Popov wrote: > Yea, we ended up with a lookup table as per my previous message. > Also, we had to reverse bytes before feeding the image to Cairo and > reverse them back once it's done its thing. Is there a test suite > somewhere for CairoGraphics? I might take a stab at integrating our > hack later on, but I wouldn't want to do that w/o some notion of > formal tests to prove that it works :) > > -Boris To date... we've been following the Benevolent Dictator with Trusted Lieutenants model for Cairo publishing/maintenance. You publish on a branch, I'll see what I can't do to review/integrate it onto the trunk. Please. :) Some times, I tell people to go ahead and publish to the trunk, when we've quasi-paired the code. I've not put together a test suite. In the beginning, because so much of it had to do with native graphics (instead of Smalltalk retained memory), so there was less state to test. Any reason you don't do this on a Mask? Conversion costs maybe? And the fact that that too requires changes/work to make it work. :) -- Travis Griggs Objologist "Only one thing is impossible for God: to find any sense in any copyright law on the planet." - Mark Twain _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
On May 19, 2009, at 3:44 PM, Boris Popov wrote: > Travis, > > Oh, sure, I wouldn't touch the main line with kinds of code that > resulted from our little adventure :) > > We aren't dealing with masks here, but rather with black-and-white > documents that are ultimately stored in tiff bytes. For certain > scenarios we need to endorse information onto these images and, thus, > being able to just call > > bitonal > becomeCairoCompatible; > newCairoContextWhile: [:cr | ... ] > > would be quite handy, because even with our hacks in place we still > need > to do a bit of trial-and-error to determine when to reverse bytes and > when to invert palettes to arrive at a desired result ;) What do you do with it as a Smalltalk Image? Is that just an intermediate format? Converted from the tiff representation? IOW, is the Smalltalk Image object just a transfer format between two separate libraries? -- Travis Griggs Objologist "You A students, you'll be back soon teaching here with me. You B students, you'll actually go on to be real engineers. You C students, you'll go into management and tell the A and B students what to do." - My Fluid Dynamics Professor whom I have yet to disprove _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
Yea, most of the time the generic pattern is,
- get smalltalk image from tiff bytes (libtiff) - endorse it (with text and/or other images) - using graphics context (old and busted) - using cairo (new hotness) - get tiff bytes from endorsed smalltalk image (libtiff) There might be other steps in between, but nothing significant enough. -Boris -----Original Message----- From: Travis Griggs [mailto:[hidden email]] Sent: Tuesday, May 19, 2009 4:03 PM To: Boris Popov Cc: VWNC Subject: Re: [vwnc] Cairo on Bitonal Images? On May 19, 2009, at 3:44 PM, Boris Popov wrote: > Travis, > > Oh, sure, I wouldn't touch the main line with kinds of code that > resulted from our little adventure :) > > We aren't dealing with masks here, but rather with black-and-white > documents that are ultimately stored in tiff bytes. For certain > scenarios we need to endorse information onto these images and, thus, > being able to just call > > bitonal > becomeCairoCompatible; > newCairoContextWhile: [:cr | ... ] > > would be quite handy, because even with our hacks in place we still > need > to do a bit of trial-and-error to determine when to reverse bytes and > when to invert palettes to arrive at a desired result ;) What do you do with it as a Smalltalk Image? Is that just an intermediate format? Converted from the tiff representation? IOW, is the Smalltalk Image object just a transfer format between two separate libraries? -- Travis Griggs Objologist "You A students, you'll be back soon teaching here with me. You B students, you'll actually go on to be real engineers. You C students, you'll go into management and tell the A and B students what to do." - My Fluid Dynamics Professor whom I have yet to disprove _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Cairo on Bitonal Images?
|
|
An alternative to integrating explicit support for depth1 images is to
reduce the cost of palette conversation. Certainly going from depth1 -> to cairoRGB24 could be nothing more than looking up each depth 1 byte in a table for the sequence of bytes making up the corresponding RGB24 pixels. Going the other way RGB24 -> depth1 is more involved. I don't know if the general case could be optimized but the case where there is only Alpha channel information could be done in two steps; threshold the image to B/W and then use a lookup table to revert to depth1. This should be a LOT faster than the current palette conversion mechanism which seem to be very heavy on large integer math. At least every time I broke into it that is what the system was doing. Joerg -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Boris Popov Sent: Tuesday, May 19, 2009 4:15 PM To: Travis Griggs Cc: VWNC Subject: Re: [vwnc] Cairo on Bitonal Images? Yea, most of the time the generic pattern is, - get smalltalk image from tiff bytes (libtiff) - endorse it (with text and/or other images) - using graphics context (old and busted) - using cairo (new hotness) - get tiff bytes from endorsed smalltalk image (libtiff) There might be other steps in between, but nothing significant enough. -Boris -----Original Message----- From: Travis Griggs [mailto:[hidden email]] Sent: Tuesday, May 19, 2009 4:03 PM To: Boris Popov Cc: VWNC Subject: Re: [vwnc] Cairo on Bitonal Images? On May 19, 2009, at 3:44 PM, Boris Popov wrote: > Travis, > > Oh, sure, I wouldn't touch the main line with kinds of code that > resulted from our little adventure :) > > We aren't dealing with masks here, but rather with black-and-white > documents that are ultimately stored in tiff bytes. For certain > scenarios we need to endorse information onto these images and, thus, > being able to just call > > bitonal > becomeCairoCompatible; > newCairoContextWhile: [:cr | ... ] > > would be quite handy, because even with our hacks in place we still > need > to do a bit of trial-and-error to determine when to reverse bytes and > when to invert palettes to arrive at a desired result ;) What do you do with it as a Smalltalk Image? Is that just an intermediate format? Converted from the tiff representation? IOW, is the Smalltalk Image object just a transfer format between two separate libraries? -- Travis Griggs Objologist "You A students, you'll be back soon teaching here with me. You B students, you'll actually go on to be real engineers. You C students, you'll go into management and tell the A and B students what to do." - My Fluid Dynamics Professor whom I have yet to disprove _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |