| Age | Commit message (Collapse) | Author |
|---|
|
I noticed that it would be beneficial to release the invert.c code
listing under a very permissive license.
I like the style of the "Copy me if you can"-License, but thought
that 0BSD would make it even clearer that everyone can do whatever
he wants with this code.
The code itself was not bad beforehand, but lacked some elementary
features like checked flushing at the end and proper error messages.
I also reworked the data structures a bit to make it more appealing
and clearer where the "guts" of the code are (i.e. in invert()).
|
|
Make them more consistent, and only maintain a list of the conversion
tools in farbfeld.5.
Refine the wording on the jpg-manpages.
|
|
|
|
and rather define it in the manual.
In the end, it doesn't influence the data structure and thus is not
part of the FORMAT-specification.
|
|
Talking with even more people and weighing the benefits, I've made the
decision to remove color spaces from farbfeld again (as it currently
is handled in version 1) and recommend sRGB, not force it.
Thing is the following: We are not ready yet for this step. Neither the
people working with the images nor the hardware to display extended
colors. Using greater colorspaces also removes the "hackability" of
farbfeld.
As it was previously possible to easily create gradients in plain C,
you have to keep multiple things in mind with linear ProPhoto RGB.
The first thing is that not all colors are "real", and there are
imaginary colors. This doesn't happen with sRGB because all the colors
it describes are "real".
The second thing is the linear gamma curve, which makes the gradients
look perceptually inconsistent.
In the interest of creating a good and simple interchange format, we
can't only weigh in points of professionals. This little excursion has
shown that aiming for the 99% is still the way to go.
And as often as you could repeat that sRGB will meet its fate in the
future when screens become better, it is surprising how badly the
industry has caught up to it.
I also must honestly say that we can't solve the color space issue
using RGB and should look at other formats to explore (CIELUV, CIELAB),
which I will probably give a talk about at slcon3.
Before releasing version 2, my aim is to make the I/O a bit more
effective (as far as possible) so it's even easier to use.
I know people will be pissed off, but fuck it, I'm the maintainer!
Live with it.
|
|
I've literally been thinking about this for quite a while now. The
initial motivation behind defaulting to sRGB was the idea that most data
on the web was in sRGB anyway.
However, my assumption was weakened in the sense that the development
is clearly moving towards images with supplied ICC profiles and software
slowly catching up to handle this. My tests have shown that more and
more people even do that on the web, even though it's been a "tradition"
that Photoshop users "Save for Web" and convert the gamut lossy into
sRGB to bring a consistent color-"experience" even to those clients not
supporting ICC profiles and which always assume sRGB.
What made this decision so difficult is that converting to "ProPhoto
RGB" requires some advanced knowledge on this topic, however, I came to
the conclusion to implement it given the *2ff- and ff2*-tools handle it
silently and well in the background, and given the little cms library is
actually quite okay to use.
When converting from ff to png, a proper "Pro Photo RGB" ICC V4-profile is
automatically included in the exported png by ff2png. V4 is not as
widespread as V2, but in the worst case (no V4 support somewhere) the
colors will just be a little off.
As an added bonus, any input files for png2ff which include ICC profiles
are also correctly handled and the color space conversions are executed
as expected.
Accordingly, the FORMAT-specification has been changed. While at it,
I added the note on alpha-multiplication. Now the format is very exact
and shouldn't leave any ambiguities.
jpeg supports ICC profiles as well, but I hadn't had the chance to look
into it (not as trivial as PNG probably, help appreciated :)), so I'm
always assuming sRGB here.
Rationale
---------
It is not obvious why one would go through the lenghts of supporting
this big-gamut colorspace and not just stick with sRGB. In 99% of the
cases, there's no reason to do that, but with even more extreme
developments in the OLED-sector and other advances display hardware is
slowly getting more powerful than sRGB, asking for color information
which is suitable for the task and actually uses the full potential.
The decision in this regard was not difficult in farbfeld because we
always use 16-Bit anyway and won't have to fear posterization in a big-
gamut color-space.
|
|
|
|
Now that we're in main, we don't need to exit().
Also, we should return 0 at the end, thanks Hiltjo!
|
|
We were close to a full program anyway, so I just completed the code so
you can study and run it easily.
|
|
1) We forgot to write the header out again (no changes, but else the
format would have obviously been broken)
2) The order of 'size' and 'count' was wrong in the fread- and fwrite-
calls inside the loops, and the checks were failing.
now this is fixed.
|
|
|
|
|
