Thanks. It does look promising.NicolasRobidoux wrote:(No apologies needed: I was not very clear.)anthony wrote:I am sorry I am not really familar with upsmooth or exactly what you did in the last example.
NIP2 upsharp, upsize and upsmooth are generic names for "state-of-the-art" resampling methods tuned for upsampling that my collaborators and me are developing. They follow an approach which is almost orthogonal to what IM does.
...
I hope this helps make sense. If you are a masochist, you can have a look at http://portal.acm.org/citation.cfm?id=1557657
image size convention in resize.c
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: image size convention in resize.c
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: image size convention in resize.c
Anthony:
I put some additional info here:
viewtopic.php?f=1&t=17447&start=15#p65650
You will not be surprised to learn that there is a lot of information about the methods in the source code comments :-}
If you can't download from ACM, you can get a copy of the article (about Nohalo subdivision minus LBB finish which was not developed then) here:
http://eprints.ecs.soton.ac.uk/18086/
We did the numerical tests with a version of IM which I believe pre-dates your improvements. Needless to say, we'll have to redo the tests from scratch (esp. now that I understand the internals of IM better).
I put some additional info here:
viewtopic.php?f=1&t=17447&start=15#p65650
You will not be surprised to learn that there is a lot of information about the methods in the source code comments :-}
If you can't download from ACM, you can get a copy of the article (about Nohalo subdivision minus LBB finish which was not developed then) here:
http://eprints.ecs.soton.ac.uk/18086/
We did the numerical tests with a version of IM which I believe pre-dates your improvements. Needless to say, we'll have to redo the tests from scratch (esp. now that I understand the internals of IM better).
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: image size convention in resize.c
I have added the distort resize equivalents to IM examples, Resize, Distort
http://www.imagemagick.org/Usage/resize/#distort
And while I use lanczos for final enlargement example of the rose (to show the better result of using 2D handling. I would prefer to keep the default distort filter set to the "robidoux" filter that was developed.
However the last part of the cylindrical filters section for specific filters does need some re-write.
http://www.imagemagick.org/Usage/resize/#distort
And while I use lanczos for final enlargement example of the rose (to show the better result of using 2D handling. I would prefer to keep the default distort filter set to the "robidoux" filter that was developed.
However the last part of the cylindrical filters section for specific filters does need some re-write.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: image size convention in resize.c
Anthony:
Very clear write up.
Very clear write up.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: image size convention in resize.c
Give that, IMHO, distort (Jinc-Jinc) Lanczos is, at least when transparency is not an issue, the nicest resampling method currently programmed in IM, I think that it would be nice if -resize had a flag which would make it use distort to perform the resizing (basically running what was shown earlier in this thread).
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: image size convention in resize.c
I doubt that will happen. A new resize option might be possible.
Whether it should happen or be provided I am of mixed feelings.
But in the mean time I do clearly demonstrate how to do the distort equivalent on the resize page, for those who do want to use a cylindrical distort.
What is you standing on your original suggestion? That is resize based on mid-pixel of source, mapping to mid-pixel of destination. Of course distort can do that very easily too, once you have calculated the final image size in integer pixels.
Whether it should happen or be provided I am of mixed feelings.
But in the mean time I do clearly demonstrate how to do the distort equivalent on the resize page, for those who do want to use a cylindrical distort.
What is you standing on your original suggestion? That is resize based on mid-pixel of source, mapping to mid-pixel of destination. Of course distort can do that very easily too, once you have calculated the final image size in integer pixels.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: image size convention in resize.c
Although the exact details are to be discussed (with you, Cristy, and whoever care to comment), I think that something like the following should be programmed (just no time to do it now). The terminology, of course, is also subject to discussion:anthony wrote:What is you standing on your original suggestion? That is resize based on mid-pixel of source, mapping to mid-pixel of destination. Of course distort can do that very easily too, once you have calculated the final image size in integer pixels.
Default:
--Match corners (like now)
New additional options:
--Match centers
--Mix and match (choose which convention to use in each direction depending on whether one is enlarging (match centers) or shrinking (match corners) in that direction)
One way to do this would be to have two flags named something like matchcorners and matchcenters so that
( matchcorners = true AND matchcenters = true ) give "mix and match"
( matchcorners = false AND matchcenters = true ) give "match centers"
and the other two combinations of logical values for the two variables give the current "match corners" default behavior.
(Note that I certainly don't claim to have a clear picture of what is idiomatic for IM.)
If we want to go for terse, I suppose the variables could be called "corners" and "centers." The way I set things up above is such that if the internal default is for both to be false (which would give the current behavior), setting only one variable to true would give that convention, and only if both variables are set to true would the "mix and match" behavior occur.
Last edited by NicolasRobidoux on 2010-12-07T14:02:38-07:00, edited 1 time in total.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: image size convention in resize.c
I meant resize option (which I keep calling a "flag").anthony wrote:A new resize option might be possible.
Whether it should happen or be provided I am of mixed feelings.
Me or my students are unlikely to be able to touch this for quite a while. So, as long as you have mixed feelings (and consequently do not program it yourself) it is not going to happen