path: root/ff2png.c
Commit message (Collapse)AuthorAge
* Use fshut() to properly flush the output streamLaslo Hunhold2017-04-13
| | | | | | | | 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.
* Refactor png-conversion-utilitiesLaslo Hunhold2017-04-12
| | | | | | | 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.
* Add util.{c|h} to deduplicate codeLaslo Hunhold2017-03-30
* Improve fread error handling in ff2*Alexander Krotov2016-05-19
| | | | | | 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).
* Prevent overflow in rowlen and improve inaccuracies in styleFRIGN2016-03-18
* Use uint32-array to store the headerFRIGN2016-03-04
| | | | | this goes around the undefined behaviour imposed by using (*(uint32_t *)(hdr + 4n))
* Refactor tools and increase performance by ~70%FRIGN2016-02-01
| | | | | | | | | | | 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.
* Back to the roots.FRIGN2016-01-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use linear RGBFRIGN2016-01-20
| | | | | Makes things a lot easier for image manipulation algorithms which can be expected to be applied to farbfeld data.
* Remove more png cruft from codeFRIGN2016-01-19
| | | | No need for these shitty png-types.
* Mandate "ProPhoto RGB" color space for farbfeld and handle ICC profilesFRIGN2016-01-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Improve error-handling in the toolsFRIGN2016-01-06
| | | | | | | | | | | | 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.
* Small changes in the png-utilsFRIGN2016-01-06
| | | | forgot to include setjmp.h. also correct the malloc error-messageSmall
* Add stricter and clearer error-checking in png2ff and ff2pngFRIGN2016-01-04
| | | | | As known from sbase, we want to manually flush stdout to see if all data has been passed on.
* ff2png: Export 16-Bit RGBA PNG's so we don't lose dataFRIGN2016-01-04
* Avoid using the non-portable endian.h conversion functionssin2015-11-17
| | | | | Use the arpa/inet.h conversion functions which are standardized in POSIX.
* Add _BSD_SOURCE for endian.hFRIGN2015-11-13
| | | | Thanks Heiko ("rundstutzen") for reporting this!
* Remove arg.hFRIGN2015-11-10
| | | | No need for this when the tools don't accept arguments.
* Fix 16-bit RGB-expands and header-endianness properlyFRIGN2015-11-10
* imagefile -> farbfeldFRIGN2015-11-09
- 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.