|
karlgoethebier has asked for the wisdom of the Perl Monks concerning the following question:
Hi all,
It seems like installing GD is a pain on a Mac.
Anyway, $image->gd seems to work.
"This returns the image data in GD format."
But what format is this?
ImageMagick doesn't know it:
karls-mac-mini:monks karl$ identify image.gd
identify: no decode delegate for this image format `image.gd'.
Is it perhaps possible to convert this format to png or jpg with another tool - as a quick workaround until i figured out to install GD properly?
Thank you very much for any hint and best regards, Karl
«The Crux of the Biscuit is the Apostrophe»
|
Re: About GD Image Data Output Methods
by BrowserUk (Patriarch) on Jun 07, 2015 at 12:11 UTC
|
->gd is libgd's own internal format. It is unlikely to be recognised by any other graphics libraries or image converters.
It is a very simple format that consists of a 11 byte header (for truecolor) and the X-width * 4 * Y-height bytes of uncompressed image data.
A simple 10x10 (truecolor) image with a diagonal line of colored pixels constructed like this:
$i = GD::Image->new( 10, 10, 1 );;
$i->setPixel( $_, $_, $_ ) for 0 .. 9;;
And then output as ->gd and unpacked as bytes : $x = $i->gd;;
print unpack 'C*', $x;;
looks like this (manully formatted): 255 254 ## (A sig of sorts) Low bit of second byte means tr
+ue color
0 10 ## Width in pixels
0 10 ## height in pixels
1 ## Indicates no color table (Ie. a non-palette imag
+e)
255 255 255 255 ## Seems to be a trailer block
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ## X x Y x 4 bytes
+(U32s) of rgba pixel data
0000 0001 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0002 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0003 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0004 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0005 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0006 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0007 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0008 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0009
It should not be hard to knock up Perl script that converts that to one of the ASCII image formats prevalent on *nix, and then convert that to png.
Note:Palleted images have two extra bytes in the header (not sure about the purpose); a 256 * 4-byte color table following the trailer block; and then width * 1-byte * height image data, where each byte value is an index into the color table.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply]
[d/l]
[select] |
Re: About GD Image Data Output Methods
by ww (Archbishop) on Jun 07, 2015 at 11:14 UTC
|
Warning: all these deal with creation of images using GD and NOT with converting native GD images.... about which neither of two search engines produced any high-ranked references. But the GD site(s) note the emphasis on GD's native ability to output GIF, JPG, PNG, etc.
Google's first suggestion references a PHP-oriented GD manual which says "When using GD, please make sure of the following things: 1. The file that is used to manipulate images is saved as ANSI format and not UTF-8." What's you input?
Slighly more usefully, maybe, the author's site, http://www.boutell.com/gd/, offers "http://www.boutell.com/gd/" and, perhaps more importantly, the observation:
"If you're compiling stuff, you're doin' it wrong. See the gd FAQ for more information and please stop compiling things from source code if you don't need to."
Template-GD in CPAN also has some interesting and perhaps relevant comments.
If your real goal is production, rather than using GD, several documents cite an executable (for ??OS) called FLY as an alternative.
| [reply]
[d/l] |
|
|
"If you're compiling stuff, you're doin' it wrong..."
Holy moly! These guys have a strange kind of humor.
I installed GD on Linux several times some time ago.
The prerequisites are zlib, libjpeg, libpng, freetype2 and libgd, as i remember.
In many cases the debs or rpms provided by SuSE/Novell or Debian didn't work so I needed to compile the libs myself. This never worked without some less or more annoying complications.
OK, Debian comes (or came) with a GD package but with perlbrew this is a different thing.
On the Mac there is no such package management tool like apt or rpm.
I could install Homebrew but i really don't want do do this.
This continues ad nauseam.
For example someone jumped to the conclusion to pack libpng with xz.
The version of tar that comes with OS X doesn't unpack these files. So i need another version of tar (which i must compile) or another unpacker (which i must compile too or buy) - or perhaps i must rely on a "free" binary from some dubious source.
I skip the rest that goes or could go wrong.
In the worst case i end up with a box cluttered with not working stuff that i need to remove by hand.
So i'll continue with RTFM. Some of the links you provided i have already read, some not.
Thank you very much and best regards, Karl
Edit: Minor changes of wording.
P.S.: Or i try what BrowserUK suggested below. Please see ibidem about the background of my question.
«The Crux of the Biscuit is the Apostrophe»
| [reply] |
Re: About GD Image Data Output Methods
by BrowserUk (Patriarch) on Jun 07, 2015 at 17:48 UTC
|
Karl, try using this to convert the internal gd format to a Windows .BMP format. After that, any of your image converters should be able to port it to whatever format you require.
# ... $image is your GD::Image for output
my $gd = $image->gd;
my @attrs = unpack 'nnnCV', substr( $gd, 0, 11, '' );
my $len = length( $gd ) / 4 * 3;
my $bmp = pack 'a2 V V V l< l< l< v v V V l< l< V V',
'BM', $len + 54, 0, 54, 40, $attrs[1], $attrs[2], 1, 24, $len, 0,
+0, 0, 0;
$bmp .= join'', unpack '(xaaa)*', $gd;
## Now print $bmp to a file xxx.bmp and convert; or maybe pipe directl
+y to an image converter for conversion.
It's a bit "magic number" ladened, but that's all they are; magic numbers.
Yell, if you really need the explanation :)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply]
[d/l] |
|
|
my $bmp = pack 'a2 V V V l< l< l< v v V V l< l< V V',
'BM', $len + 54, 0, 54, 40, $attrs[1], $attrs[2], 1, 24, $len, 0,
+0, 0, 0;
I tried it immediately but i can't view the file with various image processing software. In some it is simply black, some other reject it.
Examining the file i get:
karls-mac-mini:monks karl$ file mandelbrot.bmp
mandelbrot.bmp: PC bitmap, Windows 3.x format, 1280 x 1024 x 24
This looks good, but:
karls-mac-mini:monks karl$ identify mandelbrot.bmp
identify: unrecognized compression `mandelbrot.bmp'.
Or something is wrong with my GD installation. But i don't think so because the script would complain if something went wrong.
Thank you very much for advice. Perhaps you have a hint how to continue.
Best regards, Karl
«The Crux of the Biscuit is the Apostrophe»
| [reply]
[d/l]
[select] |
|
|
my $gd = $image->gd;
my( undef, $width, $height, undef, undef ) = unpack 'nnnCV', substr( $
+gd, 0, 11, '' );
my $len = length( $gd ) / 4 * 3;
my $bmp = pack 'a2 V V V l< l< l< v v V V l< l< V V',
'BM', $len + 54, 0, 54, 40, $width, -$height, 1, 24, 0, $len, 0, 0
+, 0;
$bmp .= join'', unpack '(xaaa)*', $gd;
Looks like I had two fields transposed; even though my image viewer didn't notice (or just didn't look).
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply]
[d/l] |
|
|
|
|
|
|
|
