| Age | Commit message (Collapse) | Author |
|---|
|
|
|
parse_mask() -> parse a mask-color #xxxxxx
ereallocarray()
estrtonum()
These will come in handy in the respective tools.
|
|
We are using stdint.h, which is a C99 feature. Syntactically, the code
is C89 though.
|
|
This is against the standard:
"The application shall ensure that the makefile does not specify
prerequisites for inference rules;"[0]
We are still fine though as we explicitly state the dependency on the
requisite-objects in the $(BIN)-target.
Thanks Lucas for pointing this out!
[0]:http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
|
|
|
|
|
|
|
|
|
|
Thanks Hiltjo for the feedback! GNUisms need to be avoided like a
plague, even if it means having to be a little more creative.
Strict POSIX compliance means that I just worked within the bounds of
the POSIX specification, hopefully without using any GNU or BSD
extensions. If I did, please let me know.
Tip to all Linux users: Test your Makefiles with pmake(1) instead of
make(1) (= GNU make) and refer to the newest POSIX 2016 make
specification[0].
[0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
|
|
|
|
I didn't like the current Makefiles. They were too crufted and not
elegant. Additionally, given I'm planning to put some utility functions
into a util.{c|h}-prerequisite, I wrote this new Makefile with PREREQs
in mind.
|
|
|
|
Laslo: Minor changes
Signed-off-by: Mattias Andrée <maandree@kth.se>
|
|
This also frees us from having to store the return value somewhere.
|
|
Thanks Roberto and Evan Gates!
|
|
If a file begins with "farbfeld", we just pass it through.
|
|
I was inspired by the current discussion on dev@ to use shellcheck to
check my scripts and thought it might be a good choice to do this for
the 2ff script.
Not much had to be changed, because I was careful writing it, but still
it won't hurt to but $TMP in double quotes.
|
|
In case of unexpected end of file errno is not set, and strerror(errno)
returns "Success". Caller should distinguish between error and EOF by
calling ferror(3) as described in fread(3).
|
|
- fix: rebuild on source change.
- allow to override dependency flag per tool (the ones that have deps).
- rebuild on config.mk or headers change.
|
|
This reverts commit 545c500d4278c50e781c9a5a550e92cb0023c8e8.
|
|
I forgot to add the dependencies in the build process
|
|
This may come as a surprise, but I'd like the libraries to handle
these cases.
Maybe some day libpng supports 0x0 images, so why impose artificial
limits here?
Same with ppm.
For me, an ideal data converter loses as little information as possible.
In mixed cases (dimensions 0xn, where n > 0) we could print a warning,
but here, 2 principles come at play:
- GIGO (garbage in, garbage out)
- no information loss if possible
Given the code later on won't try to access the malloc(0) region, we
are also all safe.
|
|
Even though I like line-length limits, it imposed a useless limitation
on the console output, given the line input is variable.
|
|
- be verbose by default: don't hide the executed commands.
- no need to make clean on make dist, but make sure to have a clean directory.
- define 2ff in ${SCRIPTS}.
- make dist: gzip directly, don't store intermediate step (faster for make dist
on floppies).
- don't cd into directories, just loop each file.
|
|
|
|
- jpg2ff requires libjpeg
- ff2png, png2ff requires libpng (and libz)
- ff2ppm has no dependencies
|
|
|
|
|
|
|
|
use the proper multiplication factors :)
|
|
|
|
ff2ppm can convert farbfeld images to PPM (P6 binary format, 24-bit RGB).
ff2ppm has an option -b to set the background color, for example for png files:
png2ff < test.png | ff2ppm -b '#00ff00' > test.ppm
|
|
|
|
There have been quite considerable changes since version 1.
The conversion tools have had a considerable performance boost of
around 75% by using a row-buffer instead of reading each R-G-B-A-chunk
individually.
Also, 2ff(1) somehow called "xconvert" instead of "convert", rendering
it useless for anything other than png's and jpg's.
There was a small excursion to color spaces and ICC color profile
handling, but this has been dismissed (it was a difficult decision).
Thanks for all the feedback!
|
|
|
|
- actually print usage when one argument is given
(forgot to incorporate the argv0-change there).
- use fputs instead of fprintf for printing a string
constant.
|
|
this goes around the undefined behaviour imposed by using
(*(uint32_t *)(hdr + 4n))
|
|
No idea how "xconvert" sneaked into there.
|
|
|
|
|
|
Instead of calling fwrite on each channel, we write one big chunk
of a line.
This increases performance by around 70% compared to version 1 and
the farbfeld tools are now roughly fast as imagemagick's convert.
I also refactored the code, removed unnecessary variables and unified
the variable naming and error reporting a bit.
Inside jpg2ff, the loop didn't need 3 variables.
|
|
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.
|
|
Makes things a lot easier for image manipulation algorithms which
can be expected to be applied to farbfeld data.
|
|
|
|
No need for these shitty png-types.
|
|
And fix a bug in the transforms that was introduced yesterday.
The only thing remaining for jpg is handling EXIF-embedded color
profiles, but the EXIF format sucks so bad.
|
|
For some reason, those strange png_char_pp-passes were optimized away
in some way, yielding in icc_len = 0.
I now explicitly use the pointers to indicate to the compiler that we
pass by reference. Fuck those png types...
|
|
|
|
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.
|
