1. 30 Mar, 2017 1 commit
    • Laslo Hunhold's avatar
      Make Makefile strictly POSIX compliant · bbe28227
      Laslo Hunhold authored
      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
      [0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
  2. 29 Mar, 2017 2 commits
    • Laslo Hunhold's avatar
      Rename PREREQ to REQ · 65829635
      Laslo Hunhold authored
    • Laslo Hunhold's avatar
      Overhaul Build-system · 416f39e3
      Laslo Hunhold authored
      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.
  3. 09 Jan, 2017 2 commits
  4. 19 Sep, 2016 3 commits
  5. 07 Sep, 2016 1 commit
    • FRIGN's avatar
      Shellcheck 2ff fixes · 1f8903d1
      FRIGN authored
      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.
  6. 19 May, 2016 1 commit
    • Alexander Krotov's avatar
      Improve fread error handling in ff2* · 3fa775e1
      Alexander Krotov authored
      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).
  7. 18 May, 2016 2 commits
  8. 17 May, 2016 1 commit
  9. 10 Apr, 2016 1 commit
    • FRIGN's avatar
      Remove dimension checks · 96faf20b
      FRIGN authored
      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.
  10. 03 Apr, 2016 5 commits
  11. 21 Mar, 2016 5 commits
  12. 18 Mar, 2016 1 commit
  13. 14 Mar, 2016 1 commit
    • FRIGN's avatar
      Bump version to 2 · 49cef794
      FRIGN authored
      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
      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!
  14. 04 Mar, 2016 4 commits
  15. 22 Feb, 2016 2 commits
  16. 01 Feb, 2016 1 commit
    • FRIGN's avatar
      Refactor tools and increase performance by ~70% · de61085a
      FRIGN authored
      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.
  17. 30 Jan, 2016 1 commit
  18. 29 Jan, 2016 1 commit
    • FRIGN's avatar
      Back to the roots. · dd22f408
      FRIGN authored
      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
      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.
  19. 20 Jan, 2016 1 commit
    • FRIGN's avatar
      Use linear RGB · e9feca5c
      FRIGN authored
      Makes things a lot easier for image manipulation algorithms which
      can be expected to be applied to farbfeld data.
  20. 19 Jan, 2016 2 commits
  21. 17 Jan, 2016 2 commits
    • FRIGN's avatar
      Add ICC-color-profile handling to jpg2ff · 93204899
      FRIGN authored
      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.
    • FRIGN's avatar
      Fix gcc-optimization bug in png2ff · 42ace91b
      FRIGN authored
      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...