resizing JPEGs (with Img and photo image)
spoo...@cox.net
way, I'm clearly missing it....
I'm working on a new neat idea for JStrack (the freeware hurricane
tracking program I wrote---see www.jstrack.org), specifically (if the
user wants to do so), downloading the current satellite imagery and,
overlaying it on top of (well, actually under) the existing
map/coordinate grid. Just two problems....
1) The satellite image and the map image are from two different views
(one from 22,300 miles in space directly above the equator, the other
a flat map), and the images will never line up perfectly...but by some
creative resizing (X axis stretched slightly more than Y axis) it
works out to be reasonably close.
2) The amount that I need to resize the image is not an integral
amount, it's a percentage (or, better still, a specific size
in pixels). Specifically (for the Gulf close-up), the image
needs to be resized from 720x480 (1.5:1) to 1324x980 (1.35:1)
to best fit with the map. Yeah, I know...but it actually looks
ok.
I've tried using -zoom ... but it'll only accept integral amounts, and
they're not percentages. I've tried specifying the image size, but I
just end up with multiple copies of the image. I've tried -zoom
combined with image size and -shrink ... but it doesn't work.
Can anyone point me in the right (for Unix, Windows, Mac, etc.)
direction? Assume Tcl/Tk 8.3.x or 8.4.x (if it has to be 8.4, that's
ok---just specify that and it'll be a requirement for the new feature)
with Img (already required for the satellite imagery).
Thanks,
--jim
PS: I've already got the satellite imagery display in its own
toplevel...but this is something I thought of this morning while
looking at the satellite imagery...specifically, it would be neat
to give users (and that includes me) the option of putting it
right on the chart with the map and plot on top of it...but if
I can't get things to line up reasonably well, it could just end
up being more misleading than useful, and that's a Bad Thing.
--
73 DE N5IAL (/4) | "This 'telephone' has too many
spoo...@cox.net | shortcomings to be seriously considered
ICBM / Hurricane: | as a means of communication. The device
30.39735N 86.60439W | is inherently of no value to us."
| (Western Union internal memo, 1876)
Donal K. Fellows
> 2) The amount that I need to resize the image is not an integral
> amount, it's a percentage (or, better still, a specific size
> in pixels). Specifically (for the Gulf close-up), the image
> needs to be resized from 720x480 (1.5:1) to 1324x980 (1.35:1)
> to best fit with the map. Yeah, I know...but it actually looks
> ok.
>
> I've tried using -zoom ... but it'll only accept integral amounts, and
> they're not percentages. I've tried specifying the image size, but I
> just end up with multiple copies of the image. I've tried -zoom
> combined with image size and -shrink ... but it doesn't work.
Ah yes, the lameness of the image resizing code (and as the maintainer
of that code I can say that it is lame with absolute certainty!) While
a combination of -zoom and -subsample would work, *don't do that*.
It's horrible. Instead, you need a resizing engine. A good place to
start looking is http://wiki.tcl.tk/10520 but I suspect you may be
better off going to http://wiki.tcl.tk/9775 (i.e. TclMagick) which is
far more capable (and faster) than scripted versions.
Donal.
pwe...@zonnet.nl
command.
Peter
davidn...@gmail.com
> better off going tohttp://wiki.tcl.tk/9775(i.e. TclMagick) which is
> far more capable (and faster) than scripted versions.
TclMagick also has the advantage over Img and the like that you can
use it without Tk if you ever wanted to do something like a web
version.
MartinLemburg@UGS
But ... I'm not able to use inside a starpack, because ImageMagick or
GraphicMagick wants to use some registry keys, created while
installing the DLLs on one computer.
Those registry keys will be missed on another computer, even while the
DLLs would work.
Workaround:
Create such registry keys, if not existent and delete them at the
end of the work.
Risk
A crash or unexpected starpack end might prevent the registry
cleanup at the end.
Why is TclMagick (with (Image|Graphic)Magick only available with an
installation?
Greetings,
Martin
On Jul 30, 4:33 pm, "davidnwel...@gmail.com" <davidnwel...@gmail.com>
wrote:
Darren New
> But ... I'm not able to use inside a starpack, because ImageMagick or
> GraphicMagick wants to use some registry keys, created while
> installing the DLLs on one computer.
Consider using pbmplus instead, then.
--
Darren New / San Diego, CA, USA (PST)
I bet exercise equipment would be a lot more
expensive if we had evolved from starfish.
sp...@controlq.com
> Date: Mon, 30 Jul 2007 08:11:45 -0700
> From: "MartinLemburg@UGS" <martin.le...@gmx.net>
> Newsgroups: comp.lang.tcl
> Subject: Re: resizing JPEGs (with Img and photo image)
It appears that ImageMagick has a ./configure option not to create an
"Install" version (--disable-installed), and thus the standard "paths" are
not created as defaults, but are instead read from environment variables.
This may well prevent the requirement for registry entries if all you need
are the Wand libraries, but does create some difficulties when compiling
TclMagick, as the Wand-config utility will not be on the path as a result.
As TclMagick amounts to essentially a single .c and .h, (in ./generic)
hacking together a make script turns out to be not too difficult, though
without the handy Wand-config tool, you'll have to pay some attention to
required libraries and paths to same ...
As we are speaking about "registry keys", I assume that .dll's are the
required format, and some care in wrapping will ensure that you package up
everything that a standard windows box does not ... perhaps doing a full
install will assist you by giving you a list of required libs and paths as
determined by Wand-config, and then proceed with creating libraries using
the "no-install" option.
On FreeBSD, the following script works to compile tclMagick (note the
backticks around the Wand-config command):
wndcfg=/usr/local/bin/Wand-config
gcc -shared -DUSE_TCL_STUBS -fPIC -DUSE_TK_STUBS -DUSE_TK_STUBS -I. \
-I/usr/local/include -L/usr/local/lib -L/usr/lib \
`$wndcfg --ldflags --libs` \
-o tclmagick.so -O2 -DNDEBUG TclMagick.c
a variation on the above using mingw32 should do the trick for windows,
with the only issue is to determine the values for Wand-config --ldflags
and --libs for your particular platform.
Hope this helps ...
Rob.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
MartinLemburg@UGS
But to be honest ... I never built any tcl extension, like I never
used cygwin, gnu compile tools, minw or another build system on my MS
Windows computer and I don't know enough about configure scripts,
etc..
The only thing I want is ...
1. ... a TclMagick DLL looking in its own directory for the (Image|
Graphic)Magick DLLs, or if not found inside the path (normal OS
behaviour, right?)
2. ... a set of (Image|Graphic)Magick DLLs, that don't need any
registry keys or environment variables
3. ... a most simple extension to be used right out of the box
What I did until today ...
1. ... installed GraphicMagick to get the DLLs used by TclMagick
2. ... found out which (Image|Graphic)Magick DLLs depends on each
other, because I only want to resize a JPEG file to a thumbnail
3. ... reduced the size of the starpack by including the TclMagick
"Package" and the minimal set of needed and dependend (Image|
Graphic)Magick DLL files
4. ... built the starpack used it on one computer, where it worked,
even after uninstalling GraphicMagick
5. ... copied the starpack to another computer, where it failed,
because GraphicMagick never was installed
I'm a software developer, but sometimes I just want to be in the rule
of the user of packages, where I hopefully don't have to invest too
much time to. If I have to develop on a package I want to use, I'm not
so amused of.
But here it is not the propblem of TclMagick - it's a problem of
GraphicMagick, which registers without asking file type associations
and its paths, configuration, etc..
Why is this necessary?
Ok - this JPEG handling starpack is my private fun, so I'll use the
standard distribution of TclMagick, and GraphicMagick and I'll fake
the registry.
Best regards,
Martin
On Jul 30, 6:50 pm, s...@controlq.com wrote:
> On Mon, 30 Jul 2007, MartinLemburg@UGS wrote:
> > Date: Mon, 30 Jul 2007 08:11:45 -0700
> > From: "MartinLemburg@UGS" <martin.lemburg....@gmx.net>
> ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----http://www.newsfeeds.comThe #1 Newsgroup Service in the World! 120,000+ Newsgroups
spoo...@cox.net
>Here's another procedure I added: expandxy ...
DISREGARD.... I finally got it to work (oddly enough, by just adding
another puts---must be a problem with quoting somewhere in my changes).
Anyways, it's so mind-bogglingly slow (as I was warned a few posts ago
that it would be), it's not worth it.
So...I guess the idea for a new JStrack feature is on hold. Thanks
anyways for the suggestions and help.
Later,
--jim
--
73 DE N5IAL (/4) | |\ _,,,---,,_
Ft. Walton Beach, FL | ZZZzz /,`.-'`' -. ;-;;,_
spoo...@cox.net | |,4- ) )-,_. ,\ ( `'-'
ICBM/Hurr.: 30.39735N 86.60439W | '---''(_/--' `-'\_)
spoo...@cox.net
The answer: use netpbm (that package *ALWAYS* seems to be the
solution...useful stuff...but I didn't know until today that it
was available pre-compiled for Windows---I've always just moved
the images to my Unix system, do whatever is needed, and then
move them back).
So it works now, given two small .exe files and a small .dll
that I can give Windows users to download, or for Unix users,
the netpbm (I keep wanting to say pbmplus) source.
A non-Tcl solution, which isn't my first choice, but....
If anyone wants to see what, exactly, I'm going on about, pull
up your favorite web browser and go to www.jstrack.org/jstrack
and look at the image file gulf_sat+map.gif (or something like
that---I think that's the exact filename). The storm that's
displayed is from last year, btw.
Larry W. Virden
wrote:
>
> The only thing I want is ...
>
> 1. ... a TclMagick DLL looking in its own directory for the (Image|
> Graphic)Magick DLLs, or if not found inside the path (normal OS
> behaviour, right?)
> 2. ... a set of (Image|Graphic)Magick DLLs, that don't need any
> registry keys or environment variables
> 3. ... a most simple extension to be used right out of the box
the dependencies you've encountered?
There is a TclMagick mailing list, but it appears to be taken over by
spammers without much apparently cleanup being done on it. When I
visit the project page at sf.net, I do not seem to see a link to the
CVS , which makes me wonder if perhaps the source isn't being
maintained on sf.net. The last file release appears to have been 2.5
years ago. Given that the image libraries on which the extension is
based have updated, I wonder whether an update is in the process of
being created. Perhaps you could email the developers - Rolf Schrodter
and David Welton, to see what they think about the idea.
Roy Terry
> Ok, I figured out a more or less portable way to get this done....
> The answer: use netpbm (that package *ALWAYS* seems to be the
> solution...useful stuff...but I didn't know until today that it
> was available pre-compiled for Windows---I've always just moved
> the images to my Unix system, do whatever is needed, and then
> move them back).
>
> So it works now, given two small .exe files and a small .dll
> that I can give Windows users to download, or for Unix users,
> the netpbm (I keep wanting to say pbmplus) source.
>
> A non-Tcl solution, which isn't my first choice, but....
a windows-only Tcl extension for image scaling and rotation that just
requires a single DLL.
How did xphoto.dll not meet your needs?
http://wiki.tcl.tk/11924
It does require Tk and has a bug or
two but generally works very well with Tcl/tk8.4 in my
usage.
Roy
spoo...@cox.net
Roy Terry <r...@terryhome.org> wrote:
>How did xphoto.dll not meet your needs?
>http://wiki.tcl.tk/11924
Quite possibly because, until I just now read your post, I'd never
heard of it. :-) Still, it's working now, and it's a lot simpler
to ask a Unix user to have netpbm (which, even from its pbmplus days,
has always seemed to be a very popular package that's likely ALREADY
installed than it is to ask them to patch/rebuild/reinstall their
Tk 8.[2-4].x.
I don't mean to sound negative towards xphoto.dll and the work that
you've put into it...really, I don't. If it were built as an
external shared library (dll for windows boxes, libxphoto.so for
Unix systems, etc.), I'd probably switch to it, but I'm trying to
consider my users, who range from A) experienced Unix types who,
when they have ideas for new features, learn Tcl/Tk, code it, and
then send me a patch file (yes, a real patch file) to B) windows
users who send me a plea for help every time the NHC/TPC ftp server[1]
tells them in its motd that it's a US Gov't system and that misuse
of the system is a federal offense (ok, I've only gotten a few of
those from the same user, but I've gotten a *LOT* of those from
different users)....
Later,
--jim
[1] I originally wrote JStrack for Unix, designing it to get its data
from incoming e-mail via the WX-ATLAN list, procmail scripts that
pipe NHC/TPC products to filt.tcl, and filt.tcl and read_fc.tcl,
which "read" the NHC/TPC products and extract the data to feed it
to JStrack (whether it's running or not...if it's not running, if
the user isn't logged in, whatever...the changes are there when
the user runs JStrack again.
But, since JStrack is all Tcl/Tk (with the ability to use external
libraries/binaries for added capabilities), I wanted to get it
running under windows, too, so I could support that whole big
group of users as well.
Unfortunately, unless something's changed recently and I don't
know about it, procmail doesn't run on windows[2], nor is there
any portable (i.e., doesn't matter what e-mail program the user
is using) solution, so using WX-ATLAN for updates there is out.
Thus, ftp from the NHC/TPC's ftp site.... It's not as reliable
(when the ftp server gets too busy, it drops connects fairly
regularly), but it basically works, as long as the user connects
again until JStrack tells them it's finished.
[2] { set joking_around_sarcastic_mode ON
I think it might have something to do with handling every possible
MTA/MDA/MUA combo program out there, since there doesn't appear to be
a way to drop in a replacement for the MDA portion of the programs....
}
I've asked various self-proclaimed "experts" (they had one of those
bits of paper that M$ gave them), after they claimed that *ANYTHING*
that could be done on Unix, they could do better and more easily on
windows (from that, they've just said that they *DO* know how to do
this).... Sadly, however, the best response these "experts" could
give was "you can't do that...but why would you want to?" (This,
after I'd just explained why along with my question---to get procmail
and filt.tcl up and running....) I've yet to get a valid answer to
that question from these "experts". :-)
--
73 DE N5IAL (/4) MiSTie #49997 < Running FreeBSD 6.1 >
spoo...@cox.net || j.gr...@ieee.org ICBM/Hurr.: 30.39735N 86.60439W
No, I'm not going to explain it. If you can't figure it
out, you didn't want to know anyway... --Larry Wall
Roy Terry
> In article <CaMri.13754$Od7....@newsread1.news.pas.earthlink.net>,
> Roy Terry <r...@terryhome.org> wrote:
>
>> How did xphoto.dll not meet your needs?
>> http://wiki.tcl.tk/11924
>
> Quite possibly because, until I just now read your post, I'd never
> heard of it. :-) Still, it's working now, and it's a lot simpler
> to ask a Unix user to have netpbm (which, even from its pbmplus days,
> has always seemed to be a very popular package that's likely ALREADY
> installed than it is to ask them to patch/rebuild/reinstall their
> Tk 8.[2-4].x.
>
> I don't mean to sound negative towards xphoto.dll and the work that
> you've put into it...really, I don't. If it were built as an
> external shared library (dll for windows boxes, libxphoto.so for
> Unix systems, etc.), I'd probably switch to it, but I'm trying to
> consider my users, who range from
BTW, I didn't write the xphoto code. I'm just a user.
Cheers,
Roy
walto...@gmail.com
> In article <CaMri.13754$Od7.11...@newsread1.news.pas.earthlink.net>,
> No, I'm not going to explain it. If you can't figure it
> out, you didn't want to know anyway... --Larry Wall
I don't know if this was mentioned yet, but you could just [exec] the
ImageMagick .exe's.
davidn...@gmail.com
> spammers without much apparently cleanup being done on it. When I
I'm not sure how they managed to post, since non-subscribers
automatically get moderated, and I sure didn't let that through the
moderation queue. Must have fancy bots that can subscribe and post:-/
> visit the project page at sf.net, I do not seem to see a link to the
> CVS , which makes me wonder if perhaps the source isn't being
> maintained on sf.net. The last file release appears to have been 2.5
> years ago. Given that the image libraries on which the extension is
> based have updated, I wonder whether an update is in the process of
> being created. Perhaps you could email the developers - Rolf Schrodter
> and David Welton, to see what they think about the idea.
The source is being maintained as part of the GraphicsMagick project.
I think the developers are kind of busy with other projects lately,
but still try and keep an eye out for improvements.
Eric Hassold
Let me propose just another option, called Pixane, just in case you wish
to condider as many solutions as possible.
http://www.evolane.com/software/pixane/index.html
This is a Tcl API to read, write and manipulate images in Tcl (Tk not
required). It used to be available only as part of our eTcl distribution
(which supports a large variety of platform), but we released today a
standalone distribution, as dynamic libraries, also with support for a
large set of platforms, i.e. Win32, WinCE, MacOSX (x86 and powerpc),
linux (x86, arm, powerpc, mips).
Those loadable libraries has no external dependencies at all, and can be
used with nearly any Tcl distrib (tested with ActiveState and tclkits,
and of course eTcl while pointless since it is already part of official
distrib).
Pixane offers more than just read/write/scale images. [pixane] and
[pixfont] commands (both provided by those libraries) are described here:
http://www.evolane.com/software/pixane/pixane.html
http://www.evolane.com/software/pixane/pixfont.html
It's still missing good documentation and recipes, but below is a sample
code to illustrate how to achieve your goal with it.
Regards,
Eric
--
# Init package
package require pixane
# Create and load source image
set psrc [pixane create]
pixane load $psrc -file test.jpg
# Maximal geometry for target image
set maxw 240
set maxh 240
# If true, preserve ratio
set ratio 1
if {$ratio} {
set srcw [pixane width $psrc]
set srch [pixane height $psrc]
if {$maxw*$srch<$maxh*$srcw} {
# Scale factor is $maxw/$srcw
set vw $maxw
set vh [expr {($srch*$maxw)/$srcw}]
} else {
# Scale factor is $maxh/$srch
set vw [expr {($srcw*$maxh)/$srch}]
set vh $maxh
}
} else {
set vw $maxw
set vh $maxh
}
puts "Scaling ($srcw x $srch) => ($vw x $vh)"
# Create target image
set pdst [pixane create]
pixane resize $pdst $vw $vh
pixane blank $pdst
pixane scale $pdst $psrc
# Save image. That's all
pixane save $pdst -file test_small.jpg -format jpeg
-----
Eric Hassold
Evolane - http://www.evolane.com/
spoo...@cox.net wrote :
davidn...@gmail.com
> Hi,
>
> Let me propose just another option, called Pixane, just in case you wish
> to condider as many solutions as possible.
>
> http://www.evolane.com/software/pixane/index.html
>
> This is a Tcl API to read, write and manipulate images in Tcl (Tk not
> required). It used to be available only as part of our eTcl distribution
> (which supports a large variety of platform), but we released today a
> standalone distribution, as dynamic libraries, also with support for a
> large set of platforms, i.e. Win32, WinCE, MacOSX (x86 and powerpc),
> linux (x86, arm, powerpc, mips).
Looks like a nice bit of code, and a good alternative to TclMagick.
For the other poster, though, the license looks like it will be a
problem:
"You may not distribute copies of this Package, or
copies of packages derived from this Package, to others outside your
organization without specific prior written permission from
Evolane (although you are encouraged to direct them to sources
from which they may obtain it for themselves)."
Eric Hassold
davidn...@gmail.com wrote :
> On Aug 2, 3:25 am, Eric Hassold <hass...@evolane.com> wrote:
>> Hi,
>>
>> Let me propose just another option, called Pixane, just in case you wish
>> to condider as many solutions as possible.
>>
>> http://www.evolane.com/software/pixane/index.html
>>
>> This is a Tcl API to read, write and manipulate images in Tcl (Tk not
>> required). It used to be available only as part of our eTcl distribution
>> (which supports a large variety of platform), but we released today a
>> standalone distribution, as dynamic libraries, also with support for a
>> large set of platforms, i.e. Win32, WinCE, MacOSX (x86 and powerpc),
>> linux (x86, arm, powerpc, mips).
>
> Looks like a nice bit of code, and a good alternative to TclMagick.
Some might also find this useful as an alternative to Img extension,
since if loaded into an interpreter with Tk present, it registers
support for lot of graphics format (png, jpeg, bmp, wbmp, ...) for Tk
photos, without needing to have specific versions of libpng, libjpeg,
etc... libraries on target system.
>
> For the other poster, though, the license looks like it will be a
> problem:
>
> "You may not distribute copies of this Package, or
> copies of packages derived from this Package, to others outside your
> organization without specific prior written permission from
> Evolane (although you are encouraged to direct them to sources
> from which they may obtain it for themselves)."
>
>
Right. Those are default redistribution conditions for binaries, taken
from ActiveTcl philosophy and conditions.
However, free or open projects which find this useful and would love to
redistribute it for free embedded into their software (e.g. embedded
into their tclkit) may just ask for it. I must admit we are not fans of
all those legal stuff. For non-commercial use, what really matters to us
is that potential bugs end up being reported to us for fixing, either
because end users knows what he/she is using, or because maintainers for
the package which use it will consider forwarding them to us. This is
important since Pixane is still considered beta-stage.
Eric