summaryrefslogtreecommitdiff
path: root/png2ff.c
AgeCommit message (Collapse)Author
2017-04-14Staticize functions in png2ff(1)Laslo Hunhold
2017-04-13Use fshut() to properly flush the output streamLaslo Hunhold
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.
2017-04-12Refactor png-conversion-utilitiesLaslo Hunhold
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.
2017-03-30Add util.{c|h} to deduplicate codeLaslo Hunhold
2016-03-18Prevent overflow in rowlen and improve inaccuracies in styleFRIGN
2016-03-04Add proper blank lines in png2ff(1) before commentsFRIGN
2016-02-01Refactor tools and increase performance by ~70%FRIGN
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.
2016-01-29Back to the roots.FRIGN
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.
2016-01-20Use linear RGBFRIGN
Makes things a lot easier for image manipulation algorithms which can be expected to be applied to farbfeld data.
2016-01-19Remove more png cruft from codeFRIGN
No need for these shitty png-types.
2016-01-17Fix gcc-optimization bug in png2ffFRIGN
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...
2016-01-17Mandate "ProPhoto RGB" color space for farbfeld and handle ICC profilesFRIGN
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.
2016-01-06Improve error-handling in the toolsFRIGN
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.
2016-01-06Small changes in the png-utilsFRIGN
forgot to include setjmp.h. also correct the malloc error-messageSmall
2016-01-04Add stricter and clearer error-checking in png2ff and ff2pngFRIGN
As known from sbase, we want to manually flush stdout to see if all data has been passed on.
2016-01-04Readd &colorFRIGN
Somehow, it broke the depth-value on libpng 1.4.*. Should be worth a bug-report to the libpng-guys, but I can't be arsed right now. This fucking library is a pain in the ass.
2016-01-04Convert depth-check to switch and remove unused variablesFRIGN
2016-01-04Clean up png2ff, remove debug leftoversFRIGN
Thanks Dimitris, Hiltjo!
2016-01-04png2ff: Convert 16-Bit PNG's losslesslyFRIGN
It took me quite a while to figure out that libpng already gives you big endian values. I also tweaked the library functions a bit more to really make sure that all PNG-types (grayscale, palette, ...) are converted to RGBA properly.
2015-11-17Avoid using the non-portable endian.h conversion functionssin
Use the arpa/inet.h conversion functions which are standardized in POSIX.
2015-11-13Add _BSD_SOURCE for endian.hFRIGN
Thanks Heiko ("rundstutzen") for reporting this!
2015-11-10Remove arg.hFRIGN
No need for this when the tools don't accept arguments.
2015-11-10Fix 16-bit RGB-expands and header-endianness properlyFRIGN
2015-11-09imagefile -> farbfeldFRIGN
- 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.