1. 14 Apr, 2017 2 commits
    • Laslo Hunhold's avatar
      Bump version to 3 · 00dd0ab3
      Laslo Hunhold authored
      This is more or less a refactoring release, but with deep changes in the
      tools that I was hoping to look into for a long time.
      The codebase is in a very consistent state now, also thanks to the
      introduction of a set of common utility-functions.
      What really makes me think is the fact that it takes so many iterations
      and a high level of detail to get the library handling and I/O right.
      It just makes you wonder how much software is out there that is full
      of little subtle bugs that might blow up in your face some day.
      Thanks for all the feedback!
    • Laslo Hunhold's avatar
      Add PNG-LDFLAGS and JPG-LDFLAGS in config.mk · 3a701d54
      Laslo Hunhold authored
      instead of per-tool-settings.
  2. 12 Apr, 2017 1 commit
  3. 02 Apr, 2017 1 commit
  4. 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
  5. 29 Mar, 2017 1 commit
    • 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.
  6. 18 May, 2016 1 commit
    • Hiltjo Posthuma's avatar
      Makefile improvements · c4944379
      Hiltjo Posthuma authored
      - fix: rebuild on source change.
      - allow to override dependency flag per tool (the ones that have deps).
      - rebuild on config.mk or headers change.
  7. 03 Apr, 2016 1 commit
  8. 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!
  9. 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.
  10. 17 Jan, 2016 1 commit
    • FRIGN's avatar
      Mandate "ProPhoto RGB" color space for farbfeld and handle ICC profiles · 3bc6c69a
      FRIGN authored
      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.
      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.
  11. 06 Jan, 2016 2 commits
  12. 05 Jan, 2016 2 commits
  13. 04 Jan, 2016 1 commit
    • FRIGN's avatar
      Update config.mk · 86495f80
      FRIGN authored
      -Wno-clobbered is not supported on OpenBSD. Let's remove it and Wextra
      with all its stupid warnings.
  14. 22 Nov, 2015 2 commits
    • FRIGN's avatar
      JPG Code cleanup · b52a5f56
      FRIGN authored
    • FRIGN's avatar
      (Re)add jpg2ff · 2c4b975c
      FRIGN authored
      Thanks z3bra for porting this!
      Also change 2ff to use case instead of if-blocks.
  15. 17 Nov, 2015 1 commit
  16. 09 Nov, 2015 2 commits
    • FRIGN's avatar
      Overhaul buildsystem · 526f2c55
      FRIGN authored
    • FRIGN's avatar
      imagefile -> farbfeld · d5f6f70d
      FRIGN authored
       - Rename the format
       - Change the format specification
       - Drop old tools waiting to be fixed on a later date, just keep
         fixed png for now
       - Simplify other stuff
      This is a direct consequence of my slcon2-talk on this topic.
      At first I planned to have 64 bits per channel, but this is
  17. 31 Jul, 2015 1 commit
  18. 31 Jul, 2014 1 commit
  19. 29 Jul, 2014 4 commits
  20. 22 Jul, 2014 1 commit
  21. 20 Jul, 2014 1 commit
  22. 19 Jul, 2014 1 commit