Let r be the downsampling ratio (approximately equal to the output and
input widths in pixels).
I would not expect NoHalo to give great results if r * OFFSET_0 is much
smaller than 1, and LoHalo if r * OFFSET_0 is much smaller than 2.
Specifically, if OFFSET_0 is 16, I would not expect any of
I suspect that it would make very little difference when downsampling, but
maybe sigmoidization, as used in LoHalo, is not worth the computational
cost.
Very easy to modify the code:
Remove the extended_sigmoidal and inverse_sigmoidal function definitions,
and then replace these strings (which
Liam:
Do you ever find LoHalo (snail crawling notwithstanding) worthwhile?
Nicolas
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List
We won't provide any conclusions because the results in the given tests
context are self explanatory.
This is another way to say: Trying to put things in context so that the
results are relevant to real life would expose us to criticism, so we'll
say it's obvious so that other people get the
I unfortunately don't have time to do it myself even though it is an easy
job, but could someone rip out the internal conversions into and out of
sigmoidal color space and just use whatever is incoming (linear float
light, if I remember right) both for the EWA Robidoux component (already
uses
I looked at DSC00434_1600.png and it smells like a tiling subsystem bug to
me.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List
+1
On 14 October 2014 15:54, Simon Budig si...@budig.de wrote:
While it certainly could be more concise, the discussion has helped me
tremendously with my glimpse into gegl/babl. So while the
misunderstandings might be easier to overcome within a phone call
keeping the discussion on the list
Nothing to do with GIMP: JPEG does not support transparency.
Search for jpeg transparency. You'll get links like:
http://corner.squareup.com/2013/01/transparent-jpegs.html.
___
gimp-developer-list mailing list
List address:
On 21 April 2014 10:47, Teo Mazars maza...@ensimag.grenoble-inp.fr wrote:
... are you really saying that Gradient should be implemented using a
non-perceptual color space?
I am sure this has been discussed in more detail elsewhere (didn't a CSS
committee discuss this somewhat recently?), but
Opinion:
Using, internally, a reference unbounded color space (or two: one linear,
one perceptual, with, possibly low precision shadows for speed), and
converting in and out of it when an image is imported or exported is a sane
choice.
Deviations from the standard internal color space(s) should
(Apologies if I am missing the point.)
What Elle's excellent
http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.htmlsuggests
to me is that the designer of an operation should choose what
color space the operations should internally work in, and convert in and
out of it.
I'm getting questions about negative light values and values larger than
255 and why one would not clip them at every step of a chain of operations
even if the initial input image and final output images are both (say) sRGB.
(Maybe putting quotes around gamut was not quite enough to be clear.)
My apologies for being vague: Indeed white is not necessarily at the
boundary of the set of values in 3D that are used to represent color
values. (It is in sRGB.)
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List
Summary:
It is my very strong opinion that values should not be clamped by default.
If you are writing an operation (a node) that is broken by negative or
values breaks, do not clamp the input and output without carefully
considering the possible impact on the entire toolchain.
Very very
Some operations are made worse if you don't allow out of gamut values
(e.g. blacker than black and whiter than white).
The first example that comes to mind is convolutions that are implemented
in a separable way and that have negative coefficients.
I vaguely remember something about resampling
This is how to fix this
Enhance GIMP and GEGL so that the Image Scale and Layer Scale
operations use the “CLAMP” (nearest neighbour) abyss policy and the
tools that use samplers use the “NONE” (fade to transparency) abyss
policy. This will remove the border artifacts from the former
operations
, within
the sampler code.
(Emphasis on suggest.)
Nohalo BTW does not convert. The upsampling component probably would look
better if it used nonlinear light.
Nicolas Robidoux
Senior Research Scientist
www.phaseone.com
___
gimp-developer-list mailing list
Dear team.gaming:
The core git repos for GIMP and related projects are here:
https://git.gnome.org/browse/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Chiming in:
Multi-core requires love to work well.
ImageMagick, for example, has been known to run considerably faster on busy
systems with openMP disabled.
In GIMP 2.6, frequent marching ants were a CPU sink. (Bad observer
effect.)
___
Indeed, maybe -g does not affect performance. I did not measure.
http://stackoverflow.com/questions/89603/how-does-the-debugging-option-g-change-the-binary-executable
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
Warning: Untested
If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source,
maybe you should try
CFLAGS=-march=native -O3 CXXFLAGS=-march=native -O3 ./autogen.sh ...
instead of the usual
./autogen.sh ...
This may, or may not, make a noticeable difference.
But if I was
There is a little bit of c++ floating around here and there TTBOMK.
-
Make sure to wear safety goggles and a flak jacket.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
I replied privately that VIPS/NIP2 and ImageMagick talks probably would be
more appropriate, providing contacts.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Indeed: Shoot me so I don't have to do it myself ;)
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Actually, it's almost certainly not me:
Bug is there using bleeding edge git GIMP together GEGL with the last
commit made before I jumped back in, namely
fa80fb559b66ab80f5e6f63edb621e642f006862, dated 2012-11-13
Also, the reflection self-tests done with gegl from xml come out good.
It is my opinion that XYZ is not fully replaced by infinite gamut linear
RGB if only because XYZ has a channel which is a proper luminance channel.
RGB does not.
Enough to deserve a place within GIMP? Don't know. If my (initial) inputs
and (final) outputs are sRGB, linear RGB with sRGB primaries
Could an xcf file contain info RE: export preference?
Then, for example, you could use the last used across sessions or whatever
other rule, but loading an xcf would override.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
Dear Caitlin:
Treat GIMP as you treat paint and paper.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Joao:
Read the article!
My guess is that the SR scheme combines two things:
1) Look for similar things at the same scale within the image to
reconstruct a platonic ideal which you then replicate (this is
super-resolution using data from the same image; classical
super-resolution uses multiple
On the other hand - how is your work going? Are you making it avalilable as a
GEGL OP as well?
Yes, that's always been the plan. But everything else I do has been
taking a lot longer than expected...
At least, I think that I've come to the point where my methods are
just about as good as they
One last grumpy comment: Look at the right nostril of the baby. It's
pure fiction.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Sorry: Left nostril.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
I stand to be corrected on this, but I believe that there is more than
one sRGB standard. I also vaguely remember reading that the formulas
are slightly different for 8 and 16 bit sRGB, meaning that they don't
exactly agree at the common (scaled) values.
http://www.color.org/srgbprofiles.xalter
the alignment of 8-bit sRGB with 16-bit sRGB.
--
Nicolas Robidoux
Image processing and applied mathematics consultant
http://river-valley.tv/better-and-faster-image-resizing-and-resampling
http://www.linkedin.com/profile/view?id=144301767
nicolas.robid...@gmail.com
http://en.wikipedia.org/wiki/Self-similarity
SR and Fattal are most effective when the image contains much of it,
and this is reflected in the choice of test images.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
Libvips, which has many similarities to GEGL, uses Orc
http://code.entropywave.com/orc/.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
- what you see inside a GIMP window is always, always, always in
GIMP format, even if the only thing you did was open (= import, as
it shows in the interaction) a png file and nothing more.
- it is 100% impossible to arrange it for popular non-GIMP files
(png/jpeg/tiff) there would be a mode
I also believe that gg hits an important point by suggesting that a
clear choice be made w.r.t.
Are we opening and image, or a file?
They truly are not really the same thing.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
- to really Save the contents of the file has to match what is
on the screen (save, quit, restart, open file: no change--undo
history excepted). this is not just a good idea, this is the law.
breaking the law: usability blooper.
Indeed, if Save is lossless is a law, Save has to be to XCF, and
For a non GIMP solution (with severe constraints on the rotation and
cropping parameters, as is pretty much unavoidable):
http://jpegclub.org/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
On Mon, May 21, 2012 at 5:31 PM, Guillermo Espertino (Gez)
gespert...@gmail.com wrote:
I'm not totally against the idea of a project, but I wonder if it's really
necessary to create a project folder with assets considering that XCF is
intended to store all that stuff in a single file.
The
...
Just change S key to E key on keyboard
...
It's about first impressions. By the time one is remapping keys, it's too late.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
On Mon, May 21, 2012 at 10:51 AM, Kevin Cozens ke...@ve3syb.ca wrote:
...
Interesting idea but how/when will someone be able to toss away the XCF
files they no longer need for projects they worked on ages ago. For a
certain group of users this would just fill up their hard drive with XCF
Another terminology suggestion:
Save image: jpeg, png, tiff, gif, whatever, with default chosen either
reasonably (match what the user fed to GIMP, or the last one used) or
somewhat safely (not JPEG unless specified).
Save work: xcf
Save project (or, possibly, workspace): multiple xcfs if there
This is how things work in NIP2. (I am not holding NIP2 as a paragon
of beginner friendliness by no means. Just brainstorming, and adapting
things a bit to what I understand of GIMP.)
Open/Save have to to with loading/saving from/into the file system
(the hard disk).
Two kinds of objects can be
Once GEGL becomes the operative system, XCF can be understood as the
tree that leads to a specific image.
Save tree?
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Whimsically, save workspace/XCF/image could be save forest/tree/leaf.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Metaphor: A tree (.xcf) will grow away from the forest
(project/workspace), but a leaf (.jpg or .png) cut away from the tree
won't.
(And yes, I am perfectly aware that in a graph theory sense what I'm
proposing to call a leaf is actually a root. The point here is to
communicate the key
On Fri, May 18, 2012 at 4:24 AM, gg g...@catking.net wrote:
...
In any other context opening a file and then saving it, the user will
*expect to be saving the file* . Why try to redefine what the world already
does.
...
Here is a trivial change that would immediately take care of the
Yet another completely different (and rather radical) idea: If the
user saves as JPEG (say), GIMP automatically and silently saves the
XCF alongside it or in a special folder. Then Open/Save does
everything you want, and when the beginner user reopens the JPEG, he
can be asked if he/she wants to
Terminology ideas:
.xcf: composition (composition suggests result of compositing as well
as its process, which is a fitting description, I think) or project
Everything (tools, frames, input and output images...): session,
workspace or project.
.jpg or .png or .tif or ...: image
I agree that Import/Save/Export is likely to make complete sense to
the target user of GIMP 2.10.
I also have the impression that it may be quite effective at informing
soon-to-be-former-users that they are not members of the target club.
___
http://sourceware.org/pthreads-win32/ ?
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
I may go. (Not sure yet.)
--
Nicolas Robidoux
Image processing and applied mathematics consultant
https://www.ohloh.net/accounts/NicolasRobidoux
nicolas.robid...@gmail.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http
Daer Halina:
I've put an example data set (raw output from the detector) here:
https://docs.google.com/open?id=0B_tFwWNVPR8jOGJlNTIwZDYtNjdlYS00N2E2LTlmZjMtZTQ1MWU0YmM1OWFl
This file (Ag_Be_SAXS_.edf_orig) is in .edf (European Data Format
http://en.wikipedia.org/wiki/European_Data_Format)
gegl-sampler-downsharp should not be there anymore. It's a deprecated method.
On Sun, Dec 18, 2011 at 12:31 PM, Ofnuts ofn...@laposte.net wrote:
A long time ago, I built the 2.7.2 version which required upgrading my
BABL/GEGL libraries (running Kunbuntu 10.04) which I did by getting the code
56 matches
Mail list logo
