1. 11 Apr, 2018 2 commits
    • Laslo Hunhold's avatar
      Add warn() and die() · d9c382a9
      Laslo Hunhold authored
      To fully centralize this matter these well-tested functions are added to
      the util.c, and implemented as we know it from many other suckless
      projects.
      d9c382a9
    • Laslo Hunhold's avatar
      Add efread() and efwrite() · 02b05163
      Laslo Hunhold authored
      Given we have a util.c anyway it does not make any sense to duplicate
      code here. This way, error handling and output is in one place and one
      does not have to change things in multiple different files. This also
      reduces code duplication by a lot.
      
      It also solves an older bug where the error reporting was not on point:
      
         $ echo "farb" | ff2png
         ff2png: fread: Success
      
      (It also lacked a newline)
      
      Now it properly reports
      
         $ echo "farb" | ff2png
         ff2png: fread: Unexpected end of file
      
      I also fixed some other minor details, for instance that all error
      messages should begin with a capital letter.
      02b05163
  2. 14 Apr, 2017 1 commit
  3. 12 Apr, 2017 2 commits
    • Laslo Hunhold's avatar
      Use fshut() to properly flush the output stream · 17f09e2c
      Laslo Hunhold authored
      For small images, it could happen that the output stream would not be
      flushed before exit(), resulting in a lack of error-reporting on
      a full device. Using fflush(), a function I first introduced in sbase,
      we do the flushing before returning manually and report errors if they
      occurred.
      17f09e2c
    • Laslo Hunhold's avatar
      Refactor png-conversion-utilities · da99b582
      Laslo Hunhold authored
      We split out the libpng-setup into a separate function, it is very very
      ugly.
      The code also received a general cleanup and aligns itself much better
      with the general coding style and structure.
      da99b582
  4. 30 Mar, 2017 1 commit
  5. 18 Mar, 2016 1 commit
  6. 04 Mar, 2016 1 commit
  7. 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.
      de61085a
  8. 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
      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.
      dd22f408
  9. 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.
      e9feca5c
  10. 19 Jan, 2016 1 commit
  11. 17 Jan, 2016 2 commits
    • 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...
      42ace91b
    • 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.
      
      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.
      3bc6c69a
  12. 06 Jan, 2016 2 commits
    • FRIGN's avatar
      Improve error-handling in the tools · 295094bb
      FRIGN authored
      We don't need the jumps, but rather pass a nice function pointer to
      libpng. The jump in libjpg was also useless.
      We check each fwrite-call so there's an early bailout in case the output
      file is full.
      Flushing at the end worked as well, but it took too long for complex
      images. We don't want to "block" a pipe here and the approach in jpg2ff
      was better.
      The iHDR-read was useless. Rather use the get*-functions in libpng,
      saves us 2 local variables as well.
      295094bb
    • FRIGN's avatar
      Small changes in the png-utils · 98dbe21b
      FRIGN authored
      forgot to include setjmp.h. also correct the malloc error-messageSmall
      98dbe21b
  13. 04 Jan, 2016 5 commits
  14. 17 Nov, 2015 1 commit
  15. 13 Nov, 2015 1 commit
  16. 10 Nov, 2015 2 commits
  17. 09 Nov, 2015 1 commit
    • 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
      overkill.
      d5f6f70d
  18. 29 Jul, 2014 6 commits
    • sin's avatar
      Revert "Fix endianness in header" · 9f7647d6
      sin authored
      The previous behaviour was correct.  A width of 1900 pixels which is
      0x00000640 in hex was stored on disk as:
      
      00 00 06 40
      
      That's BE order which is what we want.
      
      Reading this uint32_t on an LE machine we get:
      
      width = 0x40060000 and converting from BE to LE
      
      we get the correct 0x640 value.
      
      Reading on a BE machine we get the correct value
      and the swap is a no-op.
      9f7647d6
    • FRIGN's avatar
      Fix endianness in header · a18c512a
      FRIGN authored
      Well, who would have thought fwrite already converts your integer to
      NBO? It would've been bloody helpful to at least mention it in the
      manual.
      While at it, fix the wrong read-in-code and call it a day.
      a18c512a
    • sin's avatar
      Be consistent and free png data in png2if as well · 6bf8ee5a
      sin authored
      6bf8ee5a
    • sin's avatar
      Don't bother to cleanup in error cases · d8501da4
      sin authored
      These tools are "one-shot", nobody cares about memory leaks while
      the program is running.
      
      Bring back -Os, no more false positives because there's no interaction
      between gotos and setjmp/longjmp.
      d8501da4
    • sin's avatar
      Reorder includes · 81c95f15
      sin authored
      81c95f15
    • sin's avatar
      Fix type inconsistencies and remove hacky compiler options · 6520175e
      sin authored
      -Os generates lots of false positives and it is not worth it much
      for such a small set of tools.
      6520175e
  19. 28 Jul, 2014 1 commit
  20. 20 Jul, 2014 1 commit
  21. 19 Jul, 2014 1 commit