#233 FIF_LOAD_NOPIXELS affects metadata of CMYK TIFFs

None
open
Hervé Drolon
None
5
2014-03-23
2014-01-03
Joachim Reichel
No

For the attached texture FreeImage_GetBPP() incorrectly reports 32 instead of 24 if FIF_LOAD_NOPIXELS is used in FreeImage_Load(). Such a flag should not affect image metadata.

1 Attachments

Discussion

  • repro case

     
    Attachments
  • The problem is that the image is CMYK.

    When you LOAD_NOPIXELS - the correct BPP are returned.

    When you load the image, it is converted to RGB and the actual in-memory pixel BPP is returned.

    Option one: Load using TIFF_CMYK and deal with CMYK pixels.

    Option two: Query TAG_SAMPLES_PER_PIXEL and TAG_BITS_PER_SAMPLE metadata to get the file BPP

     
  • Well, I understand why that happens. I just think it is not very intuitive from a user's point of view.

    If I use LOAD_NOPIXELS|TIFF_CMYK then it's correct for FreeImage_GetBPP() to return 32. If I just use LOAD_NOPIXELS then --I think-- FreeImage_GetBPP() should take into account the eventual conversion to RGB (independent if pixels are actually converted or not) and return 24.

    Let me describe my use case in some more detail: My pipeline cannot handle CMYK, but I have to open CMYK files. Therefore I intentionally do not use TIFF_CMYK (option 1). I also do not care whether the file actually is CMYK or not, therefore option 2 is not really what I need (I want the BPP of the converted pixels).

    I guess I could use the following workaround: Use TIFF_CMYK in addition to LOAD_NOPIXELS. Use the result of FreeImage_GetBPP() unless Freeimage_GetColorType() indicates a CMYK image. In that case use just 24 (assuming that the conversion that will happen if LOAD_NOPIXELS is not used returns RGB pixels and not RGB16 or RGBF).

    Possible, but clumsy. For now I just avoid using LOAD_NOPIXELS for TIFF files ...

     
  • The best way to do this is to relay exclusively on the metadata, taking into account the color type(CMYK/RGB) + samples per pixel(might have extra alpha channel(s)) + bits per sample(might be more then 8). These will be correct in any case, with or without NOPIXELS, there is no need for any assumptions. You can adjust these values to pretend the image is converted to RGB, of course, but you must examine them in any case in order to return correct values.

    As for GetBPP(), in general one should think of it only as an aid to pixel access, not for collecting information about the image itself.

     
    • Sorry, I don't follow your reasoning.

      [...] but you must examine them in any case in order to return correct
      values.

      Not if I am only interested in the characteristics of the pixel data after a potential conversion (without actually loading the pixel data). Then GetBPP() would just return 24 in both cases.

      As for GetBPP(), in general one should think of it only as an aid to
      pixel access [...]

      This begs the question why the funtion returns anything != 0 if LOAD_NOPIXELS is given (at least the documentation could be extended to state clearly that one time the information is about the pixel format in the file, and the other time about the pixel format in memory after a potential conversion).

      Let me give another example. Some image formats like EXR support the RGBE format. Since FreeImage does not support RGBE natively it converts this pixel type to RGBAF. GetBPP() returns 128 independent of LOAD_NOPIXELS.

      Now assume FreeImage is extended to support RGBE natively and gets a new option EXR_RGBE that skips the conversion process. Would GetBPP() then be changed to report 32 if LOAD_NOPIXELS (but not EXR_RGBE) is used? Note that the option EXR_RGBE is not used, I use just that the fact that the conversion would be optional (enabled by default).

       
  • Ok, the bug is valid

    It is a quirk in the tiff loader - it loads as CMYK first, then if TIFF_CMYK is NOT set, it will convert to RGB. However if NOPIXELS is set it just bails out right after setting up the CMYK loading, hence the wrong BPP.

    This is fixable, though messy. For now please use the metadata and do the compensations for conversion yourself.

    This bug should stay open however - GetBPP must return the same with and without NOPIXEL, though this value might not be the actual file BPP.

    I want to stress again the GetBPP should NOT be considered returning "a metadata" - it is a for low level pixel access and when there are pixels the value will be always correct.

     
    Last edit: Mihail Naydenov 2014-03-06
  • Hervé Drolon
    Hervé Drolon
    2014-03-23

    • assigned_to: Hervé Drolon
    • Group: -->