octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Move rgb2ntsc and ntsc2rgb to image package


From: Rik
Subject: Re: Move rgb2ntsc and ntsc2rgb to image package
Date: Wed, 17 Jan 2018 10:41:53 -0800

On 01/17/2018 10:22 AM, Carnë Draug wrote:
> On 17 January 2018 at 17:48, Rik <address@hidden> wrote:
>> On 01/17/2018 09:32 AM, Carnë Draug wrote:
>>> On 17 January 2018 at 16:22, Rik <address@hidden> wrote:
>>>> On 01/17/2018 07:20 AM, Carnë Draug wrote:
>>>>> [...]
>>>>> Finally, the reshaping back to the original shape can be done with the
>>>>> existing private function colorspace_conversion_revert [2].
>>>> I tried using that function at first, but had to give up because I couldn't
>>>> get ND-images to work correctly.  The problem is that, unlike rgb2ntsc, the
>>>> third dimension is removed.  I can't mimic that by just deleting the
>>>> dimension from the sz vector because colorspace_conversion_revert expects 4
>>>> dimensions.  The code in question is
>>>>
>>>>     if (is_nd)
>>>>       rv = reshape (rv, [sz(1:2) sz(4) sz(3)]);
>>>>       rv = permute (rv, [1 2 4 3]);
>>>>
>>>> We could recode this to be more general, or we could just make rgb2gray a
>>>> one-off function.  I'm inclined to do the latter, but if you see a strong
>>>> reason for modifying colorspace_conversion_revert we could do that.
>>>>
>>> The thing is that in a grayscale image, the 3rd dimension must be one,
>>> the 4th dimension can't simply be shifted to the 3rd dimension like it
>>> is happening now on core.  The test unit for ND images is also
>>> incorrect.  I have attached a diff that fixes it.
>> Go ahead and push the changes.  I thought the singleton dimension would
>> have been squeezed out, but I don't work with images much so I'm apparently
>> wrong.
> Done http://hg.savannah.gnu.org/hgweb/octave/rev/93219261164d
>
> I have also patched the image package to check for it during
> installation http://hg.code.sf.net/p/octave/image/rev/db129c587407
>
> Thank you for doing this.  Should I also prepare a patch to include
> the conversion between indexed images?

Don't we have this already?

I see ind2gray and gray2ind as well as ind2rgb and rgb2ind.  Maybe they
should have a review though because ind2gray, for example, is only using a
transformation matrix with 5 significant figures.

Also, the helper function accepts any unsigned integer class so uint32
would be okay, although I don't think that is a valid image class.

--Rik

>
> Carnë
>
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]